Continious delivery and contonious integration git Workflow
Resumen
En el presente articulo presentare una propuesta de estrategia de ramificación en git, orientado al continious delivery, afín a la cultura ágil.
La importancia de tener un manejo efectivo, entiéndase por efectivo que produzca el efecto deseado, de las ramas de git radica la eficacia de git, la cual depende a si mismo de este manejo.
Que es GIT ?
 |
| "Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency." |
Git es un sistema descentralizado de versionamiento basado en ramas. Su principal diferencia con otros sistemas de versionamiento radica en la forma en la que almacena los archivos. Git almacena los archivos completos, es decir que para un archivo, entre versión y versión no guarda las diferencias que existen. Los archivos son asociados con un punto de control, el cual se genera en el momento que se hace una confirmación(commit).
 |
| Cada uno de estos puntos representa un momento exacto del contenido depositado en un repositorio. |
Una rama es una referencia a un punto de control, que a modo de workCopy, permite que se generen nuevos puntos de control que solo afecten la rama en la que se este trabajando.
 |
| Cada rama dentro de git tiene un nombre que la identifica. |
Por defecto Git tiene una rama llamada master, que es la rama principal del sistema. A medida que se vayan realizando commits la rama ira creando puntos de control e ira "avanzando".
Pero, surge aquí una pregunta, ¿ que criterio se debe seguir a la hora de crear una nueva rama ?
La respuesta a esta pregunta no es solo una. No existe un único criterio para la creación de rama. La formulación de este criterio depende totalmente del proyecto y las condiciones del mismo (tamaño, metodología, recursos ...etc).
El éxito del trabajo coordinado a través de git radica en este criterio al que llamaremos, estrategia de ramificación.
En 3DVes trabajamos con metodologías ágiles de desarrollo, bajo el marco de trabajo propuesto por scrum, con ciertos ires y venires. Asi mismo nuestros proyectos, por lo general, demandan que hagamos "entregas" o revisiones casi semanales o mas tardar cada dos semanas. En este contexto elegimos una estrategia de ramificación basada en el concepto de "Contiuous Delivery".
 |
| Al momento de escribir este articulo aun seguimos en el desarrollo e implementacion de nuestro propio "flavor" de scrum |
"Continious Delivery" es la habilidad de incorporar todo tipo de cambios (features, bug fixes, experimentos ...etc) en producción o al cliente, sin errores y de forma ágil de forma sostenible.
Para saber mas de continuos deliver ir a https://continuousdelivery.com
Es por esto que tomamos el modelo de Skull Candy, un modelo simple, ágil y disciplinado.
¿Cuando se crea una rama?
La estrategia de ramificación presenta dos tipos de rama, cada una por cada "ambiente de desarrollo" que existe en el proceso:
- Ramas de desarrollo.
- Ramas de calidad.
Una rama de desarrollo sera creada por cada historia de usuario o defecto, de esta forma cada rama podría llegar a representar una entrega de valor para nuestro cliente. El nombre de la rama debe tener una convención que rápidamente nos permita remitirnos a smartsheet, sistema de gestión de requerimientos usado 3DVes, por ejemplo:
"FF134-LoginProblem"
Es esencial que los nombres de las ramas sean concretos y relacionados con el tema que va a desarrollar. Si no te sientes seguro acerca del nombre de una rama, discutelo con tus compañeros de trabajo. Es muy importante que en tu compañía o equipo de desarrollo lleguen a un estándar para el nombramiento de las ramas, que tenga en cuenta los eventos mas significativos dentro del desarrollo de software, Task, FastFix, Bug, Improvements, Refactoring, por nombrar algunos.
Toda rama que crees debe nacer de máster. De esta forma todo depende exclusivamente de lo que esta en producción, es decir de lo que el cliente esta usando. De la anterior afirmación podemos deducir que el contenido que esta en la rama máster y su historia es desplegable en ambiente de producción.
Es importante denotar que en el modelo de Skull Candy, el arreglo de un "bug" es tratado de la misma forma que el desarrollo de un nuevo feature.
¿Como mezclar una rama con master?
Nunca una rama de desarrollo se debe mezclar con master. Pero, entonces, ¿Como se promueven cambios a producción?
Uno de los principios del manifiesto ágil nos dice que nuestra prioridad mas alta es satisfacer al cliente. Para esto debemos garantizar que todo lo que este en producción sea de su agrado. En consecuencia no podemos permitir que un comportamiento no deseable sea percibido por nuestros usuarios finales.
Para poder mezclar una funcionalidad hacia máster, primero debemos crear una rama, que por su puesto parte de master, que se llamara QA (Quality Assurance) y mezclaremos nuestra rama de trabajo con ella. El objetivo de crear esta rama de QA, es el de probar que la funcionalidad mezclada sobre ella pueda ser liberada a los "Bussines Owners" (Product owner, test team, Board, stakeholders interesados en el proyecto), quienes deberán probar que la funcionalidad promovida a QA cumpla con los requerimientos de nuestro cliente.
 |
