En los últimos tiempos es una tendencia habitual en muchos equipos utilizar git flow y pull request como estrategia de gestión de versiones. Estas estrategias son por supuesto muy útiles en algunos contextos pero no son ni la única opción ni la mejor opción para según qué casos.
Explicaremos cuales son los inconvenientes de este modelo y como nos alejan de tener un integración verdaderamente continua y del santo grial del deploy continuo. Hablaremos de otras alternativas como el Trunk Based Development (aka "to pa master") y de qué condiciones se tienen que dar en el equipo y en el proyecto para que esto último no suene a locura.
3. Un poquito de historia…
El mundo salvaje
Código en dispositivos de almacenamiento compartido
El inicio de la civilización
Empezamos a usar SVCS como CVS o Subversion
Lo locura moderna
Se popularizan los DVCS como Git o Mercurial
6. Y entonces… ¿integración continua?
A branch is, by-design, intended to hide change in one part of the code from other
developers. It is antithetical to CI - Dave Farley
Feature Branching is very nice from the perspective of an individual developer, but
sub-optimal from the perspective of a team - Dave Farley
Pair
TDD
CI
8. Y entonces… ¿El lead time y el cycle time?
LT: tiempo desde el inicio hasta el fin del
workflow
CT: intervalo entre dos entregas consecutivas
Aumentamos el tamaño del problema de integración
La incertidumbre para el final, no podemos saber cuánto falta para terminar.
Y para mejorar todo: Pull Request.
9. Pull Request
Herramienta pensada para trabajar en un entorno
asimétrico y deslocalizado, con un nivel de
interacción bajo entre los desarrolladores.
10. ¿Cual es mi objetivo con la PR?
¿Asegurar que el cambio no rompe el sistema?
¿Hacer code review para mejorar la calidad?
¿Aprendizaje?
11. Pull Request
¿Una etapa asíncrona de validación justo antes de
terminar?
Las PRs pendientes de validar son, en términos de
lean, inventario
12. Y entonces… ¿mejora continua?
Cuando no nos cuestionamos una práctica perdemos la
oportunidad de mejorar
Cuando usamos prácticas que retrasan el dolor dejamos de
buscar la forma de eliminarlo.
13.
14. Trunk Based Development (TBD)
A source-control branching model, where developers collaborate on code in a
single branch called ‘trunk’, resist any pressure to create other long-lived
development branches by employing documented techniques. They therefore
avoid merge hell, do not break the build, and live happily ever after.
https://trunkbaseddevelopment.com/
15. Nuestro contexto
- Negocio
- Comercio online
- No morimos si hay un bug en producción
- Equipo técnico de 10 personas
- Prácticas XP
- ~500 deploys/mes, ~10 servicios
Definir master: master es la última versión del producto/proyecto. el “source of truth” del proyecto.
Modelos más complejos como git-flow:
La feature se integra con develop
Develop se integra con master a través de ramas de release
Es casi un estándar de facto:
Utilizando git-flow
O algunas variaciones custom más folklóricas...
http://www.davefarley.net/?p=247
Un mundo donde todo el mundo habla de Entrega continua y por otro lado el FB es la best practice, es un mundo loco, loco…
Entorno asimetrico desde el punto de vista del ownership del proyecto (proyecto OP donde hay mantainers y colaboradores), asimetrico desde el punto de vista del esfuerzo/horas de dedicación al proyecto (alguien manda un parche)
Si no nos planteamos alternativas, o nos llevamos las manos a la cabeza cuando nos proponen otra cosa. Entonces en que queda la mejora continua si hemos establecido el FB como un estándar de facto. Lo peor no es hacer FB, lo peor es hacer FB porque es lo que hay que hacer (es la best practice)
Pues no la rompas!, en serio, si la build se rompe se para la cadena de montaje (lean) y hay que parar hasta arreglarla. La única forma de aprender a arreglar una build es rompiéndola. La necesidad de arreglarla rápido nos ayuda a optimizarla. Builds más rápidas, mejores mensajes de error en la build, ¿Separación del proyecto en varios más pequeños? (esto puede ser a veces un problema más que una solución evaluar con cuidado, hacerlo sólo en caso de necesidad evidente)
Code reviews con código ya subido, clarificar objetivos, la code review es para mejorar la calidad interna no para asegurar el comportamiento del sistema, ¿por qué hacerlo antes de subir si la feature funciona?
Cuantos más branchs en paralelo más posibilidad de conflicto. El diseño y la separación de conceptos son los que permiten que un equipo grande trabaje en un proyecto, la solución está en el diseño no en el VCS.
Feature toggles dinámicos
Comparar resultados viejos con resultados nuevos
Pruebas en staging
Blue green deployments
Integrar migraciones
Cualquier commit puede ir a prod
Baby steps
El FT más sencillo es no llamar al código nuevo
Diferencia entre usar FT como herramienta para integrar cambios y no hacerlos visibles frente a tener un sistema con features activables/desactivables en caliente y configurable y bla,bla,bla
Si vas a refactorizar no rompas lo existente y luego montes lo nuevo. Monta lo nuevo en paralelo
Branch by abstraction como mecanismo para hacer un “branch” en código.
Ejemplo DB vs ES
creando HU más pequeñas, subdividiéndolas, creando ramas no por feature sino por tareas técnicas de la FT que dejen el sistema en un estado consistente