Automatización y retroalimentación: Cerrar el bucle DevOps
4 min leer

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

El capítulo 6, el segmento final de nuestra serie DevOps for the Win, se sumerge en el último pero vital pilar de nuestra transformación: Automatización y retroalimentación. Si el despliegue continuo us ayudó a lanzar más rápido, la automatización y la retroalimentación us ayudaron a aprender más rápido, lo que us mejorar continuamente con confianza.

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

En cualquier transformación DevOps, la velocidad sin seguridad es una receta para el desastre. A medida que aumentaba nuestra frecuencia de despliegue, la necesidad de comprobaciones automatizadas y de información en tiempo real se convirtió en algo fundamental, no solo para garantizar la calidad, sino para capacitar al equipo y facilitar la toma de decisiones.

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

  • Detección precoz de problemas antes de que reach producción
  • Confianza en los cambios, mediante una validación repetible y fiable.
  • Métricas reveladoras para comprender el estado del sistema y el impacto en el usuario

Es la diferencia entre volar a ciegas y volar con un salpicadero.

Después de mejorar la velocidad de desarrollo, nos centramos en identificar los cuellos de botella en el bucle de retroalimentación una vez que el equipo de desarrollo marcaba el trabajo como "terminado". En este caso, la principal medida del flujo era la rapidez con la que el trabajo completado podía desplegarse en producción.

El plazo de cambio y la frecuencia de implantación son parámetros clave para medir la eficacia con la que el trabajo avanza por el sistema. En nuestro caso, el trabajo se acumulaba en la fase de QA del sistema (SQA), lo que creaba un cuello de botella en la preparación de la implantación.

El cuello de botella de QA del sistema

En la mayoría de los ámbitos, incluido el nuestro, los requisitos normativos 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 (por ejemplo, verificación de la red, pruebas de rendimiento)
  • Artefactos de validación → Informes de pruebas del sistema, IQ (cualificación de la instalación), OQ (cualificación operativa) y PQ (cualificación del rendimiento).

Estas tareas deben realizarse en entornos controlados, separados del desarrollo, para garantizar la conformidad. Por ello, el equipo QA del sistema funciona de forma independiente, y las pruebas sólo pueden empezar una vez que el equipo de desarrollo ha terminado su trabajo.

Nuestros paneles de control mostraban que el tiempo necesario para pasar el trabajo completado al estado listo para producción estaba aumentando, con más trabajo esperando a que SQA comenzara las pruebas. Siguiendo nuestro enfoque fundamental para mejorar el flujo, este era un problema que teníamos que abordar antes de que cualquier otra optimización de DevOps pudiera mostrar un valor real.

Desafíos clave en el flujo de desarrollo a SQA

La mejora del flujo de trabajo desde el desarrollo hasta QA del sistema planteaba dos grandes retos:

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

Si las pruebas de SQA son principalmente manuales, sólo pueden comenzar una vez que el código está completamente desarrollado y desplegado en entornos controlados. Esto determina tanto el momento en que pueden comenzar las pruebas como el tiempo que tardarán en completarse. Lo mejor que puede hacer la SQA en este modelo es preparar guiones de prueba por adelantado, esperando a 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 masivamente en la automatización. Sin embargo, no se trata solo de automatizar la ejecución de las pruebas, sino que requiere un cambio fundamental en la forma de abordarlas. Esto incluye:

  • Redefinir y reajustar los objetivos de QA del sistema.
  • Reevaluar cómo se realiza la validación para cumplir tanto los requisitos de velocidad como los reglamentarios.
  • Reimaginar las herramientas y los marcos necesarios para apoyar eficazmente la automatización.

Uno de los principales cambios de mentalidad fue pasar de probar para confirmar que el software desarrollado funciona → a probar para orientar el desarrollo.

Esto significaba crear, automatizar y ejecutar secuencias de comandos de prueba en un entorno en el que el código de desarrollo se envía regularmente, incluso antes de que se alcance el DoD de la función. En este caso, los fallos de las pruebas no indican un defecto, sino que proporcionan una visión temprana de las partes de la funcionalidad que aún no se han implementado o no son totalmente funcionales.

Gracias a las canalizaciones de entrega continua y a una estrategia de ramificación refinada, en la que las ramas de características se fusionan con frecuencia en la rama principal y se despliegan en la nube, creamos un entorno dedicado en el que estas pruebas automatizadas del sistema podían ejecutarse de forma continua.

Feedback más rápido con pruebas automatizadas

Este planteamiento permitió QA del sistema iniciar antes la validación, lo que agilizó las pruebas y facilitó información más rápida al equipo de desarrollo. En lugar de esperar a que una función se marque como terminada, ahora las pruebas se realizan en paralelo con el desarrollo, lo que proporciona a los equipos información en tiempo real sobre lo que funciona y lo que queda por completar.

Al mismo tiempo, la automatización de los casos de prueba exigía replantearse las estrategias de prueba.

  • Alejarse de la automatización basada en la interfaz de usuario → Las pruebas de API se convirtieron en la prioridad.
  • Cambio al desarrollo basado en el comportamiento (BDD) → Creación de guiones de prueba junto con las historias de usuario que se incluirán en los criterios de aceptación.

Aunque la plena adopción de BDD desde el inicio de la creación de historias de usuario sigue siendo un trabajo en curso, hemos mejorado la colaboración entre los equipos de SQA y de desarrollo, alineándolos en las primeras fases del proceso.

Alinear el SQA con el desarrollo: La influencia de las topologías de equipo

Para lograrlo, aplicamos el enfoque de equipo especializado de Team Topologies, estableciendo el equipo de SQA como un equipo habilitador. En lugar de ser una función de pruebas separada, 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 comenzara pronto y se ejecutara continuamente a medida que se desarrollaba el código.

Un requisito previo clave para este enfoque es disponer de un entorno de pruebas cloud-based para ejecutar pruebas a nivel de sistema antes de pasar a entornos controlados. Aunque esto introduce costes de infraestructura adicionales, aumenta significativamente el flujo de trabajo desde el desarrollo hasta el SQA, lo que hace que esté listo para el despliegue mucho más rápido.

Conclusión

Esta mejora refuerza un principio básico de DevOps: abordar la transformación teniendo en cuenta las competencias de las herramientas, la arquitectura y las personas, centrándose al mismo tiempo en el flujo. Al automatizar el QA del sistema, integrar las pruebas en una fase más temprana del ciclo y alinear los equipos de forma 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 implantaciones.

Conclusión de la serie

Como cierre de nuestra serie DevOps for the Win, reflexionamos sobre el viaje desde el caos de las herramientas y los procesos manuales hasta una organización más conectada, automatizada y capacitada. Desde la definición de nuestro triángulo 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.

He aquí un breve resumen de nuestra serie:

Esta transformación está en curso, pero con los cimientos que hemos construido, estamos mejor equipados que nunca para ofrecer valor de forma más rápida, segura e inteligente.

Gracias por seguirnos en este viaje. Esperamos que nuestra historia inspire su propia evolución DevOps.

Mantenga la curiosidad. Mantente iterativo. Y lo más importante, mantente conectado.

Suscribirse al blog de Freyr