Cómo implementar CI con Salesforce

A menudo nos preguntan cuál es el flujo ideal de integración continua para Salesforce. Puede ser un tema complejo porque muchas personas tienen acceso para hacer cambios en Salesforce y, históricamente, las herramientas han sido insuficientes. Después de trabajar con cientos de desarrolladores de Salesforce durante los últimos 9 meses, hemos aprendido mucho sobre cómo los distintos equipos abordan la integración continua. Estas son las mejores prácticas que hemos identificado para la integración continua con Salesforce. Gran parte se inspira en el excelente flujo de desarrollo de Atlassian para Salesforce.

CADA DESARROLLADOR Y ADMINISTRADOR TIENE SU PROPIO SANDBOX

Cada desarrollador y administrador de Salesforce debe tener su propio sandbox que puedan usar para desarrollar y probar cambios. Esto es cada vez más común, pero todavía no es una práctica universal. Muchos equipos aún no proporcionan sandboxes a sus administradores. La configuración y los cambios declarativos son una parte tan importante de la propuesta de valor y del flujo de desarrollo de Salesforce que es esencial incluir adecuadamente los cambios declarativos en ese flujo.

USA AL MENOS UN ENTORNO DE PREPRODUCCIÓN O INTEGRACIÓN

Además de los sandboxes para cada desarrollador y administrador, conviene contar con un sandbox adicional (o varios) para integrar cambios. Aquí es donde resulta útil un entorno de preproducción o UAT. En este entorno puedes fusionar código y resolver cualquier conflicto de forma segura. También puedes usarlo para hacer pruebas antes de pasar a producción. Muchos equipos optan por usar un sandbox de copia completa o, al menos, de copia parcial aquí.

ACTUALIZA LOS METADATOS DESDE PRODUCCIÓN A DIARIO

El objetivo de usar sandboxes es contar con un lugar seguro para probar el código y los cambios de configuración antes de enviarlos a producción. Sin embargo, para que esto sea útil, tus sandboxes deben ser copias de tu entorno de producción; de lo contrario, tus pruebas serán propensas a errores. Para mantener tus entornos sincronizados, debes actualizar los metadatos de tus sandboxes desde producción todos los días. En un flujo ideal de integración continua, puedes hacerlo mediante un pull en Git. Mantener tus sandboxes fieles al entorno de producción te ahorrará innumerables dolores de cabeza más adelante.

La organización ha sido tradicionalmente la fuente de verdad. Salesforce DX busca cambiar esto al trasladar la fuente de verdad a sistemas externos de control de versiones como Git, pero mientras Salesforce permita cambios declarativos y de configuración, la organización seguirá siendo la fuente de verdad definitiva.

CÓMO ENCONTRAR UNA FUENTE DE VERDAD QUE FUNCIONE PARA Salesforce

La integración continua comienza con el control de versiones y una fuente de verdad establecida. Históricamente, esto ha sido un problema en el ecosistema de Salesforce porque la organización ha sido tradicionalmente la fuente de verdad. Salesforce DX busca cambiar esto al trasladar la fuente de verdad a sistemas externos de control de versiones como Git, pero mientras Salesforce permita cambios declarativos y de configuración, la organización seguirá siendo la fuente de verdad definitiva.

Afortunadamente, hay una manera de resolver este conflicto inherente. Configura una rama de Git que refleje la actividad de tus organizaciones. Así, si se produce algún cambio en tu organización, se registrará automáticamente en tu historial de Git. Y si se realiza algún cambio en tu rama de Git, se desplegará automáticamente en la organización conectada. De esta manera, no habrá riesgo de que un cambio en el sandbox quede fuera del control de versiones y provoque desajustes, o viceversa.

Blue Canvas hace esto por ti automáticamente. Puedes establecer esta configuración en 4 clics.

