Canalización de DevOps

1. Integración continua, entrega continua e implementación continua (CI/CD)

La práctica de integración continua consiste en realizar confirmaciones frecuentes en un repositorio de código fuente común. Los cambios de código se integran de forma continua en la base de código existente para que cualquier conflicto entre los diferentes cambios en el código de los desarrolladores se identifique rápidamente y sea relativamente fácil de solucionar. Esta práctica es esencial para conseguir una implementación más eficiente.

Creemos que el desarrollo basado en troncos es un requisito de la integración continua. Si no se realizan confirmaciones frecuentes en una rama común de un repositorio de código fuente compartido, no se está realizando integración continua. Si tus procesos de compilación y prueba están automatizados, pero los desarrolladores trabajan en ramas de función aisladas y de larga duración que se integran con poca frecuencia en una rama compartida, tampoco se está haciendo integración continua.

La entrega continua garantiza que la rama principal o troncal del código fuente de una aplicación siempre esté en un estado que permita su publicación. En otras palabras, si el gestor llega a tu mesa a las 16:30 h de un viernes y te dice que hay que publicar ya la última versión, podrías implementarla con solo pulsar un botón y sin miedo a fallos.

Esto supone tener un entorno de preproducción lo más idéntico posible al de producción y garantizar que se ejecuten pruebas automatizadas, de modo que todas las variables que puedan provocar un error se identifiquen antes de fusionar el código en la rama principal o troncal.

La implementación continua implica tener un nivel de operaciones y pruebas continuas tan robusto que las nuevas versiones de software se validen e implementen en un entorno de producción sin necesidad de intervención humana.

Es algo infrecuente y, en la mayoría de los casos, innecesario. Por lo general, solo las empresas unicornio con cientos o miles de desarrolladores y muchas publicaciones diarias requieren, o desean, este nivel de automatización.

Para comprender fácilmente la diferencia entre la entrega continua y la implementación continua, piensa en la entrega como el repartidor que te entrega un paquete y en la implementación como el momento en el que abres el paquete y usas el contenido. Si hubiera que modificar el producto en el momento entre que recibes el paquete y lo abres, el fabricante tendría un problema.

2. Feedback continuo

El principal punto problemático del antiguo método de desarrollo de software en cascada (y lo que llevó al diseño de metodologías ágiles) era la falta de feedback puntual. En un momento en el que se tardaba meses o años en llevar nuevas funciones de la idea a la implementación, estaba casi asegurado que el resultado final sería algo distinto de lo que el cliente esperaba o deseaba. La metodología ágil permitió que los desarrolladores recibieran feedback más rápido de las partes interesadas. Ahora, con DevOps, los desarrolladores reciben feedback continuo no solo de las partes interesadas, sino también de las pruebas y la supervisión sistemáticas del código a lo largo de la canalización.

Las pruebas continuas son un componente fundamental de todas las canalizaciones de DevOps y uno de los principales mecanismos del feedback continuo. En un proceso de DevOps, los cambios pasan continuamente de desarrollo a pruebas e implementación, lo que no solo agiliza la publicación, sino que mejora la calidad del producto. Esto significa que existen pruebas automatizadas en toda la canalización, incluidas pruebas unitarias que se ejecutan en cada cambio de compilación, prueba de humo, prueba funcional y prueba de extremo a extremo.

La supervisión continua es otro componente importante del feedback continuo. Un enfoque de DevOps implica usar la supervisión continua en los entornos de ensayo, pruebas e incluso desarrollo. A veces es práctico supervisar los entornos de preproducción para detectar comportamientos anómalos, pero en general es un enfoque que se utiliza para evaluar continuamente el estado y el rendimiento de las aplicaciones en producción.

Existen numerosas herramientas y servicios para proporcionar esta funcionalidad, y puede implicar cualquier cosa, desde supervisar la infraestructura local o en la nube, como los recursos de servidor o redes, hasta el rendimiento de la aplicación o las interfaces API.

3. Operaciones continuas

El término operaciones continuas es relativamente nuevo y menos común, y las definiciones varían. Una forma de interpretarlo es como "tiempo de actividad continuo". Por ejemplo, imaginemos una estrategia de implementación azul/verde en la que tienes dos entornos de producción independientes, uno azul (de acceso público) y otro verde (no accesible públicamente). En esta situación, el nuevo código se implementa en el entorno verde y, cuando se confirma su funcionamiento, se acciona un interruptor (normalmente en un equilibrador de carga) y el tráfico pasa del sistema azul al verde. Como resultado, no hay tiempo de inactividad para los usuarios finales.

Otra forma de concebir las operaciones continuas es como alertas continuas. En este enfoque, el personal de ingeniería está de guardia y se le notifica si se producen anomalías en el rendimiento de la aplicación o la infraestructura. En la mayoría de los casos, las alertas continuas van de la mano de la supervisión continua.