¿Cómo lo hacemos?

• Definiendo una forma estandar de trabajar. Basado en http://nvie.com/posts/a-successful-git-branching-model/
• Usando las ventajas de GIT
• Política de BRANCHES
• Versionado
• Control estricto de los pasos a producción

versionado

Estandar X.YY.ZZ

• X -> Mayor versión
• YY -> Minor versión
• ZZ -> Patch

Pasos a producción

infinitas

develop

• Rama de desarrollo
• Cualquier funcionalidad nueva parte de esta rama y se mergea de nuevo aquí
• Jenkins configurado para ejecutarse contra ella

master

• Rama de producción
• Nunca se commitea en ella
• Jenkins configurado para ejecutarse contra ella, aunque nunca debería fallar ;-)

frontend

• Al principio del proyecto se maquetaba en ella
• Deprecada

temporales

Feature

• Para desarrollar nuevas User Stories
• Se crea a partir de develop y se mergea de nuevo a develop

Demo

Release

• Congelación y estabilización de versión candidata a subir a producción
• Se debe aumentar la versión (minor) y crear tag
• Se crea a partir de develop y se mergea de nuevo a master y develop
• Cualquier bug que haya que corregir para estabilizar la versión se commiteará directamente contra esta rama
• Está prohibido mergear cambios contra esta rama y tampoco añadir nueva funcionalidad

Demo

Hotfix

• Corrección de bugs de producción que no pueden esperar al ciclo de subidas normales
• Se debe aumentar la versión (patch) y crear tag
• Se crea a partir de master y se mergea de nuevo a master y develop

Demo

Problemas

• Funcionalidad no-plugable ni ordenable
• Árbol de commits "sucio" por los merges de develop a las ramas de features
• No hacemos rebase (aunque en su momento lo hicimos) y lo volveremos a hacer