SlideShare una empresa de Scribd logo
1 de 30
¿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!

Más contenido relacionado

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

Bilbostack 2020 - El camino de l a entrega en DevOps
Bilbostack 2020 - El camino de l a entrega en DevOpsBilbostack 2020 - El camino de l a entrega en DevOps
Bilbostack 2020 - El camino de l a entrega en DevOpsLuis Fraile
 
Que demonios es eso de Devops (y porquedebería interesarme)
Que demonios es eso de Devops (y porquedebería interesarme)Que demonios es eso de Devops (y porquedebería interesarme)
Que demonios es eso de Devops (y porquedebería interesarme)Jacobo García López de Araujo
 
Sobre cómo gestionamos centenares de despliegues de VoIP
Sobre cómo gestionamos centenares de despliegues de VoIPSobre cómo gestionamos centenares de despliegues de VoIP
Sobre cómo gestionamos centenares de despliegues de VoIPIrontec
 
DevOps, por donde comenzar? - DrupalCon Latin America 2015
DevOps, por donde comenzar?  - DrupalCon Latin America 2015DevOps, por donde comenzar?  - DrupalCon Latin America 2015
DevOps, por donde comenzar? - DrupalCon Latin America 2015Taller Negócio Digitais
 
Devops meetup 10 diciembre 2014
Devops meetup 10 diciembre 2014 Devops meetup 10 diciembre 2014
Devops meetup 10 diciembre 2014 Eduardo Diaz
 
Introducción a Git
Introducción a GitIntroducción a Git
Introducción a GitSergio Rus
 
Charla XVII Beta Beers Sevilla: ¿Ágil? Como la rodilla de un click
Charla XVII Beta Beers Sevilla: ¿Ágil? Como la rodilla de un clickCharla XVII Beta Beers Sevilla: ¿Ágil? Como la rodilla de un click
Charla XVII Beta Beers Sevilla: ¿Ágil? Como la rodilla de un clickDiego Freniche Brito
 
Gwt seminario java_hispano_manolocarrasco
Gwt seminario java_hispano_manolocarrascoGwt seminario java_hispano_manolocarrasco
Gwt seminario java_hispano_manolocarrascoManuel Carrasco Moñino
 
Retos en la Adopción del Refactoring - Junta General del MexALN 28/06/2012
Retos en la Adopción del Refactoring - Junta General del MexALN 28/06/2012Retos en la Adopción del Refactoring - Junta General del MexALN 28/06/2012
Retos en la Adopción del Refactoring - Junta General del MexALN 28/06/2012Alfredo Chavez
 
Devops meetup 21 de Junio 2017
Devops meetup 21 de Junio 2017Devops meetup 21 de Junio 2017
Devops meetup 21 de Junio 2017Eduardo Diaz
 
BancaCivica.es: Un caso de éxito Drupal en el sector bancario
BancaCivica.es: Un caso de éxito Drupal en el sector bancarioBancaCivica.es: Un caso de éxito Drupal en el sector bancario
BancaCivica.es: Un caso de éxito Drupal en el sector bancarioDavid Gil Sánchez
 
Charla Roberto Canales Codemotion 2017 Madrid
Charla Roberto Canales Codemotion 2017 MadridCharla Roberto Canales Codemotion 2017 Madrid
Charla Roberto Canales Codemotion 2017 MadridRoberto Canales
 

Similar a ¿Eres ágil? ¡Pues no te vayas por las ramas! (20)

"Al rico" PHP
"Al rico" PHP"Al rico" PHP
"Al rico" PHP
 
Gwt I - entendiendo gwt
Gwt I - entendiendo gwtGwt I - entendiendo gwt
Gwt I - entendiendo gwt
 
Introducción a microservicios
Introducción a microserviciosIntroducción a microservicios
Introducción a microservicios
 
Bilbostack 2020 - El camino de l a entrega en DevOps
Bilbostack 2020 - El camino de l a entrega en DevOpsBilbostack 2020 - El camino de l a entrega en DevOps
Bilbostack 2020 - El camino de l a entrega en DevOps
 
Que demonios es eso de Devops (y porquedebería interesarme)
Que demonios es eso de Devops (y porquedebería interesarme)Que demonios es eso de Devops (y porquedebería interesarme)
Que demonios es eso de Devops (y porquedebería interesarme)
 
Sobre cómo gestionamos centenares de despliegues de VoIP
Sobre cómo gestionamos centenares de despliegues de VoIPSobre cómo gestionamos centenares de despliegues de VoIP
Sobre cómo gestionamos centenares de despliegues de VoIP
 
