4.1 Introducción al continuous delivery + GitFlow Tema 4: Continuous delivery
Valores del desarrollo ágil Valor del manifiesto ágil: Working software El proyecto crece incrementalmente, con un flujo continuo de cambios Entregas rápidas para obtener feedback lo antes posible Optimizar el flujo desde que se empieza una historia hasta que se entrega (Kanban) 2
La última milla 3
No es ágil Tardar 6 semanas en integrar un macro-proyecto formado por 5 proyectos independientes porque no se habían probado las conexiones entre los módulos Tardar 3 semanas en lanzar una nueva versión de un proyecto porque se han detectado fallos al instalarlo en el entorno de producción Tener que esperar 1 semana a que se realicen todas las pruebas de aceptación al nuevo release antes de seguir desarrollando nuevas funcionalidades en el proyecto 6 semanas JAR Entorno de integración Entorno de producción Build JAR JAR Deploy Tests OK JAR Build JAR JAR Deploy Base de datos de integración Base de datos de producción 4
Netflix como ejemplo ágil Deploying the Netflix API 5
Etsy como ejemplo ágil Etsy s Product Development with Continuous Experimentation 6
Etsy como ejemplo ágil Etsy s Product Development with Continuous Experimentation 7
Qué es continuous delivery? Conseguir una puesta en producción (release) del software: Poco arriesgada Frecuente Barata Rápida Predecible Reproducible Reduce the cost, time, and risk of delivering incremental changes to users Jez Humble - Adopting Continuous Delivery How long would it take your organization to deploy a change that involved just one single line of code? Do you do this on a repeatable, reliable basis? Mary and Tom Poppendieck - Implementing Lean Software Development, p59. 8
DevOps Developers Su trabajo es añadir nuevas características Trabajan en entornos locales ( en mi máquina funciona ) Utilizan herramientas y lenguajes que permiten abstraer y automatizar Operations: Su trabajo es mantener el sitio web seguro, estable y rápido Detectar problemas, apagar fuegos DevOps: nueva filosofía de trabajo, donde los desarrolladores y operadores trabajan en conjunción Automatización Infrastructure-as-code Herramientas: Chef, Vagrant, 9
Ventajas del continuous delivery Estabilidad y confiabilidad en el proceso de despliegue y lanzamiento Feedback continuo Cuanto antes se detecta un error es más fácil encontrar el fallo (Time to Resolve) Mejora la calidad del producto 10
Algunas técnicas Pequeños cambios que se despliegan continuamente Todos los builds son candidatos al release Todo en el control de versiones (se debe poder probar cualquier release) Tuberías de despliegue (deployment pipelines) Integración continua: automatización de builds, tests, despliegues, entornos 11
Pequeños cambios que se despliegan continuamente John Allspaw - http://www.slideshare.net/jallspaw/ops-metametrics-the-currency-you-pay-for-change 12
13
14
15
16
17
Time To Resolve 18
Y los grandes cambios? Los incrementos pequeños no significan dejar de trabajar en características que necesiten muchas modificaciones Es posible ir desarrollando, probando y colocando las piezas para que el sistema evolucione hacia un momento futuro en sea fácil introducir una característica totalmente nueva Buen diseño de código, por ejemplo seleccionar una implementación concreta utilizando interfaces y factorías Pequeños cambios en las APIs compatibles con los tests de regresión Interruptores de características 19
Ejemplo con interfaces y factorías Core J2EE Patterns - Data Access Object 20
Implementación concreta 21
Selección de la factoría concreta 22
Interruptores de características Feature toggles En inglés: feature toggles Etsy s Product Development with Continuous Experimentation 23
Interruptores de características 24
Botón de release El sistema de continuous delivery debería permitir que en cualquier momento negocio pulsara el botón de release y pudiera poner en producción el build seleccionado El sistema de entregas continuas nos asegura de que todos los builds disponibles ya han pasado con éxito todos los tests de la tubería de despliegue (deployment pipeline) 25
Puesta en producción Amazon Web Services - Elastic Load Balancing 26
Sistema de canary releases 27
Deployment pipeline Una implementación automatizada del proceso de: construir desplegar probar lanzar nuestro sistema Una tubería de despliegue garantiza: Visibilidad Feedback Control 28
Cambios moviéndose a través de la tubería de despliegue Jez Humble - Continuous Delivery 29
Trade-offs en la tubería de despliegue Jez Humble - Continuous Delivery 30
Tubería de despliegue básica Jez Humble - Continuous Delivery 31
Herramientas visuales Go - ThoughtWorks Jenkins / Hudson 32
Prácticas de la tubería de despliegue Solo construir los binarios una vez Desplegar de la misma forma en todos los entornos Smoke-Test Your Deployments Desplegar en una copia de producción Cada cambio debería propagarse instantánemente por la tubería Si falla cualquier parte de la tubería, parar la cadena 33
Sistema de Control de Versiones - Git El primer elemento de un sistema de continuous delivery es un sistema de control de versiones Git es un Sistema de Control de Versiones Distribuido (DVCS en inglés) Permite clonar repositorios, hacer commits en la versión clonada y publicar los cambios, sincronizando los commits Una de las características principales de Git es la facilidad de gestión de ramas y de forks Gran variedad de posibles flujos de trabajo 34
Ramas en git (1) 3 1 2 4 Git Documentation - Basic Branching and Merging 35
Ramas en git (2) 5 6 36
Merge 6 7 37
Flujos de trabajo Distintas opciones posibles Recomendación de Fowler y Humbler: Everyone Commits To the Mainline Every Day Una única rama de desarrollo principal, en la que todos los desarrolladores hacen commit a diario La rama de desarrollo se despliega diariamente en el servidor de integración continua Ventaja: los errores se encuentran rápidamente y hay una sensación de progreso compartido Es posible definir short-lived branches, ramas locales en las que se trabaja durante unos pocos días y que después se integran en la rama principal 38
Línea principal con short-lived branches 1 2 3 Atlassian Git Tutorials - Feature Branch Workflow 39
GitFlow (1) Git es descentralizado Vincent Driessen - A successful Git branching model 40
GitFlow (2) Dos ramas long-lived: master (donde van los releases) y develop (donde está el último build) Ramas con características en develop Vincent Driessen - A successful Git branching model 41
GitFlow (3) Ramas de release Vincent Driessen - A successful Git branching model 42
GitFlow (4) Ramas con Fixes Vincent Driessen - A successful Git branching model Atlassian Git Tutorials - Gitflow Workflow 43
GitFlow 44
Posibilidad de recuperar cualquier release El sistema de control de versiones permite poder recuperar cualquier release previa, probarla y reparar bugs que pueda contener Las versiones tienen nombres únicos (números correlativos) en un sistema de control de versiones En el SCV se guarda toda la información adicional: ficheros de configuración de la aplicación, configuración de los distintos entornos en los que se va a desplegar la aplicación Necesaria la automatización de la construcción de entornos de despliegue a partir de la información en el SCV 45
Lecturas Jez Humble - Continuous Delivery, cap. 5 (pp. 105-120) Atlassian Tutorials - Syncing Atlassian Tutorials - Comparing Workflows Vincent Driessen - A successful Git branching model 46