Este artículo de Rancher Labs
Continuous Integration and Continuous Delivery (CI / CD) es una de las fuerzas impulsoras detrás de DevOps. Si su empresa está considerando usar DevOps, entonces CI / CD definitivamente es parte de ello. Pero, ¿qué significa exactamente CI / CD? ¿Por qué es tan importante? Para planificar estratégicamente su kit de herramientas DevOps y la implementación de TI, es esencial una comprensión profunda de CI / CD. En este artículo, discutiremos las dificultades que CI / CD necesita resolver, las herramientas necesarias y los beneficios esperados.
Primero, comenzamos con el panorama general. DevOps tiene como objetivo crear un flujo de trabajo fluido y minimizar las transferencias y establecer ciclos de retroalimentación rápidos. ¿Qué significa esto? El trabajo avanzará desde el primer paso, y en un estado ideal, no hay necesidad de regresar y repararlo, ya que deberían poder verificar y reparar el problema. Para esto, los desarrolladores necesitan bucles de retroalimentación rápidos. Esta retroalimentación se proporciona a través de pruebas automáticas rápidas, y esta prueba verificará que el código funciona como se esperaba antes de pasar a la siguiente etapa.
Para reducir las transferencias, los equipos con menos miembros utilizarán características más pequeñas y controlarán todo el proceso: crear solicitudes, enviar, QA e implementar. La atención se centra en implementar rápidamente pequeños fragmentos de código, porque cuanto más pequeños son los cambios, más fácil es diagnosticar, reparar y remediar.
La integración continua (CI) implementa un proceso rápido desde el primer paso hasta el último paso, y lo extiende al despliegue de producción real a través de la entrega continua (CD). Lo llamamos CI / CD. Ahora, comenzamos a entenderlos en profundidad.
Exploración profunda de la integración continua.
Primero, nos enfocamos en la parte de CI (integración continua) de CI / CD. De hecho, la mayoría de las empresas solo implementan CI. La finalización de todo el CI / CD requiere que la empresa ya sea una empresa DevOps madura.
Cuando se trata de la integración, nos referimos a la integración del código (incluidas las actualizaciones o la adición de nuevas funciones) desarrollado por los programadores en su computadora local en la base del código. Este proceso enfrentará los siguientes tres desafíos:
-
Realice un seguimiento de todos los cambios para que, cuando ocurra un error, aún pueda volver al estado anterior para minimizar la interrupción del servicio.
-
Cuando varios desarrolladores trabajan en el mismo proyecto al mismo tiempo, es necesario gestionar los conflictos.
- Los errores deben detectarse antes de agregar un nuevo código a la base de código
A continuación, discutiremos tres herramientas que pueden resolver los puntos de dolor anteriores.
1. Control de versiones
A medida que el código se transfiere del desarrollador al personal de operación y mantenimiento, continuará ajustándose según los resultados de la prueba. Todos los cambios son capturados por el sistema de control de versiones. El control de versiones es una herramienta de software que ayuda a los desarrolladores a administrar los cambios en el código fuente. Realiza un seguimiento de todos los cambios en un tipo especial de base de datos.
Idealmente, se capturarán todas las partes del sistema de software, incluyendo:
-
Código fuente
-
Activos
-
Medio ambiente
-
Documento de desarrollo de software
- Cualquier cambio en los archivos almacenados en el sistema
2. rama maestra y de desarrollo
Por lo general, hay varios desarrolladores trabajando juntos en el mismo proyecto, tal vez unas pocas personas o cientos de programadores, por lo que esto puede causar confusión. Para no comprometer la estabilidad o mitigar el riesgo de introducir errores en la rama maestra del control de versiones, cada desarrollador debe procesar diferentes partes del sistema en paralelo. Realizan esta operación a través de la "rama" en la computadora local.
Pero trabajar en una sucursal no es una solución en sí misma. El código en el que trabaja cada desarrollador debe integrarse en una base de código en constante expansión.
Cuanto más tiempo trabaje un desarrollador en una sucursal sin comprometerse con la rama maestra, más difícil será integrarse y fusionarse con los cambios de todos en la maestra. Por lo tanto, debido a que cuanto más tiempo el desarrollador procesa el código sin enviar el código, más difícil es obtener el código, por lo que lógicamente, la frecuencia de envío del código debe aumentarse. Pero un mejor enfoque es hacerlo de integración continua.
La siguiente figura muestra cómo visualizar diferentes ramas. El azul es la rama maestra, otros colores son desarrolladores individuales que trabajan en sus propias ramas, y estas ramas finalmente se fusionan en la rama maestra.
Sin embargo, incluso el mecanismo de ramificación no es suave. Incluso si los desarrolladores envían código todos los días, aún se producen conflictos. Porque otros miembros del equipo continuarán haciendo cambios sin considerar las demandas de todas las partes. De hecho, los problemas de integración a menudo requieren retrabajo, incluida la fusión manual de cambios conflictivos. Pero es mucho más simple encontrar y resolver conflictos en un día de trabajo que cuando el equipo de desarrollo trabaja toda la semana o el mes sin lidiar con conflictos. Por lo tanto, aunque no se pueden evitar los problemas de integración, CI puede reducir en gran medida los problemas de integración.
3. Implementar tuberías y pruebas automatizadas
Parte del trabajo de QA es identificar errores y garantizar que el código sea desplegable. En el proceso tradicional, una vez que se completa la implementación, un equipo separado es responsable del control de calidad. Debido a que los desarrolladores generalmente solo realizan algunas pruebas por año, solo se enteraron del error unos meses después de introducir los cambios. Para entonces, el vínculo entre causa y efecto puede haber sido difícil de verificar, haciendo que el diagnóstico sea cada vez más difícil. Pero las pruebas automatizadas resuelven este problema.
Después de usar la canalización de implementación, cada vez que agrega código al control de versiones, se activa una serie de pruebas. La canalización crea y prueba automáticamente el código para asegurarse de que funciona como se espera, y puede continuar funcionando una vez integrado en la base del código. Aunque el código se puede ejecutar perfectamente en el entorno de prueba, aún puede fallar desafortunadamente en el entorno de producción, porque el entorno de producción y todas las dependencias afectarán el rendimiento del código. La dependencia no es parte de la aplicación, pero aún debe ejecutarse. Por ejemplo, bases de datos, almacenamiento de datos / objetos y API que los servicios y las aplicaciones pueden necesitar llamar. Por lo tanto, el entorno de desarrollo y prueba debe imitar el entorno de producción. Además, todas las dependencias se deben probar con código.
En resumen, hay tres fases de prueba al implementar el código, cada una de las cuales agregará complejidad adicional:
(1) Verifique que el código en sí mismo funcione como se esperaba;
(2) Continuar verificando en la base del código;
(3) El rendimiento de la verificación permanece sin cambios en un entorno de producción con todas las dependencias.
Si el código se envía al control de versiones todos los días, se puede probar automáticamente, y cualquier error de compilación, prueba o integración se marcará el día en que se introduce el código, por lo que se puede solucionar de inmediato. Esto garantiza que el código esté siempre en un estado desplegable y transportable, denominado compilación ecológica.
Las pruebas automatizadas permiten a los desarrolladores aumentar la frecuencia de las pruebas y la integración, desde la ejecución periódica hasta la integración de pruebas continuas, y encontrar problemas con restricciones mínimas. El peor de los casos es solo un día de trabajo perdido.
Controversia sobre el control de versiones
Se ha debatido si se debe almacenar información confidencial (como tokens de acceso, claves y contraseñas) en el control de versiones. Por un lado, algunas personas piensan que todo (incluido el secreto) debe almacenarse aquí, para llevar este método al límite. Pero algunas personas piensan que esta es una mala práctica, y que la información confidencial debe almacenarse por separado.
El control de versiones permite a los desarrolladores comparar, fusionar y restaurar revisiones anteriores. Al permitirles restaurar rápidamente el sistema en producción a la versión anterior en caso de un problema, el riesgo se minimiza. Por esta razón, no importa cuán pequeña sea la versión, todas las actualizaciones y cambios deben ser rastreados en el control de versiones. Si este no es el caso, el código en producción no coincidirá con el código en los entornos de desarrollo y prueba, lo que generará inconsistencias.
En resumen, el control de versiones es una fuente única de verdad, que incluye el estado esperado del sistema y todos los estados anteriores. Al colocar todos los componentes en el entorno de producción en el control de versiones, los desarrolladores pueden reproducir de forma repetida y confiable todos los componentes en el sistema de software de trabajo. Esta es la clave para habilitar la llamada infraestructura inmutable, que discutiremos más adelante.
Entrega continua: amplíe CI para una implementación de código sin problemas
Incluso con una integración continua, el proceso de implementación de código en producción sigue siendo manual, tedioso y propenso a errores. Si este es el caso, entonces obviamente el código no se implementará en producción con frecuencia. El departamento de TI intentará evitar realizar tareas difíciles y peligrosas tanto como sea posible, lo que conducirá a una diferencia cada vez mayor entre el código que se implementará y el código que se ejecuta en producción, lo que aumentará aún más el peligro y luego formará un círculo vicioso. La respuesta a este círculo vicioso es habilitar la parte de CD de CI / CD.
El CD expande el CI para garantizar que el código se ejecute sin problemas en el entorno de producción antes de que el código se extienda a toda la base de usuarios. Los métodos de CD más comunes son las implementaciones canarias y azul verdosas.
Durante la implementación azul-verde, TI implementará un nuevo componente o versión de la aplicación junto con la versión actual. La nueva versión (verde) se implementa en producción y se prueba, mientras que la versión actual (azul) todavía está disponible. Si la nueva versión del código funciona bien, todos los usuarios cambiarán a la nueva versión.
También hay dos versiones de Canary Deployment: la versión actual y la versión actualizada. TI comenzó a enrutar una pequeña cantidad de solicitudes de usuarios a la nueva versión. El código y el comportamiento del usuario son monitoreados continuamente. Si la tasa de error o las quejas de los usuarios no han aumentado, la proporción de solicitudes enrutadas a la nueva versión aumentará gradualmente (por ejemplo, 1%, 10%, 50% y finalmente al 100%). Una vez que todas las solicitudes se envían a la nueva versión, la versión anterior se retirará o eliminará automáticamente.
Crear autoservicio a través del entorno a pedido
Ahora que hemos estudiado CI, CD y sus respectivas herramientas y métodos, analicemos el entorno y la infraestructura. CI / CD necesita un enfoque innovador.
Como hemos visto, las pruebas automatizadas permiten a los desarrolladores realizar el control de calidad por su cuenta. Para garantizar que todo funcione correctamente en la producción, deben utilizar un entorno similar a la producción durante todo el proceso de desarrollo y prueba.
Tradicionalmente, los desarrolladores tienen que solicitar (manualmente) configurar un entorno de prueba del equipo de Ops. Este proceso puede llevar semanas, a veces incluso meses. Además, los entornos de prueba implementados manualmente a menudo tienen errores de configuración o son muy diferentes del entorno de producción, por lo que incluso si el código pasa todas las pruebas previas a la implementación, seguirá causando problemas de producción.
La parte clave de CI / CD es proporcionar a los desarrolladores un entorno bajo demanda similar a la producción para que puedan ejecutarse en sus propias estaciones de trabajo. ¿Por qué es esto importante? Los desarrolladores solo saben cómo se comporta el código en la producción cuando se implementan y prueban en las mismas condiciones. Si prueban el código en diferentes entornos, pueden encontrar que el código es incompatible cuando el código finalmente se implementa en el entorno de producción, lo que tiene un gran impacto en el cliente en este momento, y es demasiado tarde para resolver el problema.
Infraestructura inmutable: ganado y mascotas.
Cuando discutimos el sistema de control de versiones, hablamos sobre la necesidad de codificar el entorno con todos los demás componentes de la aplicación. Discutamos estos entornos más a fondo.
Si las especificaciones del entorno se definen y codifican en el control de versiones, copiar el entorno a medida que aumenta la capacidad (expansión horizontal) es tan simple como presionar un botón (aunque es probable que se automatice a través de Kubernetes más adelante).
Escalar significa aumentar la potencia informática durante las horas pico. Por ejemplo, el uso de Netflix alcanzó su punto máximo todos los viernes por la noche, y luego volvió a la normalidad en algún momento después de la medianoche. Para garantizar el disfrute del video sin búfer, Netflix copió su componente de control de flujo (ya codificado en el control de versión) para satisfacer la demanda. Luego, después de restaurar el flujo, se destruyen todas las llamadas copias y la capacidad del flujo se restablece a la normalidad.
Para lograr esto, es esencial que siempre que se implementen actualizaciones de infraestructura o aplicaciones, estas infraestructuras o aplicaciones se copien automáticamente a otros lugares y se coloquen en el control de versiones. Esto garantizará que siempre que se cree un nuevo entorno, coincida con el entorno de toda la tubería (desde el desarrollo hasta el control de calidad y la producción). Por ejemplo, si Netflix quiere actualizar su servicio de transmisión y se olvida de capturar los cambios de control de versión, replicará componentes defectuosos u obsoletos durante las horas pico, causando problemas e incluso interrupciones del servicio.
Debido a que ha dominado la codificación del entorno en el control de versiones, el cambio manual del entorno no es una práctica recomendada, ya que cualquier operación manual es propensa a errores. En su lugar, coloque los cambios en el control de versiones y vuelva a crear el entorno (y el código) desde cero. Esto se llama una infraestructura inmutable. Estos son los mismos principios aplicados a la infraestructura discutida en la sección CI / CD.
Es posible que haya escuchado la metáfora del ganado y las mascotas. Esta analogía es bastante apropiada aquí. Anteriormente, la infraestructura se consideraba una mascota. Si hay un problema, intentará resolverlo para que pueda sobrevivir. Hoy, la infraestructura es considerada como ganado. Si no funciona correctamente o necesita actualizarse, elimínelo y comience un nuevo entorno. Esto es muy poderoso y reduce en gran medida el riesgo de problemas para infiltrarse en el sistema.
Desenganche de lanzamiento y despliegue
Tradicionalmente, los lanzamientos de software dependen de las fechas de lanzamiento al mercado. Por lo tanto, las nuevas funciones que se lanzarán se implementarán en producción el día anterior a la fecha del anuncio. Sin embargo, sabemos que siempre es arriesgado lanzar funciones o actualizaciones en producción, especialmente si libera toda la función de una vez. Por lo tanto, agrupar la implementación y el lanzamiento juntos hará que los departamentos de TI siempre tengan que asustarse por las fallas. Imagine que si se produce un problema importante el día antes de la promoción generalizada, el equipo de TI entrará en pánico y provocará grandes reacciones adversas en los clientes y los medios de comunicación.
Un mejor enfoque es desacoplar la implementación de la versión. Aunque estas dos palabras se usan indistintamente, son dos procesos separados. La implementación significa instalar la versión del software en cualquier entorno (incluido el entorno de producción). No necesariamente tiene que estar asociado con el lanzamiento. Por otro lado, publicar significa proporcionar una nueva funcionalidad a la base de clientes. El propósito de la implementación frecuente de la producción durante todo el proceso de desarrollo de funciones es reducir el riesgo de interrupción del servicio, que corre a cargo del departamento de TI. Por otro lado, cuándo mostrar a los clientes nuevas características debe ser una decisión comercial, no una decisión técnica.
El largo ciclo de implementación determina con qué frecuencia se lanzan nuevas características. Si la TI se puede implementar a pedido, la velocidad a la que se exponen las nuevas funciones debería ser una decisión comercial y de marketing.
Conclusión
En resumen, CI requiere una integración continua de código en la base de código para detectar errores cuando ocurren, minimizando así el reproceso. Para implementar este enfoque, se requieren tres herramientas: control de versiones para rastrear todos los cambios y hacer que todo el equipo esté disponible para la última versión del código fuente; maestro, el desarrollador responsable de las fusiones y actualizaciones de su sucursal diariamente; la tubería de implementación desencadenará una serie de pruebas Básicamente es QA automáticamente.
El CD extiende CI para verificar que el código esté en un estado desplegable y lo libera automáticamente al entorno de producción. Para este fin, se requiere una organización DevOps madura, que primero debe dominar el CI antes de intentar usar los CD.
Si se implementa correctamente, CI (/ CD) aumentará en gran medida la productividad de su equipo de TI. Su sistema o aplicación mejora constantemente, mientras minimiza el riesgo de implementación, lo que mejora el ciclo positivo de productividad y satisfacción de los empleados. Además, la rápida introducción de nuevas características y actualizaciones puede impulsar la innovación, lo que a su vez brinda valor a los usuarios más rápido y con mayor frecuencia. Obviamente, a medida que más y más organizaciones adopten estos métodos DevOps, ya que los métodos tradicionales no pueden competir con CI / CD, aumentará la presión sobre las empresas que no adoptan métodos DevOps.
Apéndice: Implementar el conjunto de pruebas de tuberías
- Las pruebas de integración examinan cómo una aplicación interactúa con otras aplicaciones y servicios para garantizar que el código interactúa correctamente con estas dependencias. Se pueden usar versiones virtuales o simuladas de servicios remotos para recrear con precisión el entorno de producción.
- Las pruebas de aceptación verifican que se satisfacen las necesidades comerciales para garantizar que la función o aplicación proporcione al usuario final el valor requerido.
- Las pruebas de rendimiento verifican cómo funciona la aplicación en toda la pila (código, base de datos, almacenamiento, red, virtualización) bajo cargas de producción. Los problemas causados por decisiones arquitectónicas o limitaciones inesperadas de redes, bases de datos, almacenamiento u otros sistemas deben resolverse aquí.
- Las pruebas no funcionales incluyen usabilidad, escalabilidad, rendimiento, capacidad, seguridad, etc. Estos requisitos dependen de la configuración correcta del entorno. La prueba verificará que el entorno se haya construido y configurado correctamente.
- La prueba de humo verifica que la aplicación se pueda conectar a todos los sistemas de soporte, como bases de datos, servicios o sistemas de entrega de información; las pruebas de humo suelen ser manuales.
También hay pruebas de seguridad automatizadas, así como pruebas exploratorias y otras pruebas manuales o intensivas en recursos. Nuestro objetivo es detectar más errores lo antes posible y utilizar estas pruebas que requieren más tiempo para verificar los requisitos de alto nivel e integrar completamente el producto en un entorno lo más cercano posible a la producción.