3 min de lectura
En el Capítulo 4: Seguimiento de lo que importa: KPIs y paneles, exploramos cómo la visualización del flujo de trabajo y la definición de los KPIs adecuados nos ayudaron a detectar cuellos de botella y a alinear a nuestros equipos en torno a la entrega de valor. Con una mejor visibilidad de nuestra canalización de DevOps, comenzamos a plantearnos preguntas más profundas: no solo dónde estaban los cuellos de botella, sino por qué ocurrían.
En el Capítulo 5, profundizamos en uno de los cambios técnicos y de procesos más significativos en nuestro recorrido de transformación: refinar nuestra estrategia de ramificación y habilitar el despliegue continuo. Estos cambios fueron fundamentales para resolver los retrasos persistentes entre el desarrollo y la producción.
Identificación del nuevo cuello de botella
Analizar el flujo de trabajo e identificar los cuellos de botella donde se acumula el trabajo ha sido un aspecto clave para lograr nuestra transformación de DevOps. Este enfoque en el flujo se encuentra en el centro de cómo aplicamos el triángulo de DevOps: herramientas, arquitectura y personas, para lograr una entrega más rápida y confiable.
A medida que avanzábamos en la mejora de la capacidad de prueba con una mayor cobertura de pruebas unitarias y automatización de pruebas, observamos que la calidad del código mejoraba, pero el cuello de botella seguía estando en la fase de pruebas de scrum. A pesar de los avances en la automatización de las pruebas, el trabajo seguía acumulándose y el cuello de botella se desplazó del desarrollo a las pruebas a nivel de sistema. Los indicadores clave de rendimiento (KPI) mostraron que el trabajo en curso por equipo durante el desarrollo disminuía, pero el código seguía atascándose en el punto de transición hacia las pruebas de sistema. Este retraso impedía, en última instancia, lograr un flujo fluido.
La causa principal: estrategia de ramificación y fusiones retrasadas
El análisis reveló que la causa principal de la acumulación residía en nuestra estrategia de ramificación. Los desarrolladores y evaluadores creaban ramas de características a partir de la rama principal al iniciar nuevas funciones. A medida que el código evolucionaba, los ingenieros enviaban sus cambios a ramas de características remotas para fusionar su trabajo con el de otros. Sin embargo, este código no se volvía a fusionar en la rama principal con la frecuencia necesaria.
Las tuberías de CI/CD se configuraron en la rama principal, ejecutando pruebas automatizadas y realizando despliegues en la nube, seguidas de pruebas de regresión. Sin embargo, dado que los cambios más recientes no se enviaban a la rama principal con regularidad, las ejecuciones de las tuberías se realizaban con código desactualizado, lo que las volvía redundantes e ineficaces.
La solución: ramas de características de corta duración
Para resolver esto, nos dimos cuenta de que era necesario afinar la estrategia de ramificación. Aunque las diferentes estrategias de ramificación tienen ventajas y desventajas, decidimos continuar con la estrategia de ramas de características, pero con un ajuste clave: ramas de características de corta duración que se fusionan de nuevo en la rama principal con mayor frecuencia.
La estrategia de ramas de características de corta duración ofrece varias ventajas, siendo el beneficio más crítico la mejora del flujo y la resolución de los cuellos de botella en el ciclo de desarrollo. Las ramas de menor duración garantizan que las fusiones de código sean más fáciles, rápidas y propensas a menos errores. Este enfoque también permite obtener comentarios más rápidos, lo que mejora la calidad general y la velocidad del proceso de desarrollo.
Despliegue continuo: el desafío de las tuberías
Configurar tuberías de despliegue continuo sólidas es una tarea compleja que requiere un enfoque enfocado e incremental. Según nuestra experiencia, contar con un equipo de plataforma dedicado para configurar y mantener estas tuberías es el enfoque recomendado, en lugar de hacer que cada equipo de scrum trabaje en ellas de manera individual. Si bien la propiedad final de las tuberías de entrega continua debe recaer en los equipos de scrum, la tarea inicial de configurarlas se beneficia enormemente de la ayuda de un equipo de plataforma dedicado.
Equipo de plataforma: reducción de la carga cognitiva y fomento de la concentración
Para inspirarnos en la estructuración de nuestro equipo de plataforma, recurrimos a Team Topologies, de Matthew Skelton y Manuel Pais. El libro enfatiza la importancia de contar con un equipo de plataforma dedicado que sea responsable de configurar y gestionar la infraestructura (en nuestro caso, las tuberías de CD). Esta estructura permite que los equipos de scrum se centren en el desarrollo de funciones, al tiempo que se benefician de una configuración de tuberías estable y estandarizada.
Como señala el libro:
«El equipo de plataforma es responsable de construir y mantener la plataforma interna que los equipos alineados con el flujo utilizan para entregar su trabajo. El propósito de la plataforma es reducir la carga cognitiva de los equipos alineados con el flujo para que puedan centrarse en aportar valor».
Al centralizar la responsabilidad de las tuberías, pudimos crear una plataforma compartida y común de la que los equipos alineados con el flujo pudieran depender. Esto nos permitió reducir la carga cognitiva en los equipos de desarrollo, permitiéndoles centrarse en aportar valor en lugar de lidiar con cuestiones de infraestructura.
Evolución de la plataforma para la mejora continua
Contar con un equipo de plataforma no se trata solo de configurar las tuberías, sino de evolucionar la infraestructura compartida y las herramientas con el tiempo. Un equipo de plataforma dedicado se encuentra en la mejor posición para realizar mejoras incrementales en la tubería de entrega continua, garantizando que permanezca alineada con las necesidades de los equipos y se adapte a medida que escalamos y crecemos. Esta evolución continua garantiza que la plataforma siga siendo fiable, escalable y eficiente, lo que permite a nuestros equipos trabajar al máximo.
Lo siguiente: automatización y comentarios
Con la ramificación optimizada y los despliegues fluyendo, pasamos a la última frontera en nuestro viaje de DevOps: automatización y comentarios. En el próximo y último capítulo, exploraremos cómo cerrar el círculo con información automatizada y comentarios rápidos transformó la forma en que operan nuestros equipos.
¡Manténgase atento!
