entrega contínua en la práctica

Entrega Continua en la prácticaGeykel Moreno @geykel

gmoreno@thoughtworks.com

Carlos Fuentes @educharlief

cfuentes@thoughtworks.com

Capacitación

El proyectoy sus desafíos...

El cliente

● Empresa de servicios financieros○ Banca de inversión○ Broker-dealer○ Investigación○ Operaciones (Contabilidad, finanzas,

etc.)● Sucursales en varios países● Giro de negocios complejo

La calidad es importante

Nuestras aplicaciones se utilizan para:

● Cumplimientos legales○ En varias jurisprudencias

● Verificación de clientes● Cálculos de pagos financieros● Detección y aviso de discrepancias

Nuestro requerimiento

● Construir nuevos requerimientos RÁPIDAMENTE

● Respuesta a prioridades CAMBIANTES● Mantener ALTA la calidad

¡y hacerlo con un equipo de tamaño limitado!

Escenario inicialel antes...

Arquitectura monolíticaInicialmente:

● Fácil de desarrollar● Fácil de desplegar● Fácil de escalar

A medida que va creciendo la aplicación y el equipo:

● Difícil de entender● Modularidad se rompe con el tiempo● IDE sobrecargado, baja productividad● Obstaculiza el escalado del desarrollo● Difícil de escalar

Con el paso del tiempo (~5 años)

Aplicaciones a mantener:

● Hemos ido desde 5 aplicaciones a más de 40 aplicaciones, servicios y componentes

Tamaño del equipo:

● Bastante estable entre 12 y 16 desarrolladores, QA’s y BA’s

Entrega Continua

“es una disciplina de desarrollo de software donde construyes software de tal manera que puede ser entregado/desplegado a producción en cualquier momento” - Martin Fowler

¿Por qué adoptar?

● Reduce el riesgo del despliegue: pequeños cambios

● Progreso creíble: trabajo terminado medido por (el desarrollador dice que está terminado) es menos creíble que desplegado en producción

● Retroalimentación del usuario final

Reduce el tamaño de la entrega

Estás haciendo entrega continua cuando:

● El software es desplegable durante todo su ciclo de vida

● El equipo prioriza mantener el software desplegable sobre trabajar en nuevas funcionalidades

● Retroalimentación rápida y automatizada sobre la disponibilidad de los sistemas para producción en cualquier momento que alguien realice un cambio en ellos

● Realizar despliegues “push-button” de cualquier versión del software en cualquier momento hacia cualquier entorno bajo demanda

“Una prueba clave es que un ejecutivo del negocio solicite un despliegue de una

versión del software y no cunda el pánico”- Martin Fowler

Principios

● Crear proceso repetitivo y confiable para la entrega de software

● Automatizar todo lo posible● Mantener todo almacenado en un sistema

de control de versiones● Listo significa entregado● Todos son responsable de la entrega

Prácticas

● Compila tus artefactos sólo una vez● Pruebas automatizadas a todos los niveles● Realiza los despliegues de la misma manera

en todos los entornos● ‘Smoke test’ todos los despliegues● Mantener ambientes similares● Si algo falla, para todo

¡Automatiza casi todo!

Deployment pipeline

Entrega continua != Despliegue continuo

Despliegue continuo significa que cada cambio va a través del pipeline y es automáticamente puesto en producción (resultando en varios despliegues en el día)

Entrega continua significa que estás en la capacidad de realizar despliegues frecuentes pero puedes optar por no hacerlo (los negocios usualmente prefieren una frecuencia de despliegue más lenta)

Confianza en el código

Programación en parejas

Pruebas

BDD y TDD

Integración continua

● Usualmente se refiere a integrar, construir y probar el código dentro de un ambiente de desarrollo.

● Entrega continua se construye sobre este concepto manejando además las etapas requeridas para el despliegue a producción

Features toggles

Esconder funcionalidades

● Trabajo en progreso● Funcionalidades inestables● Estrategia de negocio

¿Cómo?

● Archivos de configuración● Variables de ambiente● Servicios externos

Escenario actual...el después

Automatización de las pruebas

Automatización de las pruebas

Automatización de builds

● Compilar el código fuente en código binario● Empacar el código binario● Correr las pruebas automatizadas● Desplegar en los diferentes ambientes● Crear documentación y release notes

● Rake○ Rake build○ Rake build deploy○ Rake test:unit, rake test:acceptance○ Rake pc

Automatización de builds

Automatización de builds

Automatizar los ambientes

Mejora Continua

Integración Continua

Radiador

KanbanHaz una sola cosa y hazlo bien

Kanban● kan, 看 カン, significa "visual," y ban, 板 バン,

significa "tarjeta" o "tablero"● Desarrollado por Taiichi Ohno, en Toyota● Kanban da a los equipos más opciones

flexibles de planificación, la producción más rápido, claro enfoque y la transparencia en todo el ciclo de desarrollo.

Kanban

Kanban - principios● Flexibilidad en la planificación

○ El equipo solo está enfocado en el trabajo en progreso

● Minimizar el ciclo de vida○ Tiempo medio para completar una

tarjeta● Eficiencia a través del enfoque

○ Multitarea mata la eficiencia● Tener métricas visuales

○ Mejora contínua

Kanban

Scrum vs Kanban

Kanban en el proyecto

Tarjetas

Automatizar la burocracia

Estructura del proyectoSer autónomo pero no sub optimizar

Squads

● “Se siente como una mini-startup”

● Auto organizada● Cross-functional● De 5 a 7 ingenieros,

menos de 10

¿Por qué elegir Squads?● > 40 proyectos● No está dividido geograficamente

Mejora contínua…

● Feedback ( Standups diarios)● Desplegar pequeña entregas desacopladas.● Personas T - shaped

SquadsPrácticas: ambiente amigable

al fallo

Alineamiento vs Autonomía

Alineamiento vs Autonomía

Squads

MétricasResultados...

Trabajo realizado por períodos

(períodos de 4 semanas)

Porcentaje de defectos

¿Preguntas?

La Biblia

Entrega Continua en la prácticaGeykel Moreno @geykel

gmoreno@thoughtworks.com

Carlos Fuentes @educharlief

cfuentes@thoughtworks.com

Gracias