DevOps, integración continua y entrega continua... ¿Cuántas palabras de moda más podríamos incluir en la primera frase de una entrada de blog? Lo más probable es que si has pasado algún tiempo en el mundo de la ingeniería de software, te hayas encontrado con estos términos. El problema es que a veces estos términos se utilizan indistintamente, cuando en realidad son disciplinas distintas.
DevOps es el concepto general utilizado para describir las iniciativas para acelerar y automatizar el desarrollo y la entrega de software. Los equipos de desarrollo que buscan adoptar las prácticas de DevOps pueden intentar mejorar el ciclo de vida del desarrollo de software (SDLC), mejorar el proceso de entrega de software o reducir la cantidad de intervención humana necesaria.
La integración continua y la entrega continua son dos metodologías diferentes bajo el paraguas de DevOps.
CI significa integración continua, una práctica fundamental de DevOps en la que los desarrolladores fusionan con frecuencia los cambios de código en un repositorio central en el que se ejecutan compilaciones y pruebas automatizadas. Pero CD puede significar entrega continua o despliegue continuo.
¿Cuáles son las diferencias entre la integración continua, la entrega continua y el despliegue continuo (CI/CD)?
Los desarrolladores que practican la integración continua fusionan sus cambios con la rama principal tan a menudo como sea posible.
Los cambios del desarrollador se validan creando una compilación y ejecutando pruebas automatizadas contra la compilación. De este modo, se evitan los problemas de integración que pueden producirse cuando se espera al día de la publicación para fusionar los cambios en la rama de publicación.
La integración continua pone un gran énfasis en la automatización de las pruebas para comprobar que la aplicación no se rompe cada vez que se integran nuevos commits en la rama principal.
Si quieres saber de esto con ejemplos prácticos te dejaré un video interesante donde te lo contamos; sin embargo, es importante que te lleves la teoría y fomentes tu capacidad lectora 😊
¿Qué es la entrega continua (CD)?
La entrega continua es la automatización de los pasos para llevar los cambios a producción de forma segura.
Las entregas pueden ser muy variables e incongruentes entre los equipos. Los equipos individuales suelen tener sus propios requisitos, sus propias herramientas y su propio calendario de lanzamientos.
Recorrer todos los pasos necesarios y las modificaciones necesarias para propagar/soportar los cambios o las nuevas características en una gran organización puede ser desalentador.
La entrega continua reúne todos los pasos de las pruebas, los despliegues incrementales/ambientales y los pasos de validación para llevar los cambios a la producción de forma segura. El objetivo final de las herramientas de CD es "pulsar un botón" para poner los cambios en producción.
Diferencias entre la CI y la CD
La CI y la CD van de la mano y suelen confundirse para significar una sola cosa, pero los procesos son completamente distintos.
La integración continua (CI) permite a los equipos de desarrollo de software y a los flujos de trabajo ayudar a construir y probar el código más rápidamente.
Muchas organizaciones están bajo la presión de entregar rápidamente con innovación y calidad. Trabajar con el código implica desarrollar, fusionar conflictos, gestionar el código y probarlo, lo que contribuye a que se produzcan largos plazos de despliegue, despliegues poco frecuentes y altas tasas de fracaso de los cambios.
La solución es utilizar CI para integrar los cambios de desarrollo de forma automatizada, mejorando así la cadencia y el proceso de desarrollo de características.
Por otro lado CD como ya lo comentamos anteriormente tiene como objetivo entregar de forma segura y repetida un artefacto en un entorno de producción.
El proceso de CD ayuda a automatizar la operatividad de los servicios e implica la liberación, el despliegue y la supervisión de las aplicaciones. A medida que un artefacto es promovido a entornos de producción o superiores, se añade más rigor al proceso de verificación.
Añadir pruebas adicionales al proceso de comprobación y a cada etapa o flujo de trabajo de un entorno permite a los equipos detectar problemas antes de que los clientes los encuentren.
Cómo reconocer si realmente está haciendo CI/CD
Confundir los dos términos CI y CD engaña a las organizaciones para que piensen que están haciendo ambas cosas cuando la mayoría de las veces sólo están ejecutando una extensión de la Integración Continua. 🙄
Ejecutar un servidor de CI como Jenkins o Bamboo para integrar los cambios de código a través de la automatización y de un pipeline no significa que se esté haciendo CD. Para participar con éxito en la CD, los despliegues a la producción también deben ser continuos.
¿Cómo funcionan conjuntamente la integración continua y la entrega continua?
Hoy en día, se hace hincapié en el cambio a la izquierda para garantizar que los problemas se detecten en una fase temprana del proceso de entrega de software.
La integración continua y la entrega continua trabajan conjuntamente para garantizar que las organizaciones tengan la capacidad y la visibilidad necesarias para detectar y solucionar los defectos/errores y los posibles fallos de producción, o los incidentes que, de otro modo, podrían ser perjudiciales para una empresa.
Los conductos de CI/CD actúan como conductos de entrega automatizados, imitando todo el ciclo de vida de desarrollo de software (SDLC) que, de otro modo, puede ser difícil de entender, mejorar, compartir y controlar.
Mejores prácticas de integración continua y entrega continua
Mejores prácticas de CI
Las construcciones automatizadas deben ser rápidas. El proceso de construcción se ejecuta varias veces al día, con disparadores desde un repositorio de código fuente.
El tiempo de espera de los resultados puede convertirse en una bola de nieve y hacer que la productividad de los desarrolladores disminuya.La confianza en la compilación y el empaquetado desplegable es diferente de la confianza en el despliegue y la posterior liberación.
Es necesario ser estratégico en cuanto a dónde aplicar partes del conjunto de pruebas para evitar sobrecargar el proceso de integración continua. Una línea en la arena debe ser que la Integración Continua aborde la creación de confianza centrada en los artefactos (por ejemplo, pruebas unitarias, pruebas de integración y escaneos de artefactos).
Las pruebas que tienen en cuenta otros artefactos y dependencias y/o la infraestructura de la aplicación son más adecuadas para el proceso de Entrega Continua. Después de que la construcción se compruebe en un repositorio central y se fusione con la rama principal, el siguiente paso para llevar su idea a la producción es el proceso de promoción/despliegue.
Finalmente vamos a concluir este articulo con el paso de la integración continua al despliegue continuo.
Pasar de la integración continua al despliegue continuo
Si acabas de empezar con un nuevo proyecto sin usuarios todavía, podría ser fácil para ti desplegar cada commit a producción. Incluso podrías empezar automatizando tus despliegues y lanzando tu versión alfa a producción sin clientes.
Entonces puedes aumentar tu cultura de pruebas y asegurarte de que aumentas la cobertura del código a medida que construyes tu aplicación. Para el momento en que esté listo para incorporar usuarios, tendrá un gran proceso de despliegue continuo en el que todos los nuevos cambios se prueban antes de ser liberados automáticamente a producción.
Pero si ya tienes una aplicación con clientes, deberías ir más despacio y empezar con la integración continua y la entrega continua. Comienza por implementar pruebas unitarias básicas que se ejecuten automáticamente no hay necesidad de centrarse todavía en la ejecución de pruebas complejas de extremo a extremo.
En cambio, deberías intentar automatizar tus despliegues tan pronto como sea posible y llegar a una etapa en la que los despliegues en tus entornos de preparación se realicen automáticamente. La razón es que, si tienes despliegues automáticos, puedes centrar tu energía en mejorar tus pruebas en lugar de detener las cosas periódicamente para coordinar una liberación.
Una vez que puedas empezar a liberar software a diario, puedes considerar el despliegue continuo. Pero asegúrate de que el resto del equipo y departamentos también estén preparados: documentación, soporte, marketing, entre otros. Estas funciones tendrán que adaptarse a la nueva cadencia de lanzamientos, y es importante que no se pierdan los cambios significativos que puedan afectar a los clientes.
