Esta entrada pertenece a una serie:
- Introducción
- Descripción de la metadata
- Proceso y uso de la herramienta de despliegue (esta entrada)
- Orquestación y visión completa
- Conclusiones Finales y recomendaciones
El proceso
Veamos cual es el proceso para desplegar en una ORG.
Despliegue por diferencias
El proceso de despliegue en Salesforce, a diferencia de, por ejemplo, en el mundo Java, no se realiza desplegando un fichero .ear/.war que contiene todos los componentes y sustituye de forma completa al anterior , sinó que se realiza mediante el despliegue de los componentes añadidos/modificados y listando aquellos que queremos eliminar, lo que se suele llamar incremental, por diferencias (en adelante usaré este último término).
Porque…
Aunque es técnicamente posible un despliegue completo, este, comporta riesgos y tiempos de procesamiento muy elevados.
Así, por ejemplo, para añadir el campo Rating en un objecto custom llamado Invoice, se realizaría un despliegue de toda la Metadata, afectando a toda la ORG (solo hace falta imaginar la incertidumbre en un proyecto productivo con los miles de usuarios).
La herramienta: Force.com Migration Tool de Salesforce
Por tanto, partiendo de la base que necesitamos desplegar por diferencias y queremos hacerlo dentro un de un entorno automatizado de Integración Continua, Salesforce nos ofrece realmente una única alternativa: Force.com Migration Tool (básicamente targets añadidos para ANT).
Pero siendo ANT, una herramienta de invocación de targets y tareas, debemos describir cuales seran todas las tareas a llevar a cabo para culminar un despliegue.
Descripción alto nivel de las tareas de un despliegue
El conjunto de tareas podría ser el siguiente listado:
- Ejecutar tareas Pre: tareas que necesitamos ejecutar antes del despliegue que no son automatizables con la herramienta
- Traspasar/Desplegar toda la nueva metadata
- Traspasar/Desplegar toda la metadata modificada
- Eliminar la metadata que haya sido sustraída
- Ejecutar tareas Post, si las hubiere
Aunque este listado puede resultar una obviedad (lo es), veamos como quedaría reflejado al adecuarlo a la Force.com Migration Tool, dado que el objetivo que perseguimos es desplegar los cambios de una Sandbox, que denominamos Origen, hacía otra Sandbox/ORG Destino.
Descripción de las tareas adecuadas a Force.com Migration Tool
Quedaría un listado tal que:
- Obtener toda la Metadata Origen: correspondiente a la Sandbox Origen, para ello veremos que con acceder a nuestro
- Obtener toda la Metadata Destino: correspondiente a la Sandbox Destino
- Identificar cual de esta Metadata es nueva, es decir, no existente en la ORG Destino (o lo que es lo mismo aquella que está en Origen y no en Destino)
- Identificar la Metadata cambiada: aquella que está presente en ambas Sandbox , pero que su contenido difiere
- Identificar la Metadata eliminada: aquella que estando en Destino, ya no está presente en Origen
- Desplegar la Metadata nueva y modificada (obtenida en el punto 3 y 4) en la Sandbox Destino
- Eliminar la Metadata en la Sandbox Destino para la Metadata identificada en el punto 5
Puede parecer que solo he cambiado palabras y añadido alguna tarea, pero realmente las tareas acaban de aterrizarse y transformándose en tareas complejas.
Análisis de cada una de las tareas técnicas identificadas
Voy a analizar cada una de las tareas comentadas anteriormente, por favor sigue leyendo, ahora viene la chicha de verdad.
Paso 1: Obtener la metadata de la Sandbox Origen
Partiendo de la base que trabajamos con una herramienta de control de versiones (Bitbucket o Git en mi caso), y partiendo de la idea de Version control is the source of the truth, esta tarea consiste en realizar un Pull de la última versión de la rama correspondiente a este entorno.
De este Pull, obtendremos en nuestro sistema de ficheros, cientos de ficheros y directorios con la Metadata, tal y como expliqué en el artículo anterior (Descripción de la Metadata).
Existen muchas opciones para descargar el contenido de una rama de Bitbucket, pero lo más habitual, es el uso de un plugin, para la herramienta de orquestación del proceso (Hudson/Jenkins/etc.) que tengamos, simplificando así la tarea.
Paso 2: Obtener la metadata de la Sandbox Destino
Invocando el target sf:retrieve de la Force.com Migration Tool, con el fichero package.xml adecuado, se obtiene toda la Metadata de la ORG.
Aquí la palabra crucial es adecuado: el contenido del fichero package.xml indica que objetos queremos obtener de la ORG, y sería trivial, si pudiéramos indicar “TODOS LOS OBJETOS”, pero desafortunadamente esto no es posible.
Por tanto, la generación de un package.xml adecuado es la clave de este proceso, veamoslo a continuación.
Generación de un package.xml adecuado
Su formato, que está definido por Salesforce, está íntimamente relacionado con la Metadata API, y tiene particularidades que deben conocerse (https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/manifest_samples.htm).
No existe una definición formal de este fichero, ni un XSD relacionado. Existen, en mi experiencia 3 opciones viables de generación:
- Uso de Plantilla genérica con Wildcards: en la comunidad de Salesforce, se han definido plantillas pre-construidas que permiten simplificar la creación de este fichero. Una de las más usadas y conocidas es la de JitendraZaa.
- Generado a partir de una herramienta: utilizando Force.Com IDE (Eclipse con Plugin) y seleccionando Select All genera un package.xml para la descarga completa de la Metadata. Hace uso extensivo de Wildcards también.
- Generado a partir de una herramienta sin Wildcards: si no nos sentimos cómdos con el suo de Wildcards, existen herramientas como Package Builder disponible en Heroku, que generan un package.xml sin Wildcards, de todos los elementos de todos los tipos usados en la ORG. Su inconveniente es que si se crean nuevos elementos, el package.xml deja de ser válido y hay que regenerarlo cada vez.
Con cualquiera de las opciones anteriores, el resultado esperado vuelve a ser la descarga de cientos de ficheros y directorios en nuestro sistema de ficheros.
Paso 3: Identificar la nueva Metadata
Dado que tenemos en nuestro sistema de ficheros toda la metadata de las 2 ORGs, el tarea se simplifica en la búsqueda de ficheros nuevos mediante comparación
Paso 4: Identificar la Metadata modificada
Análogamente, debemos localizar aquellos ficheros que no son iguales/idénticos/equivalentes en la estructura de Origen y Destino.
Paso 5: Identificar la Metadata eliminada
Finalmente, este paso consiste en la búsqueda de ficheros existentes en la estructura Destino que ya no existen en Origen.
Pasos 6 y 7: Desplegar la Metadata nueva, modificada y eliminada
Para la ejecución del despliegue es necesaria la ejecución de una secuencia de acciones, como la siguiente:
- Creación de una estructura de directorios para el despliegue
- Creación del fichero package.xml correspondiente a la estructura anterior
- Creación de la estructura de los ficheros eliminados
- Creación del fichero destructiveChanges(Pre-Post).xml
- Ejecución de sf:deploy de la Force.Com Migration Tool con un fichero ZIP de los contenidos generados de 1 a 4.
Para cada uno de estos 5 pasos, podría detallar lo que se requiere, pero la entrada es suficientemente larga, y creo que no es necesario más castigo!
También debo confesar, que en aras de simplificar el proceso, he modificado el proceso real, evitando el uso de la rama Destino. En el proceso real, el despliegue se realizaría solo ante un Merge desde la rama Origen a la Destino (me he tomado esa licencia porque creo que se entiende mejor así).
Conclusiones
He intentado, desgranar las tareas que van apareciendo cuando se detalla y se profundiza en lo que habitualmente se simplifica en pocas frases.
En mi opinión, las debilidades en este proceso son numerosas, y me atrevo a destacar algunas:
- El paradigma de despliegue no es el habitual, sino por diferencias
- La fiabilidad del proceso recae en la capacidad de generación de un fichero package.xml sin una definición clara ni documentación asociada
- La fiabilidad del proceso recae en la capacidad de comparar ficheros:
- donde falsos positivos (identifico ficheros que no son iguales, pero que son equivalentes), suponen algo de rework,
- pero los falsos negativos (ficheros que no son equivalentes – cambio en metadata) supone no desplegar toda la metadata
- La fiabilidad del proceso está sujeta (en mi caso fueron +2000 líneas Java) a programación para llevar a cabo todas estas tareas. Dicho de otra manera, desplegar en Salesforce requiere programar/scripting en otro lenguaje.
En este punto, es cuando ya he avanzado bastante en el camino y abandono la idea inicial de implementar «un proceso simple para la integración continua en Salesforce» para entrar en el terreno de «proceso complejo» o dicho de otra manera, ya me veo entrando en el Valle.
En la siguiente entrada,veremos como orquestrar todas estas tareas con herramientas como Hudson/Jenkins y concluiremos el proceso.
Siento la longitud de la entrada.
Enlace adicionales:
Forcegraells 
[…] Proceso y uso de la herramienta de despliegue […]
Me gustaMe gusta