Principios y prácticas recomendadas de DevOps

La eliminación de problemas y el heroísmo no se tratan solo de una eficiencia fría y dura (aunque aumentarán la productividad). También están relacionados con la creación de una cultura laboral positiva y sostenible en la que los equipos puedan prosperar y producir su mejor trabajo. En una cultura de colaboración, los empleados se sienten más seguros, las ideas se comparten de forma más general y hay una mayor sensación de unión y responsabilidad, todo lo cual tiene un impacto positivo en la producción y el producto final.

Para crear un ambiente de colaboración, fomenta la franqueza, la transparencia y la retroalimentación (tanto positiva como negativa), al mismo tiempo que enfatizas que no hay malas ideas. Establece sistemas que permitan la polinización cruzada del trabajo entre los equipos y reconoce en público a las personas y los equipos por sus éxitos. Tener las herramientas adecuadas ( como un sistema de control de versiones que todos puedan usar) también es fundamental.

En DevOps, el principio "shift left" se refiere a la reorganización de los pasos en un flujo de trabajo. Los procesos que normalmente ocurren más adelante en la canalización de desarrollo se realizan en una etapa anterior para alinearlos con las prácticas recomendadas del ciclo de vida de DevOps.

CI/CD es un ejemplo de cómo el principio "shift left" puede ayudar a los equipos a trabajar con mayor agilidad. La integración continua (CI) es el proceso de fusionar automáticamente el trabajo en un repositorio central. Los cambios se validan mediante la creación de una compilación y la ejecución de pruebas automatizadas de la compilación.

Luego sigue la implementación continua (CD) de las versiones desde la compilación y la realización de pruebas automatizadas a nivel del sistema. Tradicionalmente, este proceso se realiza manualmente, lo que ralentiza la canalización. La implementación de CI/CD proporciona una forma coherente y automatizada de crear, empaquetar y probar tu software.

La eliminación de procesos manuales que desperdician tiempo y son vulnerables al error humano es un principio fundamental de DevOps. Las herramientas de pruebas automatizadas y seguimiento de errores les ahorran a los equipos el tedioso trabajo de buscar y eliminar errores, al mismo tiempo que hacen que estos procesos sean más eficientes en general. De hecho, con el conjunto correcto de herramientas para el monitoreo de errores y generación de informes, puedes aprovechar estos errores y convertirlos en indicadores, con el objetivo de optimizar el código y, en última instancia, lograr un mejor producto.

Las pruebas automatizadas son otro ejemplo del principio "shift left" de DevOps. En un flujo de trabajo tradicional, una compilación se envía en vivo y se prueba manualmente. Los flujos de trabajo que incorporan pruebas automatizadas pueden monitorear errores antes de que los cambios de código se publiquen en la compilación y también antes de la producción. Cuando los errores se marcan antes de publicarse, los programadores pueden solucionarlos en tiempo real y minimizar las interrupciones del servicio con revisiones y correcciones.

Para cuantificar el rendimiento de la canalización y encontrar oportunidades de optimización, debes realizar el seguimiento de varios indicadores claves de desempeño (KPI). Los cuatro KPI más importantes de DevOps son:

• Frecuencia de la implementación: la frecuencia con la que se implementa el código para la puesta en escena, las pruebas o la producción
• Plazo de ejecución de los cambios: el tiempo que tarda una confirmación en entrar en producción
• Frecuencia de errores de cambio: el porcentaje de implementaciones que detienen la producción
• Tiempo medio de reparación (MTTR): el tiempo medio para recuperarse de un error del producto o del sistema

Otros KPI incluyen:

• Tiempo de implementación: el tiempo necesario para implementar el código en la puesta en escena, las pruebas o la producción
• Tiempo del ciclo de solicitudes de extracción: el tiempo necesario para escribir e implementar el código
• Número de errores
• Tiempo medio de detección (MTTD): el tiempo medio para encontrar errores

Concéntrate en KPI relevantes y procesables. Realizar el seguimiento de muchos KPI puede causar una sobrecarga de información y datos que carecen de contexto, lo que dificulta la optimización.

Los equipos que implementan los principios de DevOps pueden beneficiarse de las prácticas de Agile: ambos son complementarios, ya que los valores de Agile son fundamentales para una colaboración efectiva de DevOps.

DevOps se centra en el desarrollo iterativo en todo el proceso de producción, desde la preproducción hasta el lanzamiento, con el envío constante de actualizaciones, hasta varias veces por semana. Agile se centra más en la fase de producción y sigue un modelo sprint, con el lanzamiento de nuevas compilaciones a un ritmo más prolongado, cada pocas semanas o incluso meses.

Los profesionales de DevOps pueden beneficiarse del enfoque de Agile para la administración de proyectos. Las prácticas de Agile, como Kanban y Scrum, garantizan que los flujos de trabajo estén organizados. También hay un mayor enfoque en el proceso y las reuniones, con herramientas que se utilizan principalmente para el seguimiento de la productividad, el cálculo de gráficos de evolución y la organización de trabajos pendientes.

En DevOps, un ciclo de retroalimentación es cuando una entrada se transmite a una salida (y viceversa) y se revisa, con el objetivo de mejorar uno o más procesos o resultados.

Hay dos tipos de ciclos de retroalimentación. En un ciclo de retroalimentación de refuerzo, una actualización positiva de un proceso beneficia a otro proceso relacionado, lo que aumenta el valor de la actualización original; esto a veces se denomina "un ciclo de cambio acelerado". En un ciclo de retroalimentación de balance, una actualización positiva de un proceso causa un resultado negativo para otro, lo que pone en duda el valor de la actualización original. En general, lo ideal es maximizar los ciclos de retroalimentación de refuerzo y minimizar los de balance.

Cuanto más cortos sean los ciclos de retroalimentación, más fáciles son de mantener, supervisar y optimizar.