Automatización y retroalimentación: Cerrando el ciclo de 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 reducir la fricción 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.

Capítulo 6, el segmento final de nuestra serie DevOps para el éxito, se adentra en el último, pero vital, pilar de nuestra transformación: Automatización y retroalimentación. Si el despliegue continuo nos ayudó a lanzar más rápido, entonces la automatización y la retroalimentación nos ayudaron a aprender más rápido, permitiéndonos mejorar continuamente con confianza.

Por qué la automatización y la retroalimentación importan

En cualquier transformación DevOps, la velocidad sin seguridad es una receta para el desastre. A medida que nuestra frecuencia de implementación aumentó, la necesidad de verificaciones automatizadas y retroalimentación en tiempo real se volvió crítica, no solo para la garantía de calidad, sino también para el empoderamiento del equipo 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, a través de una validación repetible y fiable
  • Métricas detalladas para comprender la salud del sistema y el impacto en el usuario.

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

Después de mejorar la velocidad de desarrollo, nuestro siguiente objetivo fue identificar cuellos de botella en el ciclo de retroalimentación una vez que el equipo de desarrollo marcaba el trabajo como "terminado". Aquí, la principal medida del flujo fue la rapidez con la que el trabajo completado podía implementarse en producción.

El tiempo de entrega para el cambio y la frecuencia de implementación son métricas clave para medir la eficiencia con la que el trabajo avanza a través del sistema. En nuestro caso, el trabajo se estaba acumulando en la etapa de QA del sistema (SQA), creando un cuello de botella en la preparación para la implementación.

El cuello de botella del QA 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 (por ejemplo, verificación de red, pruebas de rendimiento)
  • Artefactos de validación → Informes de pruebas del sistema, CI (Calificación de Instalación), CO (Calificación Operacional) y CD (Calificación de Desempeño)

Estas tareas deben realizarse en entornos controlados, separados del desarrollo, para garantizar el cumplimiento. Por ello, el equipo de QA del sistema opera de forma independiente, y las pruebas solo pueden comenzar una vez que el equipo de desarrollo ha completado su trabajo.

Nuestros paneles de control mostraron que el tiempo necesario para pasar el trabajo completado a un estado listo para producción estaba aumentando, con más trabajo esperando que 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 Dev hasta SQA

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

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

Si las pruebas SQA son principalmente manuales, solo pueden comenzar una vez que el código esté completamente desarrollado e implementado en entornos controlados. Esto determina tanto cuándo pueden comenzar las pruebas como cuánto tiempo tardarán en completarse. Lo mejor que SQA puede hacer en este modelo es preparar los scripts de prueba con antelación, esperando 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, esto no se trata solo de automatizar la ejecución de pruebas, sino que requiere un cambio fundamental en cómo se aborda la realización de pruebas. Esto incluye:

  • Redefiniendo y reajustando los objetivos de la QA del sistema.
  • Reevaluación de 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 la automatización de manera efectiva.

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

Esto significó conseguir que los scripts de prueba se crearan, automatizaran y ejecutaran en un entorno donde el código de desarrollo se envía regularmente, incluso antes de que se alcance el DoD de la característica. Aquí, los fallos de las pruebas no indican un defecto, sino que proporcionan una visión temprana de qué partes de la funcionalidad aún no están implementadas o no son completamente funcionales.

Con pipelines de entrega continua y una estrategia de ramificación refinada en su lugar, donde 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 podrían ejecutarse continuamente.

Retroalimentación más rápida con pruebas automatizadas

Este enfoque permitió que el QA del sistema comenzara la validación antes, agilizando las pruebas y proporcionando comentarios más rápidos al equipo de desarrollo. En lugar de esperar a que una función se marque como terminada, las pruebas ahora se ejecutan en paralelo con el desarrollo, lo que brinda a los equipos información en tiempo real sobre lo que funciona y lo que aún necesita ser completado.

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

  • Pasar de la automatización basada en la interfaz de usuario (UI) → las pruebas de API se convirtieron en la prioridad.
  • Transición al desarrollo dirigido por el comportamiento (BDD) → Creación de scripts de prueba junto con las historias de usuario para ser incluidos en los criterios de aceptación.

Aunque la adopción completa de BDD desde el inicio de la creación de historias de usuario todavía está en curso, hemos mejorado la colaboración entre los equipos de SQA y desarrollo, alineándolos al principio del proceso.

Alineando SQA con el Desarrollo: La influencia de las topologías de equipo

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

Un requisito clave para este enfoque es tener un entorno de prueba Cloud-based para ejecutar pruebas a nivel de sistema antes de pasar a entornos controlados. Si bien esto introduce costos de infraestructura adicionales, aumenta significativamente el flujo de trabajo desde el desarrollo hasta el SQA, haciéndolo listo para la implementación mucho más rápido.

Conclusión

Esta mejora refuerza un principio central de DevOps: abordar la transformación considerando las competencias de Herramientas, Arquitectura y Personas, mientras se enfoca en el flujo. Al automatizar el QA del sistema, integrar las pruebas antes en el ciclo y alinear los equipos de manera más efectiva, reducimos significativamente el cuello de botella entre el desarrollo y la validación del sistema, acelerando los ciclos de retroalimentación y haciendo que las implementaciones sean más fluidas.

Concluyendo la serie

Al concluir nuestra serie DevOps para el Éxito, reflexionamos sobre el camino desde el caos de herramientas y los procesos manuales hacia una organización más conectada, automatizada y empoderada. Desde la definición de nuestro Triángulo DevOps en el Capítulo 1 hasta el establecimiento del aprendizaje impulsado por 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 breve resumen de nuestra serie:

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

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

Manténgase curioso. Manténgase iterativo. Y lo más importante, manténgase conectado.

Suscribirse al Blog de Freyr