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.

Hago un repaso muy muy breve, de las premisas de gitFlow:

• The master branch stores the official release history
• The develop branch serves as an integration branch for features
• Each new feature should reside in its own branch. But, instead of branching off of master, feature branches use develop as their parent branch. When a feature is complete, it gets merged back into develop
• Features should never interact directly with master.
• Once develop has acquired enough features for a release, you fork a release branch off of develop. Creating this branch starts the next release cycle, so no new features can be added after this point
• Once it’s ready to ship, the release gets merged into master and tagged with a version number.

¿Cómo mapeamos este proceso en un proyecto de Salesforce?

Supongamos un mapa de entornos de Sandboxes de un proyecto medianto tal que existen los entornos:

1. Desarrollo
2. Integración
3. QA / User Acceptance Test
4. Rendimiento / Formación / Pre-Producción
5. Producción

Además supongamos que nuestro proyecto/cliente introduce las siguientes restricciones (son las que me impongo para asegurar unas premisas de calidad del proceso de Integracioón Continua – cada uno tendrá las suyas pero creo que estas pueden ser comunes a todos nuestros proyectos):

1. No se puede realizar ningún trapaso a un entorno que no haya sido probado en un entorno anterior
2. Esto implica introducir el concepto de dependencia de entornos. Los entornos 1-2-3-4-5, los consideramos dependientes en cascada, es decir, no es posible incorporar nuevas funcionalidades a un entorno posterior, que no haya sido incorporada y probada en un entorno  anterior (aquí no entro en la cosnideración de correctivos urgentes, que siguen otro camino)
3. Todos los despliegues de funcionalidades deben proceder de una rama de la herramienta de control de versiones (aka Bitbucket), no es posible modificar el entorno directamente mediante manipulación de Setup y solo se permiten cambios de objetos no soportados por la metadata

Existen otras como replicación de datos maestros, replicación de configuraciones y objetos que no soporta la metadata, pero alargan esta entrada demasiado.

En esta situación se observa que, con 2 ramas en el gitFlow Workflow (+ ramas Feature) y con 5 entornos, y los condicionantes expuestos, el procedimiento debe adaptarse.

Una solución (propuesta)

Mi propuesta de solución es:

• Cada Sandbox tiene una rama en Bitbucket.
• Solo la rama de Desarrollo puede recibir Commits mediante Push
  
• El resto de ramas solo pueden recibir operaciones de Merge procedente de la rama precedente (cascada cacofónica :-)), forzando así que toda nueva funcionalidad, ha sido al menos desplegada en el entorno anterior (y esperemos validada satisfactoriamente por los equipos resposanbles)
• La operación de Merge, provoca un trigger del sistema de integración contínua, que ejecuta deploy por diferencias (artículo más adelante)
• Por tanto, la rama master, que corresponde al entorno de Producción, solo puede recibir nuevas funcionalidades de la rama que pertenece al entorno de Rendimiento / Formación / Pre-Producción
• Debe existir la figura del Release Manager que se responsabilice de este procedimiento y de evitar llaneros solitarios.

Hay varios temas que quedan en el aire como: despliegue de metadatos no soportados por la Metadata API, despliegue de Datos maestros, ni he mencionado la gestión de Hot Fix, pero espero que con la entrada pueda ayudar a los que se plantean usar gitFlow y plantearse como adoptarlo.