Integración Continua en Salesforce (1): Introducción

Esta entrada inicia una serie en la que muestro el proceso de mi adopción de Integración continua en Salesforce. Para la mayoría, no aporta ningún conocimiento nuevo, pero sirve para sentar las bases comunes.

Las entradas de la serie son:

1. Introducción (esta entrada)
2. Descripción de la metadata
3. Proceso y uso de la herramienta de despliegue
4. Orquestación y visión completa
5. Conclusiones Finales y recomendaciones

Únicamente me centraré en un aspecto concreto, como traspasar los cambios realizados en configuración y programación entre entornos de un proyecto de Salesforce (dejando de lado, gestión de datos maestros, automatización de pruebas, análisis de calidad de código, % de alineación de best practices, etc.).

El entorno en el que se describe esta serie, puede ser el de cualquier proyecto de tamaño medio en cualquier empresa:

• Sandboxes disponibles y mapa de entornos adecuados
• Se utiliza GitFlow adaptado a Salesforce comentado en la entrada anterior
• La gestión del proyecto utiliza una metodología ágil, formada por springts de entre 2 y 3 semanas, con los que no se pretende llegar a Producción, hasta final de proyecto
• Los equipos involucrados en Salesforce, son muy competentes en la administración y programación de Salesforce, y tienen expertise en Integración Continua

Mecanismos de traspase de cambios habituales en Salesforce

Dado este punto, repaso brevemente las opciones disponibles en Salesforce:

1. John Wayne: se intenta replicar todos los cambios a mano, recordando lo que he modificado yo y mis compañeros (por suerte no vemos gente por la calle con gorro de vaquero y pistola en cinto)
2. Change Sets: ampliamente conocidos
3. Unmanaged Package: mediante publicación privada, y comunicación de link de descarga
4. Managed Package: como si se realizara una instalación de una App de terceros
5. Uso de la Metadata API via Force.com IDE o Force.com Migration Tool o cualquier otra herramienta que la implemente

Al plantearse las opciones anteriores, tanto consultores de Salesforce, como toda la documentación oficial, concluyen que la opción deseable, automatizable, escalable, etc., a nivel empresarial es el uso de Metadata API conjuntamente con otras herramientas.

Los argumentos para esa conclusión son realmente de peso, y se basan en las limitaciones importantes:

•  Change Sets: debes mantener una lista de los cambios realizados, se olvidan dependencias, no es automatizable, agrupaciones de objetos sin relación y mucho volumen producen errores inesperados, requieren que las ORGS tengan conexiones establecidas, se requieren pasos Pre y Post, no se pueden eliminar objetos, etc.
• Unmanaged Package: debes mantener una lista de los cambios realizados, se olvidan dependencias, no permite instalar objetos con el mismo nombre, algunos quedan no actualizables en el futuro, no es automatizable, el proceso de publicación es tedioso
• Managed Package: casi inviable en un entorno empresarial, al quedar el código oculto

Seguro que hay bastantes más, si quieres comentarlas te lo agradezco.

Conclusiones Iniciales sobre las opciones

Quizás podemos resumir que todas estas variantes sufren de 3 grandes defectos.

1. Requieren una gestión y registro paralelo de las modificaciones realizadas (si no lo hago, debo recorrer el Audit Trail y esperar hacer una lista suficientemente completa)
2. No son automatizables en un proceso típico de Integración Continua
3. No aseguran un proceso idempotente: realizar el mismo despliegue varias veces y conseguir el mismo resultado como si se realizase una sola vez

Por tanto, aunque estas opciones pueden tener su utilidad en ciertos escenarios, no parecen ser, las recomendadas para un entorno empresarial, sinó, que la opción de la Metadata API será la opción deseada.

Camino al Valley of Death

…puedes pensar «voy por buen camino«, pero realmente, acabas de entrar en el Valley of Death. En la siguiente entrada, Integración Continua en Salesforce – Descripción de la Metadata,  lo podrás ver.

Enlaces interesantes

• Development Lifecycle Guide – Enterprise Development on the Force.com Platform

Anuncio publicitario