Cómo lograr una retroalimentación continua en los flujos de DevOps

Metodologías y comentarios de CI/CD

Las fases de CI/CD generalmente se basan entre sí. Las organizaciones DevOps pueden implementar algunos o todos los aspectos de la integración continua y la distribución continua, pero el mejor enfoque varía de un equipo a otro y de un proyecto a otro.

La integración continua es la práctica de desarrollo de software de asimilación constante de cambios de código en un repositorio de código común. CI fomenta cambios de código más pequeños y frecuentes que otras metodologías de desarrollo, lo que conduce a una rápida iteración y pruebas de código.

Al practicar CI, el equipo se enfoca en si una compilación y un conjunto de pruebas tuvieron éxito o fallaron antes de pasar a la siguiente parte del proceso de entrega. En general, funciona así: un desarrollador confirma un cambio en un sistema de control de versiones, que se comunica con la herramienta CI. En ese momento, la canalización activa herramientas para compilar o empaquetar ese código, que luego se prueba para verificar si la compilación se realizó correctamente. El equipo de desarrollo toma medidas en función de si la compilación progresó correctamente o falló.

El código probado se entrega para empaquetar y desplegar en producción. La entrega continua significa que el código ejecutable está construido y listo para funcionar tan pronto como CI se complete. El equipo de control de calidad se comunica con los desarrolladores o recibe un mensaje automatizado que indica el estado de la compilación. En esta etapa, la decisión de desplegarse en producción es normalmente manual.

Para una implementación continua, los equipos de DevOps implementan un conjunto de pasos automatizados para activar el código. El despliegue continuo es una de las prácticas más difíciles para obtener retroalimentación adecuada. Hay fuentes de retroalimentación continua en producción, generalmente métricas de servidor, métricas de rendimiento de aplicaciones y retroalimentación de clientes. Si bien el código podría implementarse con éxito en la producción, la configuración de automatización y monitoreo podría no brindar retroalimentación real sobre los efectos que cada versión tiene en los usuarios finales.

Nota del editor: en la abreviatura CI/CD, CD generalmente se refiere a la entrega continua, no a la implementación continua más compleja.

Comentarios de DevOps en la vida real

La retroalimentación generada por los diversos sistemas en un entorno DevOps es difícil de manejar y descifrar para muchas organizaciones. Peor aún, la información incorrecta o incompleta puede rápidamente perder el tiempo de los equipos en la resolución de problemas.

Idealmente, la retroalimentación proporciona información procesable de una manera que se ajuste al flujo de trabajo del equipo. Estas son algunas de las mejores prácticas para lograr comentarios continuos en entornos DevOps.

Integrar la comunicación en tiempo real. Muchas organizaciones usan el correo electrónico para comunicarse entre equipos. Pero los clientes de chat ofrecen una ida y vuelta más rápida que se adapta a los flujos DevOps rápidos y automatizados. La mayoría de los sistemas de chat se integran en las herramientas de CI/CD, lo que facilita el envío de mensajes de estado y otros comentarios. Pero los mensajes pueden perderse en el gran volumen de conversaciones y alertas. Observe lo que es esencial transmitir sobre los procesos de CI/CD para que los miembros del equipo obtengan lo que necesitan.

Enfoque de mensajes para cortar el ruido. Para enfocar la retroalimentación y evitar ruidos innecesarios, invierta el tiempo para determinar exactamente qué necesita un equipo de DevOps en un mensaje de retroalimentación y qué tan rápido necesita saber sobre un resultado dado, como el éxito o el fracaso o la acción automatizada. Reduzca los mensajes innecesarios y repetitivos al resumirlos.

No abandone totalmente los mensajes manuales. Los pasos manuales todavía tienen un lugar en el mundo de la automatización continua. Por ejemplo, un equipo de control de calidad encuentra un error en una compilación y, debido a un requisito de aprobación, debe detener el progreso. Puede proporcionar retroalimentación a los desarrolladores, indicando y explicando la razón de la falla. Con esta entrada, un desarrollador puede actualizar el código, que luego vuelve al equipo de control de calidad en una compilación fija. Con este ciclo de retroalimentación completo, y si pasan todas las pruebas de control de calidad, la compilación avanza para lanzarse a producción.

Enfatice el monitoreo del sistema. El monitoreo es un componente crítico de la implementación de DevOps, y los equipos pueden obtener comentarios valiosos para los desarrolladores a partir de métricas monitoreadas. El monitoreo actúa como el indicador de éxito o falla para el código actualizado al final del proceso de CI/CD, completando el ciclo de retroalimentación de DevOps para que comience la próxima iteración. Busque herramientas de monitoreo que permitan a los usuarios hacer una notación en un punto en el tiempo con respecto a una versión de compilación.

