Empiece a realizar un seguimiento de su progreso
Inicio de Trailhead
Inicio de Trailhead

Aprender los conceptos básicos de la gestión de versiones

Objetivos de aprendizaje

Después de completar esta unidad, podrá:

  • Identificar las tres categorías de versiones y los tipos de cambios que proceden en cada categoría.
  • Describir un conjunto de cambios.
  • Explicar por qué es importante realizar un seguimiento de los cambios y las dependencias para las versiones del conjunto de cambios.

En esta unidad, Calvin y sus colegas comienzan a aplicar el proceso ALM. A medida que vaya leyendo, considere las elecciones que haría para su equipo. Después, trabaje en los módulos que aparecen al final de este módulo para familiarizarse con el proceso y poder decidir lo que funcione mejor para usted.

Crear un proceso de gestión de versiones

El equipo de Zephyrus adapta sus prácticas de personalización a los pasos recomendados de ALM. Llevará un tiempo para que se acostumbren a utilizar este proceso, pero sus esfuerzos valdrán la pena. Verán un incremento en la velocidad de desarrollo y una disminución en las interrupciones se equipos de ventas. Con eso basta para convencer al equipo, y el equipo de gestión es está encantado.

Al implementar el ciclo de ALM, Zephyrus ha adoptado un proceso de gestión de versiones básico. No obstante, el equipo tiene proyectos grandes y pequeños en curso, todos en distintos pasos del ciclo de ALM. Para ayudar a tener los proyectos y las expectativas bajo control, Calvin agrega más estructura mediante la configuración de un programa de versiones y la definición de criterios para versiones de distintos tamaños.

Las versiones se suelen clasificar en una de tres categorías.

Parche
Correcciones de errores y cambios sencillos. Los cambios sencillos incluyen reportes, tableros, vistas de lista y plantillas de email.
Secundarias
Cambios con un impacto limitado, como una regla de flujo de trabajo nueva o un desencadenador que influye en un único proceso de negocio. Estas versiones suelen requerir pruebas, pero solo de capacitación y gestión de cambios limitadas. Normalmente, un equipo entrega los cambios para una versión secundaria en unas semanas.
Principales
Cambios con un impacto considerable, como cambios con una o varias dependencias. Dado que estas versiones pueden influir en gran medida en la experiencia del usuario y la calidad de los datos, se requieren pruebas exhaustivas, capacitación y una gestión minuciosa de los cambios. Las versiones principales se suelen presentar una vez por trimestre (Salesforce lo hace tres veces al año).

Versión en una programación coherente. El objetivo es publicar a intervalos regulares o en un día determinado de la semana. Por ejemplo, puede que las versiones secundarias se produzcan a las 8 PM en hora oriental el primer martes de cada mes. Una programación coherente permite la planificación en toda la compañía y determina las expectativas de los usuarios de negocio. Una cosa más: Intente no programar versiones en fecha próximas a las vacaciones u otros eventos importantes.

Realizar un seguimiento de un conjunto de cambios durante todo el proceso hasta la producción

A medida que avanza por los pasos de ALM, el equipo de Zephyrus utiliza el modelo de desarrollo del conjunto de cambios. El equipo utiliza la interfaz de usuario de Configuración para crear cambios en un entorno de desarrollo y migrar esos cambios entre entornos a través de los pasos de ALM.

En el desarrollo del conjunto de cambios, el artefacto de la versión del equipo es un conjunto de cambios de metadatos, como diff o delta, con relación a lo que hay en la organización de producción. Solo se incluirán en la versión los metadatos que se agregaron o modificaron; si no hay ningún cambio, no está en la versión.

  • Cada desarrollador realiza un seguimiento de los cambios que se realizaron en su personalización de la versión. La herramienta de seguimiento puede ser cualquier cosa, desde una hoja de cálculo hasta un sistema de seguimiento de trabajo.
  • Puede que determinados componentes modificados no estén disponibles aún en la API de metadatos y tengan que migrarse manualmente entre entornos. Si realiza un seguimiento de estos cambios, no olvide migrarlos.
  • Como gestor de la versión, Calvin trabaja para descubrir e incluir componentes dependientes en la versión. Por ejemplo, no es posible migrar un nuevo campo personalizado al siguiente entorno si el objeto personalizado al que pertenece no existe en la organización de destino. La herramienta del conjunto de cambios ayuda a Calvin a identificar estas dependencias.

Página Dependencias de componente, mostrando las dependencias por nombre y qué hace referencia a estas.

Nota

Nota

La migración de perfiles y conjuntos de permisos puede ser complicada. Revise las consideraciones especiales para la implementación y recuperación de conjuntos de permisos y perfiles antes de continuar.

El seguimiento de los cambios en cada versión conlleva trabajo, pero si mantiene al día sus registros, tendrá una implementación sin contratiempos cuando publique la versión en producción.

¡Todos juntos!

Su versión puede contener varios proyectos, y cada proyecto puede desarrollarse y probarse en entornos distintos. Pero, antes del paso de compilación, debe migrar todos los cambios de cada proyecto al mismo entorno para la integración. Desde este punto en adelante, sus cambios y personalizaciones en una versión viajarán juntos, en dirección a la producción, como un único conjunto de cambios integrado. En el paso de la versión de prueba que sigue a la compilación, probará todos los cambios juntos.

Como gestor de versiones, Calvin realiza un seguimiento de los cambios de todos los contribuidores de su versión. Asimismo, realiza un seguimiento de los cambios que se realizaron en producción y que no se reflejan en los entornos de desarrollo y prueba. ¿Por qué? Es la única forma en la que pueden implementar personalizaciones correctamente, sin sobrescribir cambios de forma involuntaria en la organización de producción.