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

Gestionar los cambios en versiones cada vez más complejas

Objetivos de aprendizaje

Después de completar esta unidad, podrá:
  • Explicar cómo el uso del control de versiones puede beneficiar a una versión de conjunto de cambios.
  • Describir las similitudes entre los modelos de conjunto de cambios y de desarrollo de organización.

Esta unidad describe por qué Calvin y sus colegas cambian al desarrollo con códigos y al sistema de control de versiones. A medida que vaya leyendo esta unidad, considere las elecciones que haría para su equipo. Al final de este módulo, realizaremos ejercicios prácticos para que pueda aprender el proceso y tomar las decisiones más fundamentadas y que mejor se adapten a su caso.

Cambio al modelo de desarrollo de organización para asumir el aumento de la complejidad

Zephyrus tiene un trimestre excelente detrás de otro. Salesforce se está utilizando ahora en otras partes del negocio, no solo en Ventas. Tras consultarlo con Calvin y los encargados del departamento del Servicio de atención al cliente, el director de operaciones acepta pasar a Enterprise Edition y adquirir Service Cloud Lightning. Con Service Cloud Lightning, la compañía podrá ofrecer una asistencia instantánea y personalizada a sus clientes. Y lo que es mejor, el departamento del Servicio de atención al cliente tiene algunos miembros del equipo con capacidades de codificación para desarrollar aplicaciones de Salesforce adaptadas a las necesidades de su equipo.

Calvin tiene claro que la complejidad de la organización está superando cada vez más las competencias del equipo en cuanto al proceso de desarrollo de conjuntos de cambios. La compañía necesita ahora un proceso de gestión de cambios más riguroso y un proceso de auditoría (piense en un sistema de control de versiones) que le ayude a gestionar tantas líneas de trabajo.

Además, el equipo está trabajando con muchas limitaciones en cuanto al uso de conjuntos de cambios. Por ejemplo, pueden agregar, pero no pueden eliminar campos (cambios destructivos).

En una presentación a su director y al director general de Zephyrus, Calvin propone realizar el cambio al modelo de desarrollo de organización.

Calvin proponiendo el cambio al modelo de desarrollo de organización.

Al igual que en el proceso de conjunto de cambios, el artefacto de la versión que están creando es un conjunto de cambios de metadatos relativos a su organización de producción. En el modelo de desarrollo de organización, no obstante, el equipo puede obtener una gran mejora de gestión de cambios al externalizar los cambios que realizan. Pueden utilizar la CLI de Salesforce para extraer metadatos de un entorno de desarrollo para integrarlos con un sistema de control de versiones (VCS).

También pueden utilizar la CLI de Salesforce para programar tareas rutinarias e impulsar la productividad de todo el que colabore en la versión. La sugerencia de Calvin de empezar a crear secuencias de comandos para ejecutar implementaciones de prueba y ejecutar pruebas de Apex tiene sentido para su director y para el director general.

Gracias a los argumentos de Calvin centrados en el negocio, su director y el director general aprueban el cambio al desarrollo de organización. En reconocimiento a su contribución para el éxito de la compañía, Calvin obtiene un ascenso a analista de negocio. Este ascenso también proporciona a Calvin el ámbito de trabajo que necesita para gestionar versiones entre departamentos.

Nuevas ventajas y algunos temas familiares

Calvin y dos miembros del equipo de servicio de atención al cliente trabajan cada uno en un proyecto distinto, con entornos de desarrollo independientes. Los tres proyectos están programados para la misma versión. A medida que avanzan en el proceso de desarrollo de la organización, advierten algunos aspectos familiares y algunas cosas distintas al proceso del conjunto de cambios.

Al igual que lo hacen en el desarrollo del conjunto de cambios, los tres miembros del equipo realizan un seguimiento de los cambios que están haciendo. ¿Por qué? El equipo necesita saber qué componentes cambian, si deben agregar estos componentes a un conjunto de cambios o si deben recuperarlos con la CLI de Salesforce. Además, algunas de sus personalizaciones no se pueden implementar en otra organización, ya que incluyen componentes modificados que no se representan en la API de metadatos. Estos cambios deben volver a crearse manualmente en la organización de destino, así que sigue siendo importante realizar un seguimiento de estos.

Cuando los miembros del equipo completen sus asignaciones de desarrollo correspondientes, su siguiente paso será mover sus cambios al entorno de compilación para su integración. Pero ahora deberán utilizar la CLI de Salesforce para recuperar los cambios de sus entornos de desarrollo correspondientes, en lugar de utilizar herramientas declarativas para crear un conjunto de cambios. Integrarán su trabajo con un VCS, de modo que los cambios que recuperen los miembros del equipo se puedan confirmar y seguir en el VCS.

La confirmación y el seguimiento de los cambios recuperados en el VCS supone una ventaja clave para el equipo. Al utilizar el proceso de conjunto de cambios, los miembros del equipo pueden (y suelen) sobrescribir por error los cambios de otra persona al implementar un conjunto de cambios sobre el conjunto de cambios anterior. Al utilizar el nuevo proceso de confirmación de cambios en el VCS, los conflictos de personalización se pueden identificar antes de que se sobrescriba un cambio.

Al avanzar hacia el paso de compilación, las personalizaciones del equipo ya están integradas en el proyecto en el control de fuentes. Desde el VCS, estos cambios se implementan de forma conjunta en el entorno de compilación para la integración y las pruebas. Al igual que en el proceso del conjunto de cambios, los cambios se prueban de forma conjunta en el entorno de compilación. Y, de la misma forma que antes, el resultado es un único artefacto de versión que es, a efectos prácticos, un gran conjunto de cambios consolidado. Sin embargo, Calvin ahora utiliza la CLI de Salesforce para recuperar el artefacto del entorno de compilación. Y, a medida que avanza el proceso de desarrollo de la organización, el artefacto de la versión sigue moviéndose desde el VCS y avanzando hacia el siguiente entorno.

Aunque utilizan herramientas adicionales en el proceso de desarrollo de la organización, los pasos básicos de ALM, el concepto de conjunto de cambios y los entornos para desarrollo y pruebas son los mismos. Todo el que trabaje en la primera versión bajo el nuevo modelo de desarrollo tiene al menos algunos puntos familiares de referencia. Además, Calvin está entusiasmado con utilizar Trailhead y recursos del sitio web de desarrolladores de Salesforce para ampliar sus conocimientos y sus habilidades técnicas.

El cambio al modelo de desarrollo de organización ayuda a proporcionar a Zephyrus el control y la eficiencia que necesitan para ampliar su uso de Salesforce en toda la compañía.