Las herramientas de monitoreo pueden desempeñar un papel en la retroalimentación continua en los canales de DevOps que se extienden a la producción. Por ejemplo, una herramienta de monitoreo está configurada para generar una alerta de variaciones en el uso de CPU y memoria. Cuando los desarrolladores y los evaluadores de control de calidad obtienen estos comentarios sobre el consumo de recursos, pueden actuar sobre la información para abordar problemas con la compilación u optimizar aún más el código.

Expansión más allá de los comentarios tradicionales

Más allá de estas fuentes de retroalimentación continua esperadas en las implementaciones de DevOps, busque otros tipos útiles, como marketing, documentación y soporte. Es posible que los equipos de TI no busquen comentarios en estos lugares porque quedan fuera del proceso de CI/CD, pero pueden ser igual de importantes y extender el ciclo de principio a fin.

Busque formas de incorporar alertas de estas fuentes en el proceso de retroalimentación. Por ejemplo, un aumento en las solicitudes de soporte es información útil sobre una versión. Necesita una forma para que los representantes de soporte indiquen que hay un problema. En los enfoques de gestión de servicios de TI basados ​​en ITIL, por ejemplo, la alerta vendría en forma de un registro de problemas, que está vinculado a la última compilación.

Otro ejemplo muestra el valor de la documentación para los bucles de retroalimentación. A medida que el código se mueve a través del flujo de CI/CD para la prueba, se envían mensajes procesables al equipo de documentación donde es posible etiquetar los cambios de código como una funcionalidad nueva o mejorada, y obtener la documentación actualizada en el momento en que el código se activa y requiere soporte.

Los clientes deben conocer las nuevas características y funcionalidades, lo que hace que el marketing también forme parte del ciclo de DevOps. El equipo de marketing debe incluirse en el proceso DevOps para preparar los materiales apropiados, cronometrados en torno al lanzamiento de la producción. Cuanto más retroalimentación y comunicación automatizadas, más fácil es mantener a estos grupos dispares trabajando juntos.

Medir el éxito de la retroalimentación

La retroalimentación continua en los flujos de DevOps es tan buena como los sistemas establecidos para lograrlo. Se arriesga a agregar mucha complejidad por poco beneficio. Utilice las métricas de DevOps para saber si los circuitos de retroalimentación ahorran tiempo y aumentan la productividad. Las medidas a observar incluyen el tiempo medio de resolución (MTTR) y el tiempo de desarrollo, reparación y ciclo completo.

MTTR es el tiempo que tarda la retroalimentación en llegar a una solución. Por lo general, los comentarios se presentan en forma de una solicitud de atención al cliente, que se canaliza a los desarrolladores para que trabajen, pero también podrían ser alertas automáticas de las herramientas de monitoreo. Un equipo de soporte coloca los informes de errores sobre un problema con una nueva versión, creando un registro de problemas para esa compilación. El informe del problema brinda a los desarrolladores comentarios sobre lo que salió mal y aplican su experiencia para cambiar el código del problema. El tiempo desde los informes iniciales hasta el momento en que el equipo de DevOps lanza una nueva versión a producción comprende TTR. Los equipos pueden comparar cada solución del problema con el MTTR para identificar cuellos de botella y otros problemas del proceso y deben tratar de reducir el MTTR general como un objetivo continuo.

DevOps se trata de moverse rápido, pero esa velocidad no sirve si culmina en una construcción fallida que lleva mucho tiempo solucionar. Los desarrolladores reciben la retroalimentación de que una compilación falló bastante rápido, pero eso es solo el comienzo del reloj. Los equipos de DevOps deben realizar un seguimiento del tiempo que lleva solucionar el problema. Cuanta más información tengan sobre el fallo de compilación, mejor equipados estarán para resolverlo. Los largos tiempos de reparación fallidos retrasan otros procesos de desarrollo y deben abordarse, posiblemente con capacitación para escribir un mejor código.

El tiempo de ciclo de sprint completo, también conocido como tiempo de confirmación de implementación, proporciona información sobre el estado de un flujo de CI/CD. Muchos equipos de DevOps se basan en enfoques de desarrollo de software ágil, incluido el uso de sprints.

Un sprint establece límites de tiempo estrictos para un ciclo continuo de integración y entrega, lo que obliga al equipo a identificar pasos lentos o áreas donde el código espera a que una herramienta o persona tome medidas al respecto. Los bucles de retroalimentación contienen información valiosa sobre las ralentizaciones dentro del ciclo de sprint. Dentro del tiempo completo del ciclo de sprint, también debe medirse el tiempo de desarrollo de la característica como una métrica independiente. Y las organizaciones maduras de DevOps deberían mirar más allá de TI en la documentación y los esfuerzos de marketing como se incluye en la medida del tiempo de ciclo.

Rastree estas métricas y otras para guiar y medir la mejora en el flujo de CI/CD a lo largo del tiempo. Si es nuevo en los conceptos de integración continua y distribución continua, mida todo lo posible sobre los sistemas de desarrollo e implementación antes y después de implementarlo. Si encuentra que los nuevos procesos no ahorran tiempo, dé un paso atrás y evalúe dónde se descomponen los procesos.