3 min leer
En Capítulo 4: Seguimiento de lo que importa - KPI y cuadros de mandoexploramos cómo la visualización del flujo de trabajo y la definición de los KPI adecuados us ayudaron a detectar cuellos de botella y a alinear a nuestros equipos en torno a la entrega de valor. Con una mejor visibilidad de nuestro canal de DevOps, empezamos a hacernos preguntas más profundas, no sólo dónde estaban los cuellos de botella, sino por qué se producían.
En el capítulo 5, nos adentramos en uno de los cambios técnicos y de proceso más significativos de nuestro proceso de transformación: el perfeccionamiento de nuestra estrategia de ramificación y la activación del despliegue continuo. Estos cambios fueron fundamentales para resolver los persistentes retrasos entre desarrollo y producción.
Identificar el nuevo cuello de botella
Analizar el flujo de trabajo e identificar los cuellos de botella en los que se acumula el trabajo ha sido un aspecto clave para lograr nuestra transformación DevOps. Este enfoque en el flujo está en el centro de 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 comprobabilidad con el aumento de la cobertura de las pruebas unitarias y la automatización de pruebas, descubrimos que la calidad del código mejoraba, pero el cuello de botella seguía estando en la fase de pruebas scrum. A pesar de los avances en la automatización de 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) mostraban 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 del sistema. us última instancia, este retraso impedía lograr un flujo fluido.
La causa raíz: Estrategia de ramificación y retrasos en las fusiones
El análisis reveló que la causa principal del retraso radicaba en nuestra estrategia de ramificación. Los desarrolladores y probadores creaban ramas de funciones a partir de la rama principal cuando iniciaban nuevas funciones. A medida que se desarrollaba el código, los ingenieros empujaban sus cambios a ramas de características remotas para fusionar su trabajo con otros. Sin embargo, este código no se fusionaba con la rama principal con la frecuencia suficiente.
Las canalizaciones CI/CD se establecieron en la rama principal, ejecutando pruebas automatizadas y desplegando en la nube, seguidas de pruebas de regresión. Sin embargo, como los últimos cambios no se transferían a la rama principal con regularidad, las ejecuciones de las canalizaciones se ejecutaban en código obsoleto, lo que las hacía redundantes e ineficaces.
La solución: ramas de funciones efímeras
Para resolverlo, nos dimos cuenta de que era necesario ajustar la estrategia de ramificación. Aunque hay pros y contras 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 de nuevo con la rama principal con más frecuencia.
La estrategia de bifurcación de corta duración ofrece varias ventajas, siendo la más importante la mejora de la fluidez y la resolución de los cuellos de botella del ciclo de desarrollo. Las ramas de vida más corta 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 de las canalizaciones
Establecer canalizaciones de despliegue continuo sólidas es una tarea compleja que requiere un enfoque centrado e incremental. Según nuestra experiencia, el enfoque recomendado es contar con un equipo de plataforma dedicado a configurar y mantener estas canalizaciones, en lugar de que cada equipo de scrum trabaje en ellas individualmente. Aunque la propiedad final de las canalizaciones de entrega continua debe recaer en los equipos de scrum, la tarea inicial de configurarlas se beneficia enormemente de un equipo de plataforma dedicado.
Equipo de plataforma: Reducir la carga cognitiva y facilitar 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 hace hincapié en la importancia de contar con un equipo dedicado a la plataforma que se encargue de configurar y gestionar la infraestructura (en nuestro caso, los conductos de CD). Esta estructura permite a los equipos de scrum centrarse en el desarrollo de características, al tiempo que se benefician de una configuración de canalización estable y estandarizada.
Como dice el libro:
"El equipo de la plataforma es responsable de crear y mantener la plataforma interna que los equipos alineados con la corriente utilizan para realizar su trabajo. El objetivo 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 canalizaciones, pudimos crear una plataforma común y compartida de la que podían depender los equipos alineados con los flujos. Esto us permitió reducir la carga cognitiva de los equipos de desarrollo, permitiéndoles centrarse en ofrecer valor en lugar de ocuparse de los problemas de infraestructura".
Evolución de la plataforma para la mejora continua
Contar con un equipo de plataforma no consiste únicamente en configurar las canalizaciones; se trata de hacer evolucionar la infraestructura y las herramientas compartidas a lo largo del tiempo. Un equipo de plataforma dedicado se encuentra en la mejor posición para realizar mejoras incrementales en la canalización de entrega continua, garantizando que se mantiene alineada con las necesidades de los equipos y se adapta a medida que escalamos y crecemos. Esta evolución continua garantiza que la plataforma siga siendo fiable, escalable y eficiente, lo que permitea nuestros equipos trabajar al máximo rendimiento.
A continuación: Automatización y retroalimentación
Con la ramificación racionalizada y los despliegues fluyendo, pasamos a la última frontera en nuestro viaje DevOps: Automatización y retroalimentación. En el siguiente y último capítulo, exploraremos cómo el cierre del bucle con información automatizada y feedback rápido transformó el funcionamiento de nuestros equipos.
Permanezca atento.
