,
3 min de lectura
En el Capítulo 4: Seguimiento de lo Importante – KPI y Paneles de Control, exploramos cómo la visualización del flujo de trabajo y la definición de los KPI adecuados nos ayudaron a identificar cuellos de botella y a alinear a nuestros equipos en torno a la entrega de valor. Con una mejor visibilidad de nuestro pipeline de DevOps, comenzamos a hacer preguntas más profundas, no solo dónde estaban los cuellos de botella, sino por qué estaban ocurriendo.
En el Capítulo 5, profundizamos en uno de los cambios técnicos y a nivel de proceso más significativos en nuestro viaje 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 el trabajo se acumula ha sido un aspecto clave para lograr nuestra transformación DevOps. Este enfoque en el flujo es fundamental en cómo aplicamos el triángulo DevOps —herramientas, arquitectura y personas— para lograr una entrega más rápida y fiable.
A medida que avanzábamos en la mejora de la capacidad de prueba con una creciente cobertura de pruebas unitarias y automatización de pruebas, descubrimos que la calidad del código estaba mejorando, pero el cuello de botella seguía estando en la fase de pruebas scrum. A pesar del progreso en la automatización de pruebas, el trabajo seguía acumulándose y el cuello de botella se trasladó 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 estaba disminuyendo, pero el código seguía atascándose en el punto de transición a las pruebas de sistema. Este retraso, en última instancia, nos impidió lograr un flujo fluido.
La causa raíz: Estrategia de ramificación y fusiones retrasadas
El análisis reveló que la causa raíz del retraso residía en nuestra estrategia de ramificación. Los desarrolladores y probadores estaban creando ramas de características a partir de la rama principal al iniciar nuevas funcionalidades. A medida que el código se desarrollaba, los ingenieros subían sus cambios a ramas de características remotas para fusionar su trabajo con el de otros. Sin embargo, este código no se fusionaba de nuevo con la rama principal con la suficiente frecuencia.
Las tuberías CI/CD se configuraron en la rama principal, ejecutando pruebas automatizadas y desplegándose en la nube, seguidas de pruebas de regresión. Sin embargo, dado que los últimos cambios no se enviaban a la rama principal con regularidad, las ejecuciones de las tuberías se realizaban con código obsoleto, lo que las hací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 ajustar la estrategia de ramificación. Aunque existen ventajas y desventajas en las diferentes estrategias de ramificación, 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 con 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 corta duración garantizan que las fusiones de código sean más fáciles, rápidas y menos propensas a errores. Este enfoque también permite una retroalimentación más rápida, lo que mejora la calidad general y la velocidad del proceso de desarrollo.
Despliegue Continuo: El Reto del Pipeline
Establecer sólidos canales de despliegue continuo es una tarea compleja que requiere un enfoque centrado e incremental. Según nuestra experiencia, contar con un equipo de plataforma dedicado para configurar y mantener estos canales es el enfoque recomendado, en lugar de que cada equipo scrum trabaje en ellos individualmente. Si bien la propiedad final de los canales de entrega continua debe recaer en los equipos scrum, la tarea inicial de configurarlos se beneficia enormemente de un equipo de plataforma dedicado.
Equipo de la plataforma: Reducir la carga cognitiva y permitir 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 tener un equipo de plataforma dedicado que es responsable de configurar y gestionar la infraestructura —en nuestro caso, los pipelines de CD—. Esta estructura permite a los equipos scrum centrarse en el desarrollo de funcionalidades, mientras se benefician de una configuración de pipeline estable y estandarizada.
Como afirma el libro:
“El equipo de la plataforma es responsable de construir y mantener la plataforma interna que los equipos alineados por flujo utilizan para entregar su trabajo. El propósito de la plataforma es reducir la carga cognitiva de los equipos alineados por flujo, para que puedan centrarse en entregar valor.”
Al centralizar la responsabilidad de los procesos, pudimos crear una plataforma compartida y común en la que los equipos alineados por flujo de trabajo podían confiar. Esto nos permitió reducir la carga cognitiva de los equipos de desarrollo, permitiéndoles centrarse en aportar valor en lugar de preocuparse por la infraestructura.
Evolucionando la plataforma para la mejora continua
Tener un equipo de plataforma no se trata solo de establecer los procesos; se trata de evolucionar la infraestructura compartida y las herramientas con el tiempo. Un equipo de plataforma dedicado está en la mejor posición para realizar mejoras incrementales en el proceso de entrega continua, asegurando que se mantenga alineado con las necesidades de los equipos y se adapte a medida que escalamos y crecemos. Esta evolución continua asegura que la plataforma siga siendo fiable, escalable y eficiente-lo que permite a nuestros equipos trabajar al máximo de su capacidad.
A continuación: Automatización y Retroalimentación
Con la ramificación optimizada y las implementaciones fluyendo, nos adentramos en la última frontera de nuestro viaje DevOps: Automatización y Retroalimentación. En el próximo y último capítulo, exploraremos cómo cerrar el ciclo con información automatizada y retroalimentación rápida transformó la forma en que operan nuestros equipos.
¡Manténgase atento!