Con esta configuración, puedes programar o desarrollar usando cualquier IDE de Salesforce con el que te sientas cómodo: MavensMate, Eclipse, Illuminated Cloud, la consola de desarrollo de Salesforce, etc. Sin importar cómo lleguen los cambios a un sandbox de desarrollo, Blue Canvas los detectará y los incorporará a la rama de Git de esa organización.

RAMAS DE FUNCIONALIDADES CON Salesforce

Una vez que hayas resuelto el problema de la fuente de verdad, estarás listo para configurar un flujo de trabajo con ramas. El flujo ideal de integración continua para Salesforce comienza con una rama de funcionalidad. Esta es una rama aislada que parte de la base de código principal. Puedes hacer cambios en ella de forma segura sin afectar la producción ni el trabajo de tus colegas. Aquí puedes experimentar libremente. Puedes tener varias ramas de funcionalidades activas a la vez.

Cuando quieras migrar el trabajo de tu rama de funcionalidad a tu organización de desarrollo, simplemente crea una solicitud de incorporación de cambios o realiza una fusión entre tu rama de funcionalidad y la rama conectada a tu organización de desarrollo. Con Blue Canvas, esto fusionará y desplegará automáticamente tus nuevos cambios en tu sandbox de desarrollo.

Ten en cuenta que no es imprescindible usar ramas de funcionalidades; es solo una buena práctica. Puedes desarrollar directamente en tu sandbox de desarrollo, siempre que sea de uso exclusivo para ti.

REVISIÓN DE CÓDIGO Y PRUEBAS EN UAT

Una vez que hayas probado tu código en tu propio sandbox de desarrollo, estarás listo para enviarlo al entorno de preproducción. Una buena práctica es que otra persona revise tus cambios mediante una revisión de código.

Para hacerlo, simplemente crea una solicitud de incorporación de cambios (o una solicitud de despliegue en Blue Canvas). Blue Canvas buscará conflictos de fusión y ejecutará una validación de Salesforce. Mientras tanto, un colega puede revisar tu código; el proceso solo tarda unos minutos o segundos, según el tamaño del despliegue. Si todo está bien, puedes desplegar tu código en UAT o preproducción automáticamente o con un clic.

Como cada rama conectada corresponde a una organización específica de Salesforce, puedes desplegar automáticamente al fusionar en Git.

DE UAT Y PREPRODUCCIÓN A PRODUCCIÓN

Los entornos de UAT y preproducción sirven para probar e integrar el código de los distintos desarrolladores y administradores de tu equipo. Si tienes un equipo con varios desarrolladores, aquí puedes resolver conflictos de fusión de forma segura y garantizar que el código de un usuario no sobrescriba el de otro. Aquí puedes realizar más revisiones de código y pruebas.

También puedes usar git diff o la herramienta de comparación de Blue Canvas para ver qué diferencias existen entre UAT y producción.

Si todo se ve bien en UAT, simplemente puedes abrir otra solicitud de despliegue con producción o master como organización de destino. Desplegar aquí es muy rápido. Blue Canvas ejecutará automáticamente tus pruebas unitarias. Si todas pasan, puedes desplegar automáticamente o con un clic.

PASO POSTERIOR AL DESPLIEGUE

Como mencionamos en nuestros tres principios fundamentales, ahora debes asegurarte de que tus sandboxes reflejen el entorno de producción lo más fielmente posible. Por eso, después de cada despliegue a producción, conviene traer los metadatos de producción a tu entorno de UAT y a todos los sandboxes de desarrollo. Con Blue Canvas, solo tienes que abrir otra solicitud de despliegue y fusionar el código de master con tus ramas de desarrollo y de preproducción, sin preocuparte por eliminar trabajo aún no desplegado en tus sandboxes.

REPITE

Eso es todo. La integración continua es bastante sencilla, pero muy potente. Una vez que adoptes este flujo de trabajo con Git, podrás lanzar nuevas funcionalidades de forma continua, segura y rápida, y darle a tu equipo de desarrollo mucha más autonomía para escribir código de calidad y crear funcionalidades innovadoras.

‍