Skip to main content
Únase a nosotros en TDX, en San Francisco, o en Salesforce+ los días 5 y 6 de marzo en la conferencia para desarrolladores sobre la era de agentes de IA. Registrarse ahora.

Revisar el ciclo de vida de la versión

Objetivos de aprendizaje

Después de completar esta unidad, podrá:

  • Describir el ciclo de vida de la versión principal de Marketing Cloud Engagement.
  • Conocer los pasos de las versiones de parche y de emergencia.

Ciclo de vida de la versión principal

Vamos a ver cómo nuestro equipo de producto hace posible la magia de la innovación. En Salesforce, seguimos un ciclo de vida de desarrollo ágil para cada versión principal. Empezamos planificando cada versión y luego destinamos entre 8 y 10 semanas al desarrollo antes de inmovilizar las funciones. Después de esa fecha, nos centramos en la preparación para la versión y seguimos un proceso de versión por etapas. Vamos a repasar las fases del ciclo de vida con más detalle.

Fases del ciclo de vida de la versión principal.

Fase

Qué ocurre

Más información

Planificación

Los equipos revisan y planifican lo que quieren completar en la próxima versión principal. Revisan las listas de deseos de productos, las ideas de productos en IdeaExchange y los problemas conocidos.

  • ¿Tiene una gran idea para la función de un producto? Visite Marketing en IdeaExchange para compartir su idea con nosotros.
  • Consulte el estado de los problemas conocidos en el sitio de problemas conocidos de Salesforce.

Desarrollo ágil

Una vez establecido el plan, los equipos organizan el trabajo en "sprints" para centrarse en funciones específicas que quieren crear y probar. El ciclo de desarrollo termina con la inmovilización de funciones, la fecha en la que se eliminan todas las funciones incompletas de la próxima versión.

  • Creación, prueba y repetición. Todas las funciones pasan por una serie de pruebas de unidad, funcionales y de rendimiento antes de agregarlas a una versión.
  • Después de la inmovilización de funciones, los equipos vuelven a empezar el proceso para desarrollar la siguiente versión.

Preparación de la versión

Cuando se inmovilizan las funciones, solo se incluyen en la versión las que se hayan probado, validado y aprobado.

  • Se realizan pruebas adicionales, incluidas pruebas de compatibilidad con versiones anteriores, pruebas de integración, pruebas de funcionamiento, validación de bases de datos y scripts de implementación, junto con la validación de casos de uso de clientes.
  • Varios equipos deben aprobar las actualizaciones.

Versiones por etapas

Una vez aprobadas, Marketing Cloud Engagement lanza nuevas funciones por etapas. Todos los clientes reciben actualizaciones de la versión uno (R1) o de la versión dos (R2).

  • Antes de lanzar la versión R1, disponemos de una versión R0 interna para que los equipos internos con cuentas de Salesforce Marketing Cloud Engagement realicen aún más pruebas.
  • Aproximadamente el 25 % de los clientes están incluidos en la R1 en función de su instancia de base de datos.
  • El 75 % restante de los clientes está incluido en la R2.
Nota

¿Quiere saber si forma parte de la R1 o la R2? Recibirá notificaciones sobre la fecha del lanzamiento de la versión, pero en realidad la versión que reciba dependerá de su pila y de su instancia de base de datos. Las pilas 4, 11, 13 y 50 reciben la R1. Las pilas 1, 6, 7, 10, 12 y 51 reciben la R2.

Procedimientos de la versión

Como puede imaginar, nuestros equipos están muy ocupados antes de lanzar una versión principal. Queremos proporcionarle una visión en segundo plano de lo que ocurre justo antes de lanzar las funciones nuevas.

Cuándo

Qué ocurre

De 2 a 3 semanas antes del lanzamiento

Durante las actividades de preparación para la versión, hacemos lo siguiente:

  • Nos reunimos con ejecutivos para revisar los manuales de pruebas y preparación.
  • Confirmamos la aprobación de la versión por parte de los ejecutivos.
  • Solucionamos los problemas funcionales pendientes.
  • Completamos los componentes de implementación.

De 1 a 2 días antes del lanzamiento

Durante las actividades previas a la versión, hacemos lo siguiente:

  • Realizamos actualizaciones de esquemas SQL compatibles con versiones anteriores. (Lo que básicamente significa que nos preparamos para lo peor asegurándonos de que existe una opción de reversión en caso de que ocurra un problema).
  • Nos preparamos para evitar tiempos de inactividad o interrupciones.

Día del lanzamiento

Para garantizar un impacto mínimo, hacemos lo siguiente:

  • A las 12 p. m. EST del día del lanzamiento (que siempre es sábado en EE. UU.), implementamos las actualizaciones de la base de datos y del código. La elección del día y la hora se debe a que es el momento en el que hay menos tráfico de clientes.
  • Para el control de calidad, realizamos validaciones automáticas y manuales de los datos justo después del lanzamiento.

1 días después del lanzamiento

Comprobamos lo siguiente:

  • Fiabilidad del sitio, soporte, gestión de la versión e ingeniería para ver si hay problemas abiertos relacionados con la versión.

Utilizamos lo siguiente:

  • Herramientas de supervisión para identificar y resolver problemas de forma proactiva antes de que afecten a los clientes.

Versiones adicionales

Además de centrarse en las mejoras de los productos y en las actualizaciones de las versiones principales, nuestros equipos de productos trabajan para corregir errores e investigar problemas conocidos. Disponemos de un programa semanal de versiones de parche para actualizar el producto de manera regular.

Cuándo

Qué ocurre

De forma continua

Se investigan y se revisan los errores para encontrar posibles soluciones. Una vez que se encuentra una solución y se producen cambios en el código, se prueban de manera exhaustiva.

2 días antes del lanzamiento

Las correcciones aprobadas se bloquean para la próxima versión de parche. Además, los equipos completan los componentes de implementación y confirman el plan de implementación.

1 día antes del lanzamiento

A las 2 p. m. EST, se implementa el código en una instancia de producción interna. Los equipos realizan un seguimiento de la implementación y la supervisan, además de llevar a cabo pruebas adicionales.

Día del lanzamiento (miércoles)

Sin interrupciones*, los miércoles a las 8 p. m. EST en los Estados Unidos, se implementa el código nuevo para todos los clientes. Después del lanzamiento, se realizan pruebas de humo y validaciones adicionales.

Nota

* Esto se refiere a las versiones semanales de código.  Revise este artículo de conocimiento sobre los períodos de mantenimiento.

Ciclo de vida de la versión de emergencia

Algunas correcciones son demasiado importantes para esperar a una versión semanal. Por eso, cuando se deriva un problema, nos centramos en encontrar una solución de inmediato. Una vez que se identifica y se prueba la corrección, es necesario aprobarla y validarla antes de programar una versión de emergencia. Una vez planificadas, las versiones de emergencia se implementan por etapas, de forma similar a las versiones principales. Esto nos permite centrarnos en una estrategia de implementación con el menor riesgo.

Ahora que ya conoce los tipos de versiones y su ciclo de vida, en la siguiente unidad abordaremos las notificaciones y la preparación para las versiones.

Recursos

Comparta sus comentarios sobre Trailhead en la Ayuda de Salesforce.

Nos encantaría conocer su experiencia con Trailhead. Ahora puede acceder al nuevo formulario de comentarios cuando quiera desde el sitio de la Ayuda de Salesforce.

Más información Continuar para compartir comentarios