¿Eres ágil?
¡pues no te vayas por las ramas!
Presentación de ponentes
Alfredo Casado. Jefe Rubén Díaz
Martínez. Señor mayor
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
Feature Branching Era
Una rama por feature
Se integra con trunk cuando
está ¿terminada?
Git Superheroes!
- git pull origin master
- git checkout -b <mi_feature>
- git commit… git commit… git push… git commit… git push…
- git log --graph --decorate --pretty=oneline --abbrev-commit
- git rebase -i HEAD[NUMBER OF COMMITS] or git rebase -i [SHA]
- git push origin <mi_feature> --force
- git pull origin master
- git checkout <mi_feature>
- git rebase master (resolvemos los posibles conflictos)
- git push origin <mi_feature> --force
- git merge <mi_feature>
- git push origin master (AL FIN!!)
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
Y entonces… ¿entrega continua?
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.
Pull Request
Herramienta pensada para trabajar en un entorno
asimétrico y deslocalizado, con un nivel de
interacción bajo entre los desarrolladores.
¿Cual es mi objetivo con la PR?
¿Asegurar que el cambio no rompe el sistema?
¿Hacer code review para mejorar la calidad?
¿Aprendizaje?
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
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.
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/
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
Pero… la build se rompe muy a menudo
Pero… si no tengo ramas no puedo hacer code review
Pero… mi equipo es muy grande y eso no nos vale
Cuadro de Mondrian
Ramas de un equipo grande
Pero… ¿cómo arreglo un bug?
Pero… ¿cómo pruebo las cosas?
Pero… ¿y la base de datos?
https://thoughtfulsoftware.wordpress.com/2016/10/03/database-migrations-for-zero-downtime-deployments/
Mindset incremental
Commit y push frecuente (trunk en local es una rama)
Tests unitarios, TDD
Builds rápidas
Deploy frecuente
Feature toggles
Integra cambios sin hacerlos visibles
Ten claro el objetivo
Parallel change
Pero no seas loco
Aprende las técnicas practicando
Minimizar la duración de las ramas
Recursos
- Feature Branching Considered Evil, Thierry de Pauw
https://vimeo.com/275529985
- Feature toggles - https://martinfowler.com/articles/feature-toggles.html
- Parallel Change - https://martinfowler.com/bliki/ParallelChange.html
- http://www.caroli.org/continuous-delivery-lead-time-and-cycle-time/
- http://www.davefarley.net/?p=247
¿Eres ágil? ¡Pues no te vayas por las ramas!

¿Eres ágil? ¡Pues no te vayas por las ramas!

  • 1.
    ¿Eres ágil? ¡pues note vayas por las ramas!
  • 2.
    Presentación de ponentes AlfredoCasado. Jefe Rubén Díaz Martínez. Señor mayor
  • 3.
    Un poquito dehistoria… 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
  • 4.
    Feature Branching Era Unarama por feature Se integra con trunk cuando está ¿terminada?
  • 5.
    Git Superheroes! - gitpull origin master - git checkout -b <mi_feature> - git commit… git commit… git push… git commit… git push… - git log --graph --decorate --pretty=oneline --abbrev-commit - git rebase -i HEAD[NUMBER OF COMMITS] or git rebase -i [SHA] - git push origin <mi_feature> --force - git pull origin master - git checkout <mi_feature> - git rebase master (resolvemos los posibles conflictos) - git push origin <mi_feature> --force - git merge <mi_feature> - git push origin master (AL FIN!!)
  • 6.
    Y entonces… ¿integracióncontinua? 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
  • 7.
  • 8.
    Y entonces… ¿Ellead 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 pensadapara trabajar en un entorno asimétrico y deslocalizado, con un nivel de interacción bajo entre los desarrolladores.
  • 10.
    ¿Cual es miobjetivo con la PR? ¿Asegurar que el cambio no rompe el sistema? ¿Hacer code review para mejorar la calidad? ¿Aprendizaje?
  • 11.
    Pull Request ¿Una etapaasíncrona de validación justo antes de terminar? Las PRs pendientes de validar son, en términos de lean, inventario
  • 12.
    Y entonces… ¿mejoracontinua? 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.
  • 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
  • 17.
    Pero… la buildse rompe muy a menudo
  • 18.
    Pero… si notengo ramas no puedo hacer code review
  • 19.
    Pero… mi equipoes muy grande y eso no nos vale Cuadro de Mondrian Ramas de un equipo grande
  • 20.
  • 21.
  • 22.
    Pero… ¿y labase de datos? https://thoughtfulsoftware.wordpress.com/2016/10/03/database-migrations-for-zero-downtime-deployments/
  • 25.
    Mindset incremental Commit ypush frecuente (trunk en local es una rama) Tests unitarios, TDD Builds rápidas Deploy frecuente
  • 26.
    Feature toggles Integra cambiossin hacerlos visibles Ten claro el objetivo
  • 27.
  • 28.
    Pero no seasloco Aprende las técnicas practicando Minimizar la duración de las ramas
  • 29.
    Recursos - Feature BranchingConsidered Evil, Thierry de Pauw https://vimeo.com/275529985 - Feature toggles - https://martinfowler.com/articles/feature-toggles.html - Parallel Change - https://martinfowler.com/bliki/ParallelChange.html - http://www.caroli.org/continuous-delivery-lead-time-and-cycle-time/ - http://www.davefarley.net/?p=247

Notas del editor

  • #5 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...
  • #7 http://www.davefarley.net/?p=247
  • #8 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…
  • #10 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)
  • #13 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)
  • #18 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)
  • #19 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?
  • #20 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.
  • #22 Feature toggles dinámicos Comparar resultados viejos con resultados nuevos Pruebas en staging
  • #23 Blue green deployments Integrar migraciones
  • #26 Cualquier commit puede ir a prod Baby steps
  • #27 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
  • #28 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
  • #29  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