Desde hace años en mis desarrollos hago Trunk-Based Development (TBD) y también «evangelizo» en esta técnica. Pero lamentablemente me suelo encontrar que en muchos casos los equipos no se encuentran en condiciones para trabajar de esta forma. TBD requiere del uso simultáneo de un conjunto de técnicas complementarias sin las cuales su utilización resulta impracticable (o demasiado riesgosa). Obviamente que también están los «detractores» que creen que TBD «no funciona» o que «no es bueno», resulta curioso que muchos de estos detractores nunca probaron TBD seriamente.
En fin, el tema es que si no utilizamos TBD hay que buscar otra alternativa. Dos técnicas bastante populares en la actualidad son Gitflow y GitHub flow. Adicionalmente hay una práctica que he visto bastante difundida de asociar branches a ambientes la cual está bien para proyectos chicos/triviales pero que personalmente me parece inconveniente para proyectos más grandes/complejos.
Actualmente estoy colaborando con un equipo que digamos no está en condiciones de hacer TBD (o dicho de otra forma: al cual aún no logré convencer de hacer TBD). Sin embargo el modelo de branching que hemos acordado me resulta bastante convincente. La cuestiones es así:
- Para desarrollar cada funcionalidad se crear un branch (feature branch) a partir de la rama principal(main).
- En cada commit+push se ejecuta el linter y un conjunto de pruebas «unitarias/de componentes» automatizadas.
- Una vez el developer completa la funcionalidad (code complete), se genera un tag, una imagen docker y la misma es desplegada a un ambiente de prueba (existen varios ambientes de prueba) donde se realizan pruebas manuales.
- Al mismo tiempo se instancia un arnés de prueba armado con docker, donde se ejecutan un conjunto de pruebas de aceptación automatizadas.
- Si la prueba manual y las pruebas de aceptación automatizadas resultan exitosas, la rama es integrada en la rama principal, la imagen docker es promovida (no se la vuelve a buildear) y es desplegada a un ambiente de staging.
- En staging se realizan otro conjunto de pruebas (con datos más parecidos a los productivos) y todo está ok, la imagen se vuelve a promover y queda lista para ir a producción.
Si, es un clásico esquema de feature branch pero con «condimentos» que en muchos equipos no están presentes. Destaco aquí las pruebas automatizadas, el arnés de prueba «portable» creado con docker y el hecho de que la imagen docker se crea una única vez y es promovida a medida que pasa de un ambiente a otro.
Blog de NicoPaez 
Me genera dudas como llamar a este modelo de branching, y tambien me genera dudas saber que diferencia tiene con el modelo de TBD, o sea, el modelo de branching es un esquema y el modelo de build y deploy de dichos branch pueden llegar a ir por otro carril. En tu explicacion yo veo un TBD con el build y test desde el feature branch y no desde main, estoy equivocado? como lo llamarias?
Hola Diego, en TBD todo el mundo trabaja simultáneamente sobre la misma rama. En este modelo que intento explicar, el desarrollo ocurre en paralelo sobre varias ramas (típicamente cada funcionalidad se desarrolla en su propia rama y solo me mezcla a la rama principal una vez completa).
Ahí actualicé la imagen para explicitar que el desarrollo ocurre en paralelo en varias ramas.
El build y tests ocurre en cada rama, todo el tiempo y también antes del merge a main. Eso no quita que luego en main se vuelva a buildear/testear. Sin embargo en este caso, como trabajamos con docker, la imagen docker la generamos una única vez en la rama de del feature y luego simplemente promovemos esa imagen.
Hola Nico, ahora entiendo mejor el grafico, basicamente cada desarrollador trabaja en un feature branch (puedes varios trabajar en el mismo) y al finalizar se buildea la imagen y se mergea a Main, el paso que indicas de (update feature branch with stable changes) entiendo que debe de ser automatico, y en todas las ramas vivas al momento, es asi??. Si no es asi hay un riesgo en generar la imagen desde el feature branch y no considerar cambios de otras ramas. Podria ser una mejora que la imagen en lugar de generarse desde el feature branch se haga desde main al momento del merge?
La imagen se genera en el feature branch porque una vez generada se levanta un arnés de prueba con docker-compose y se corren tests e2e en la imagen generada. si los tests fallan, entonces no se hace el merge