Este documento describe cómo una empresa de servicios financieros adoptó prácticas de entrega continua para mejorar la calidad y velocidad de desarrollo de sus más de 40 aplicaciones. Inicialmente tenían una arquitectura monolítica que se volvió difícil de mantener, por lo que automatizaron pruebas, despliegues y ambientes usando integración continua, kanban, squads autónomos y métricas para medir el progreso. Esto les permitió entregar cambios con más frecuencia mientras mantenían alta calidad.

1. Entrega Continua en la
práctica
Geykel Moreno @geykel
gmoreno@thoughtworks.com
Carlos Fuentes @educharlief
cfuentes@thoughtworks.com
Capacitación

2. El proyecto
y sus desafíos...

3. 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

4. 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

5. Nuestro requerimiento
● Construir nuevos requerimientos
RÁPIDAMENTE
● Respuesta a prioridades CAMBIANTES
● Mantener ALTA la calidad
¡y hacerlo con un equipo de tamaño limitado!

6. Escenario inicial
el antes...

7. Arquitectura monolítica
Inicialmente:
● 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

8. 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

9. 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

10. ¿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

11. Reduce el tamaño de la
entrega

12. 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

13. “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

14. 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

15. 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

16. ¡Automatiza casi todo!

17. Deployment pipeline

18. 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)

19. Confianza en el código

20. Programación en
parejas

21. Pruebas

22. BDD y TDD

23. 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

24. Features toggles
Esconder funcionalidades
● Trabajo en progreso
● Funcionalidades inestables
● Estrategia de negocio
¿Cómo?
● Archivos de configuración
● Variables de ambiente
● Servicios externos

25. Escenario actual
...el después

26. Automatización de las pruebas

27. Automatización de las
pruebas

28. 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

29. Automatización de
builds

30. Automatización de
builds

31. Automatizar los
ambientes

32. Mejora Continua

33. Integración Continua

34. Radiador

35. Kanban
Haz una sola cosa y hazlo bien

36. 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.

37. Kanban

38. 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

39. Kanban

40. Scrum vs Kanban

41. Kanban en el proyecto

42. Tarjetas

43. Automatizar la
burocracia

44. Estructura del
proyecto
Ser autónomo pero no sub optimizar

45. Squads
● “Se siente como una mini-
startup”
● Auto organizada
● Cross-functional
● De 5 a 7 ingenieros,
menos de 10

46. ¿Por qué elegir Squads?
● > 40 proyectos
● No está dividido geograficamente
Mejora contínua…
● Feedback ( Standups diarios)
● Desplegar pequeña entregas desacopladas.
● Personas T - shaped

47. Squads
Prácticas: ambiente amigable
al fallo

48. Alineamiento vs
Autonomía

49. Alineamiento vs
Autonomía

50. Squads

51. Métricas
Resultados...

52. Trabajo realizado por
períodos
(períodos de 4 semanas)

53. Porcentaje de defectos

54. ¿Preguntas?

55. La Biblia

56. Entrega Continua en la
práctica
Geykel Moreno @geykel
gmoreno@thoughtworks.com
Carlos Fuentes @educharlief
cfuentes@thoughtworks.com
Gracias