DevOps, por donde comenzar? - DrupalCon Latin America 2015
DevOps, por donde comenzar?  - DrupalCon Latin America 2015DevOps, por donde comenzar?  - DrupalCon Latin America 2015
DevOps, por donde comenzar? - DrupalCon Latin America 2015
 
Devops meetup 10 diciembre 2014
Devops meetup 10 diciembre 2014 Devops meetup 10 diciembre 2014
Devops meetup 10 diciembre 2014
 
Joomla! v3 - Presentación
Joomla! v3 - PresentaciónJoomla! v3 - Presentación
Joomla! v3 - Presentación
 
Introducción a Git
Introducción a GitIntroducción a Git
Introducción a Git
 
Charla XVII Beta Beers Sevilla: ¿Ágil? Como la rodilla de un click
Charla XVII Beta Beers Sevilla: ¿Ágil? Como la rodilla de un clickCharla XVII Beta Beers Sevilla: ¿Ágil? Como la rodilla de un click
Charla XVII Beta Beers Sevilla: ¿Ágil? Como la rodilla de un click
 
Gwt seminario java_hispano_manolocarrasco
Gwt seminario java_hispano_manolocarrascoGwt seminario java_hispano_manolocarrasco
Gwt seminario java_hispano_manolocarrasco
 
Grails barcamp 2013
Grails barcamp 2013Grails barcamp 2013
Grails barcamp 2013
 
Retos en la Adopción del Refactoring - Junta General del MexALN 28/06/2012
Retos en la Adopción del Refactoring - Junta General del MexALN 28/06/2012Retos en la Adopción del Refactoring - Junta General del MexALN 28/06/2012
Retos en la Adopción del Refactoring - Junta General del MexALN 28/06/2012
 
Devops meetup 21 de Junio 2017
Devops meetup 21 de Junio 2017Devops meetup 21 de Junio 2017
Devops meetup 21 de Junio 2017
 
BancaCivica.es: Un caso de éxito Drupal en el sector bancario
BancaCivica.es: Un caso de éxito Drupal en el sector bancarioBancaCivica.es: Un caso de éxito Drupal en el sector bancario
BancaCivica.es: Un caso de éxito Drupal en el sector bancario
 
Charla Roberto Canales Codemotion 2017 Madrid
Charla Roberto Canales Codemotion 2017 MadridCharla Roberto Canales Codemotion 2017 Madrid
Charla Roberto Canales Codemotion 2017 Madrid
 
Desarrollo de Software 2013
Desarrollo de Software 2013Desarrollo de Software 2013
Desarrollo de Software 2013
 
FULLSTACK JS DEV in 2017
FULLSTACK JS DEV in 2017FULLSTACK JS DEV in 2017
FULLSTACK JS DEV in 2017
 
Why what who when
Why what who whenWhy what who when
Why what who when
 

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

  • 1. ¿Eres ágil? ¡pues no te vayas por las ramas!
  • 2. Presentación de ponentes Alfredo Casado. Jefe Rubén Díaz Martínez. Señor mayor
  • 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
  • 4. Feature Branching Era Una rama por feature Se integra con trunk cuando está ¿terminada?
  • 5. 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!!)
  • 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
  • 16.
  • 17. Pero… la build se rompe muy a menudo
  • 18. Pero… si no tengo ramas no puedo hacer code review
  • 19. Pero… mi equipo es muy grande y eso no nos vale Cuadro de Mondrian Ramas de un equipo grande
  • 22. Pero… ¿y la base de datos? https://thoughtfulsoftware.wordpress.com/2016/10/03/database-migrations-for-zero-downtime-deployments/
  • 23.
  • 24.
  • 25. Mindset incremental Commit y push frecuente (trunk en local es una rama) Tests unitarios, TDD Builds rápidas Deploy frecuente
  • 26. Feature toggles Integra cambios sin hacerlos visibles Ten claro el objetivo
  • 28. Pero no seas loco Aprende las técnicas practicando Minimizar la duración de las ramas
  • 29. 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

Notas del editor

  1. 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...
  2. http://www.davefarley.net/?p=247
  3. 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…
  4. 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)
  5. 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)
  6. 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)
  7. 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?
  8. 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.
  9. Feature toggles dinámicos Comparar resultados viejos con resultados nuevos Pruebas en staging
  10. Blue green deployments Integrar migraciones
  11. Cualquier commit puede ir a prod Baby steps
  12. 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
  13. 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
  14. 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