Despliegues descendentes en Salesforce

Con este artículo, aprende sobre la importancia de los despliegues descendentes para mantener una buena estrategia de sandboxes en Salesforce, las limitaciones de las actualizaciones de sandboxes y cómo puedes usar Git para gestionar despliegues descendentes. También aprendí sobre las ventajas de usar Git, como la capacidad de gestionar flujos de trabajo colaborativos complejos y seleccionar qué componentes incluir o excluir en una fusión descendente.

Estas son nuestras 5 conclusiones clave:

1. Los despliegues descendentes son importantes para mantener los entornos de prueba y desarrollo lo más parecidos posible al de producción y evitar fallas inesperadas al desplegar nuevas funcionalidades.

2. Las actualizaciones de sandboxes tienen limitaciones en cuanto a frecuencia, velocidad e inclusión tanto de datos como de metadatos.

3. Puedes usar Git para gestionar despliegues descendentes y superar las limitaciones de las actualizaciones de sandboxes.

4. Git es ideal para los despliegues descendentes porque maneja solo metadatos, ofrece mayor rendimiento y puede gestionar flujos de trabajo colaborativos complejos.

5. Git permite realizar despliegues descendentes selectivos, lo que resulta útil cuando quieres integrar cambios de producción sin sobrescribir el trabajo realizado en un sandbox.

‍

Uno de los principios más importantes para mantener una buena sandboxes de Salesforce son los despliegues descendentes. Lamentablemente, muy pocos equipos realizan despliegues descendentes regulares y repetibles desde su entorno de producción hacia sus entornos de preproducción y desarrollo.

¿Qué es un despliegue descendente?

Un despliegue descendente es un despliegue desde tu entorno de producción hacia una o más de tus organizaciones de desarrollo o preproducción. Según el tamaño de tu equipo, puedes tener una sola organización de desarrollo desde la que despliegas directamente a producción, o puedes tener decenas. Sin importar el tamaño de tu equipo, un componente clave de una buena estrategia de sandboxes es mantener tus entornos de prueba y desarrollo lo más parecidos posible al de producción. La razón es simple: quieres asegurarte de que las nuevas funcionalidades que creas en un entorno de prueba no fallen inesperadamente al desplegarlas a producción. Dada la complejidad de las dependencias en muchas organizaciones de Salesforce, no es raro que un equipo vea cómo una flamante funcionalidad llega a producción llena de errores cuando «funcionaba perfectamente en mi sandbox».

Las limitaciones de las actualizaciones de sandboxes en Salesforce

Normalmente, los equipos usan Actualizaciones de sandboxes para actualizar los entornos de desarrollo con cambios de producción. Sin embargo, esto es un problema porque las actualizaciones de sandboxes son limitadas y lentas. Según el tipo de organización, solo puedes actualizar tu sandbox cada cierto tiempo. Las organizaciones de copia completa solo se pueden actualizar una vez al mes. Incluso los sandboxes de desarrollador solo se pueden actualizar una vez cada 5 días. Si intentas lograr entrega continua para Salesforce necesitarás poder actualizar con mayor frecuencia.

Además, las actualizaciones de sandboxes son lentas. Una actualización puede tardar horas o días.

Las actualizaciones de sandboxes incluyen tanto datos como metadatos. Esto puede ser molesto si has configurado muchos datos de prueba en tu sandbox para trabajar en funcionalidades. Quizá quieras que tus metadatos reflejen los de producción, pero no necesariamente tus datos.

Por último, las actualizaciones son de todo o nada. ¿Qué pasa si quieres implementar cambios desde producción en un entorno de desarrollo sin borrar el trabajo que ya empezaste? Con una actualización del sandbox, no hay forma de excluir ciertos componentes o archivos de producción.

Cómo usar Git para gestionar despliegues descendentes

Dadas las limitaciones de las actualizaciones de sandboxes de Salesforce, muchos han buscado una mejor manera de hacerlo. El control de código fuente puede ayudar. En Blue Canvas nos encanta Git, pero puedes aplicar los mismos principios a otros sistemas de control de código fuente, como SVN.

El control de versiones es ideal para implementar cambios desde producción en entornos de desarrollo porque resuelve algunas de las limitaciones de las actualizaciones de sandboxes. En primer lugar, no hay límites en la frecuencia con la que puedes hacer una fusión de git desde producción. En segundo lugar, como solo modificas metadatos, no tienes que preocuparte por perder tus datos de prueba. Además, al tratarse solo de metadatos, la fusión desde producción es mucho más rápida. Git está escrito en C y diseñado para manejar grandes cambios en bases de código casi al instante.

Quizás lo mejor de todo es que Git está diseñado para gestionar flujos de trabajo colaborativos complejos. Si varias personas trabajan en los mismos sandboxes, o si hay funcionalidades en desarrollo en un sandbox, puedes sincronizarlo con producción sin sobrescribir tus funcionalidades. Puedes seleccionar qué clases incluir y cuáles excluir.

Un ejemplo de despliegues descendentes selectivos

En alpha-webinar he estado trabajando en un cambio en BookPrice.cls. Lo empecé hace un mes, pero surgieron otras prioridades más urgentes y tuve que dejarlo en pausa mientras hacía otros cambios que llegaron a producción. Como era de esperarse, prod-webinar ha cambiado bastante durante el último mes. Hubo adiciones, eliminaciones y modificaciones.

Antes de volver a trabajar en BookPrice.cls, quiero traer todos los cambios de prod-webinar a mi sandbox. Así tendré la certeza de que todas las pruebas en mi sandbox son válidas y coherentes con lo que veré en prod-webinar. Pero no quiero sobrescribir ni eliminar el trabajo que he hecho en la nueva clase.

Con Git puedo hacerlo muy fácilmente. Solo creo una solicitud de implementación desde prod-webinar hacia alpha-webinar.

Puedo ver que hay 25 archivos diferentes, 45 adiciones y 75 eliminaciones entre prod-webinar y alpha-webinar. Git me muestra claramente que, si hiciera una actualización simple del sandbox, se eliminaría BookPrice.cls. Con Git y Blue Canvas puedo quitar esa eliminación de destructiveChanges.xml con un solo clic.

Ahora, cuando haga la fusión desde producción, seguiré teniendo mi BookPrice.cls de hace un mes para continuar trabajando en él. Además, todos mis datos de prueba se mantienen iguales, así que no necesito hacer nada para volver a configurarlos.

Si algo sale mal en cualquier parte de este proceso, puedo estar tranquilo porque Git mantiene un historial continuo de todos los cambios en mis organizaciones de Salesforce. Si eliminara BookPrice.cls por accidente, no habría problema, porque podría consultar mi historial de Git, ver lo que había hecho antes y volver a agregarlo manualmente.

Para probar las solicitudes de implementación desde producción a entornos de desarrollo, crea una cuenta en https://manage.bluecanvas.io.

‍