| Una rama sea cual sea su propósito siempre deriva de master (rama principal), tras cumplir con su objetivo esta no vuelve directamente a master sino que pasa por QA, donde debe ser aprobada por los stakeholders antes de pasar a master. |
Finalmente, si las funcionalidades desplegadas sobre QA son aprobadas, se hará un pull request, poniendo como base a master.
Dev Ops en acción !
En el momento que una rama finalmente es mezclada con master, es ideal que el contenido sea desplegado de forma automática e inmediata al ambiente de producción; Si todo en master esta bien, y ha sido aprobado por una muestra de usuarios finales, que dan fe de que la satisfacción del cliente es un hecho, ¿ por que no desplegar inmediatamente ?
Sin embargo esto no es sencillo, es necesario contar con DevOps en tu compañía, pero si es necesario para que en verdad exista el continious delivery.
Discusión y futuras publicaciones
Como se menciona antes, la presentada aquí no es la única estrategia de ramificación, ni siquiera es la mas famosa, pero de momento es la que mas se acomoda a las necesidades de nuestro equipo de desarrollo y nuestros clientes. Dicho esto, la discusión no esta cerrada y te invito a que por favor cuestiones esta estrategia y nos ayudes a mejorarla día a día.
En una futura publicación, es mi deseo, plasmar la mayor cantidad de casos de uso que se me puedan ocurrir y como la estrategia de ramificación reaccionaria ante tales casos. Así que si se te ocurre algún caso de uso bien retorcido, no dudes en dejarlo en tus comentarios.
Así mismo planeo escribir un post acerca de la integración de esta estrategia de ramificación con "Semantic Version".
!Agradezco mucho tu tiempo y espero que hayas aprendido algo de mi parte el día hoy¡
Nos vemos en la próxima !
En mi opinion personal me parece que gitflow te permite avanzar mas rapido, si brancheas siempre desde master haces como que los desarrolladores trabajen en features completos desde la perspectiva del cliente, ej. login, crear cita etc, y esto quiere decir features largos (o sea integraciones lentas), ademas de que para cooperar en el equipo tienes que esperar a que los cambios pasen por QA por lo que desarrollar simultaneamente entre varios es mas dificil debido a que el desarrollador no puede hacer una integracion peque;a con la que otros pudieran cooperar(master y QA), eso quiere decir que uno solo debe hacer una integracion grande (larga y lenta), creo que el brancheo debe de ver los features desde el punto de vista de los desarrolladores (crear endpoint tal, agregar acciones a tal endpoint) y despues traducir esos features a 'features desde el punto de vista del cliente' en el release el cual mandas a QA, la razon por la que no quieres integraciones lentas es porque el cambio es mas grande, si hay un error el debug es mas dificil (mas codigo a debugear), un cambio mas grande tambien significa mayor probabilidad de conflicto al juntar los dos branchesotes con 59 archivos cambiados de cada 'feature'
ResponderBorrarSaludos!
A lo que se refiere con 'continuous integracion' es que estas integrando pues continuamente o sea en cambios muy peque;os (infinitesimales teoricamente) no cada que tu usuario apruebe, un branch de desarrollo para una historia de usuario es demasiado grande el cambio y seguro se tarda como una semana en hacer por lo que no parece muy continuo.
BorrarMuchas Gracias por tu comentario Alan !
BorrarEstoy deacuerdo en que un "Feature", desde el punto de vista del usuario, puede ser algo muy grande.
Agradezco el enfoque y en mi siguiente publicacion acerca del tema lo corregire.