Partimos inicialmente con el deseo y con la convicción de que la Integración Contínua en Salesforce es completamente necesaria, y esa convicción, a pesar de los retos y condicionantes observados, sigue intacta.
Lo que ha cambiado completamente, es la simplificación con la que se habla y se predica la adopción de este proceso en modo DIY (Do it Yourself).
Hemos visto en las entradas previas, varias necesidades para implementar el proceso de integración contínua automatizado en Salesforce.
Veamos cual es el proceso para desplegar en una ORG.
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).
Una vez decidido que la Metadata API, es el camino a seguir, hay que entender las nociones básicas.
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:
Vincent Driessen en su blog GitFlow- A successfull Branching Model, describe el casi proceso de facto que aplican muchos equipos de desarrollo para la gestión de ramas (aunque prefiero la explicación y gráficos de AtlassiangitFlow Workflow.)-.
En esta entrada, intento explicar por qué, al menos en mi caso, no es directa su aplicación en un proyecto de Salesforce y las consideraciones adicionales y conclusiones a las que he llegado.
