entrega contínua en la práctica
TRANSCRIPT
Entrega Continua en la prácticaGeykel Moreno @geykel
Carlos Fuentes @educharlief
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
Carlos Fuentes @educharlief
Gracias