Automatización y retroalimentación: Cerrando el ciclo DevOps
4 min de lectura

En el Capítulo 5: Ramificación y Despliegue Continuo, exploramos cómo las ramas de corta duración y una plataforma centralizada de despliegue continuo (CD) nos ayudaron a acelerar la entrega y a reducir los problemas de integración. Estos cambios mejoraron drásticamente el flujo de código a producción, pero para completar verdaderamente el ciclo de retroalimentación de DevOps, necesitábamos más.

El Capítulo 6, el segmento final de nuestra serie DevOps for the Win, se adentra en el último pero vital pilar de nuestra transformación: la automatización y la retroalimentación. Si el despliegue continuo nos ayudó a realizar lanzamientos más rápido, la automatización y la retroalimentación nos ayudaron a aprender con mayor rapidez, lo que nos permitió mejorar continuamente con confianza.

Por qué son importantes la automatización y la retroalimentación

En cualquier transformación de DevOps, la velocidad sin seguridad es una receta para el desastre. A medida que aumentó nuestra frecuencia de despliegue, la necesidad de controles automatizados y retroalimentación en tiempo real se volvió fundamental, no solo para el control de calidad, sino también para potenciar a los equipos y la toma de decisiones.

Los sistemas de automatización y retroalimentación ofrecen a los equipos:

  • Detección temprana de problemas antes de que lleguen a producción
  • Confianza en los cambios mediante una validación repetible y fiable
  • Métricas perspicaces para comprender el estado del sistema y el impacto en los usuarios

Es la diferencia entre volar a ciegas y volar con un panel de control.

Tras realizar mejoras en la velocidad de desarrollo, nuestro siguiente objetivo fue identificar los cuellos de botella en el ciclo de retroalimentación una vez que el equipo de desarrollo marcaba el trabajo como «finalizado». Aquí, la principal medida del flujo era la rapidez con la que el trabajo completado podía desplegarse en producción.

El tiempo de entrega de los cambios y la frecuencia de despliegue son métricas clave para medir la eficiencia con la que el trabajo se desplaza por el sistema. En nuestro caso, el trabajo se acumulaba en la etapa de control de calidad del sistema (SQA), lo que generaba un cuello de botella en la preparación para el despliegue.

El cuello de botella en el control de calidad del sistema

En la mayoría de los ámbitos, incluido el nuestro, los requisitos reglamentarios exigen una serie de actividades de validación para garantizar la calidad del software. Esto incluye:

  • Pruebas de integración
  • Pruebas a nivel de sistema
  • Pruebas no funcionales (p. ej., verificación de red, pruebas de rendimiento)
  • Artefactos de validación → Informes de pruebas del sistema, IQ (cualificación de instalación), OQ (cualificación operativa) y PQ (cualificación de rendimiento)

Estas tareas deben realizarse en entornos controlados, separados del desarrollo, para garantizar el cumplimiento. Debido a esto, el equipo de control de calidad del sistema opera de forma independiente y las pruebas solo pueden comenzar una vez que el equipo de desarrollo finaliza su trabajo.

Nuestros paneles mostraron que el tiempo necesario para trasladar el trabajo completado a un estado listo para producción estaba aumentando, y había más trabajo a la espera de que el equipo de SQA comenzara las pruebas. Siguiendo nuestro enfoque fundamental para mejorar el flujo, este era un problema que debíamos abordar antes de que cualquier otra optimización de DevOps pudiera mostrar un valor real.

Desafíos clave en el flujo desde el desarrollo hasta SQA

Hubo dos desafíos principales para mejorar el flujo de trabajo desde el desarrollo hasta el SQA del sistema:

  1. El retraso en el inicio de las tareas de SQA
  2. La velocidad a la que se podía ejecutar la validación del sistema

Si las pruebas de SQA son principalmente manuales, solo pueden comenzar una vez que el código se haya desarrollado por completo y se haya implementado en entornos controlados. Esto determina tanto cuándo pueden empezar las pruebas como el tiempo que llevará completarlas. Lo máximo que puede hacer SQA en este modelo es preparar los guiones de prueba de antemano, a la espera de que se alcance la definición de hecho (DoD) del equipo de desarrollo antes de ejecutar las pruebas.

Automatización de SQA: un cambio en la estrategia de pruebas

