El modelo de implementación de entrega continua
- 4 minutos
Has aprendido sobre las muchas desventajas de la "implementación épica" como modelo de entrega de software, pero saber lo que no funciona bien es tan solo la mitad de la batalla. En esta unidad, obtendrá información sobre la alternativa a ese método monolítico y cómo puede aumentar el objetivo de mejorar la confiabilidad.
También merece la pena distinguir dos términos relacionados que a veces se usan indistintamente:
- Entrega continua: todos los cambios que superen las pruebas automatizadas están listos para implementarse en producción, pero la versión real en producción está controlada por una aprobación manual.
- Implementación continua: todos los cambios que superen las pruebas automatizadas se liberan automáticamente en producción, sin ninguna puerta manual.
Ambos dependen de las mismas bases (integración frecuente, pruebas automatizadas, canalizaciones repetibles). Este módulo se centra en esas bases compartidas.
¿Qué es la entrega continua?
La entrega continua es un método por el que cada cambio en el código base se mantiene liberado en una forma más rápida, menos estresante, menos arriesgada y más reproducible. En lugar de hacer que cada implementación de software o actualice un evento épico, la entrega continua lo convierte en una experiencia rápida, rutinaria y predecible que se produce a petición.
Frecuencia de implementación: con un modelo de entrega continua, las implementaciones se producen a menudo: La cadencia podría ser mensual, semanal, diaria o incluso por hora. La clave consiste en implementar cambios más pequeños y específicos más a menudo.
Desencadenada por confirmación de código: en lugar de esperar una ventana de versión programada de antemano, la canalización de entrega se inicia cuando se confirma el código. Este código puede ser software, infraestructura o incluso elementos como configuraciones de software. A continuación, cada cambio se compila, prueba y se mantiene listo para su lanzamiento. En función de los controles de la organización, la promoción a producción puede ocurrir más adelante, después de una aprobación.
Pruebas automatizadas: puede usar las pruebas automatizadas integradas no solo para probar el código, sino para proporcionar comentarios rápidos sobre los resultados de las pruebas. Estos comentarios rápidos son los que permiten iterar y recuperarse rápidamente de las pruebas fallidas.
Una vez que se ha probado el código, se puede probar la implementación, de un extremo a otro, en una serie de entornos de ensayo, como pruebas, control de calidad, etc. La aplicación de las implementaciones en estos entornos es una parte integral de la experiencia de implementación.
Registros históricos: no solo le interesa tener un registro histórico de las actividades de implementación, sino que le conviene poder conciliar el entorno de producción en un momento dado. Necesita saber qué implementación ha creado el entorno de producción actual. Con este conocimiento, puede llevar un seguimiento de aspectos como configuraciones, resultados de pruebas y el propio código hasta la solicitud de incorporación de cambios individual que desencadenó la implementación.
Objetivos de implementación
Ahora que sabe cómo funciona la entrega continua, tenga en cuenta los objetivos de entrega continua y otras prácticas de DevOps le ayudarán a lograr al implementar soluciones de software.
Objetivo 1: reducir el estrés que conlleva la implementación de servicios a la vez que se aumenta la confiabilidad de dichos servicios
Reducir el estrés de las implementaciones de software e infraestructura mejora la experiencia diaria de los ingenieros que los ejecutan. El aumento resultante de la confiabilidad también beneficia a los usuarios finales, que experimentan menos cortes e interrupciones.
Objetivo 2: reducir el tiempo que media entre el momento en el que se descubre que hace falta un cambio y el momento en el que dicho cambio se implementa en producción
Por ejemplo, supongamos que ha identificado un defecto de código que afecta a los ingresos y sabe exactamente cómo corregirlo. Con prácticas maduras de DevOps, el ciclo de commit a producción es corto y predecible. El cambio se compila, se prueba automáticamente en los entornos pertinentes y se prepara para su lanzamiento en cuestión de minutos. Cuando se reciba la aprobación correspondiente, se podrá pasar a la fase de producción en lugar de quedarse en el período programado para una nueva versión.
Objetivo 3: Reducir el tiempo entre tener una idea y entregar software utilizable
Este objetivo es similar al anterior, pero se centra en la innovación en lugar de en las correcciones. ¿Cuánto tiempo tardas en actuar sobre una nueva idea? Con este modelo de implementación, puede integrar un nuevo concepto en un sistema de producción con confianza en que la adición no interrumpirá ni dificultará el sistema actual. Esa confianza le permite ofrecer nuevas características rápidamente.
Resultados de la implementación
Los objetivos descritos en esta unidad no son solo aspiraciones teóricas, son medibles. Desde 2014, el equipo de DevOps Research and Assessment (DORA) ha publicado una investigación anual sobre el estado de DevOps sobre el rendimiento de la entrega de software. En los últimos años, este trabajo se ha publicado como el Accelerate State of DevOps Report. El modelo DORA actual realiza un seguimiento de cinco métricas de entrega:
- Frecuencia de implementación
- Cambio del tiempo de entrega
- Tasa de fallos de cambio
- Tiempo de recuperación de implementación fallida
- Tasa de incidencias en implementación
Año después del año, la investigación muestra que los equipos de mayor rendimiento proporcionan cambios con más frecuencia, pasan de la confirmación a la producción más rápido, se recuperan de implementaciones con errores antes y dedican menos tiempo a corregir problemas relacionados con la implementación. Para obtener las últimas definiciones de investigación y métricas, consulte las métricas de entrega de software de DORA.
Estos resultados validan la idea de que las prácticas de implementación son importantes.