La única forma de mejorar este flujo es centrarse enormemente en la automatización. Sin embargo, esto no se trata solo de automatizar la ejecución de pruebas; requiere un cambio fundamental en la forma en que se abordan las pruebas. Esto incluye:

  • Redefinir y realinear los objetivos del SQA del sistema.
  • Reevaluar cómo se realiza la validación para cumplir tanto con los requisitos de velocidad como con los reglamentarios.
  • Reimaginar las herramientas y los marcos necesarios para respaldar la automatización de manera eficaz.

Uno de los cambios clave de mentalidad fue pasar de hacer pruebas para confirmar que el software desarrollado funciona a hacer pruebas para guiar el desarrollo.

Esto significaba conseguir que los guiones de prueba se crearan, se automatizaran y se ejecutaran en un entorno donde el código de desarrollo se implementa regularmente, incluso antes de alcanzar la DoD de la característica. Aquí, los errores en las pruebas no indican un defecto, sino que proporcionan una visión temprana de qué partes de la funcionalidad aún no se han implementado o no funcionan por completo.

Con canales de entrega continua y una estrategia de ramificación refinada, en la que las ramas de características se fusionan frecuentemente en la rama principal y se implementan en la nube, configuramos un entorno dedicado donde estas pruebas de sistema automatizadas podían ejecutarse de forma continua.

Comentarios más rápidos con pruebas automatizadas

Este enfoque permitió que el SQA del sistema comenzara la validación antes, lo que hizo que las pruebas fueran más rápidas y proporcionó comentarios más rápidos al equipo de desarrollo. En lugar de esperar hasta que una característica se marque como finalizada, las pruebas ahora se ejecutan en paralelo con el desarrollo, lo que brinda a los equipos información en tiempo real sobre lo que está funcionando y lo que aún debe completarse.

Al mismo tiempo, la automatización de los casos de prueba requirió replantear las estrategias de pruebas.

  • Dejar atrás la automatización basada en la interfaz de usuario: las pruebas de API se convirtieron en la prioridad.
  • Cambiar hacia el desarrollo guiado por comportamiento (BDD): crear guiones de prueba junto con las historias de usuario para incluirlas en los criterios de aceptación.

Si bien la adopción total de BDD desde el inicio de la creación de historias de usuario sigue en marcha, hemos mejorado la colaboración entre SQA y los equipos de desarrollo, alineándolos desde el principio del proceso.

Alineación de SQA con el desarrollo: la influencia de las topologías de equipos

Para lograrlo, aplicamos el enfoque de equipo especialista de Team Topologies, configurando el equipo de SQA como un equipo facilitador. En lugar de ser una función de pruebas separada y posterior, los miembros del equipo de SQA se alinearon estrechamente con el desarrollo para garantizar que la creación de casos de prueba de automatización comience temprano y se ejecute de forma continua a medida que se desarrolla el código.

Un requisito previo fundamental para este enfoque es contar con un entorno de pruebas Cloud-based para ejecutar pruebas a nivel de sistema antes de pasar a entornos controlados. Si bien esto genera costos de infraestructura adicionales, aumenta significativamente el flujo de trabajo desde el desarrollo hasta SQA, lo que hace que esté listo para su implementación mucho más rápido.

Conclusión

Esta mejora refuerza un principio fundamental de DevOps: abordar la transformación considerando las competencias de herramientas, arquitectura y personas, al tiempo que se centra en el flujo. Al automatizar el SQA del sistema, integrar las pruebas antes en el ciclo y alinear los equipos de manera más eficaz, redujimos significativamente el cuello de botella entre el desarrollo y la validación del sistema, acelerando los ciclos de retroalimentación y facilitando las implementaciones.

Conclusión de la serie

Al concluir nuestra serie DevOps for the Win, reflexionamos sobre el camino recorrido desde el caos de herramientas y los procesos manuales hacia una organización más conectada, automatizada y capacitada. Desde la definición de nuestro triángulo de DevOps en el Capítulo 1 hasta el establecimiento del aprendizaje basado en la retroalimentación en el Capítulo 6, cada capítulo se basó en el anterior para impulsar una transformación significativa.

Aquí tiene un resumen rápido de nuestra serie:

Esta transformación continúa, pero con la base que hemos construido, estamos mejor preparados que nunca para ofrecer valor de forma más rápida, segura e inteligente.

Gracias por acompañarnos en este recorrido. Esperamos que nuestra historia inspire su propia evolución en DevOps.

Mantenga la curiosidad. Siga iterando. Y, lo más importante, manténgase conectado.

Suscribirse al blog de Freyr