Integración vs. Entrega vs. Implementación continua
Si lleva un tiempo en el mundo del desarrollo de software, probablemente ya se haya encontrado alguna vez las abreviaturas CI/CD.
La integración, la entrega y la implementación continuas son prácticas destinadas a acelerar el proceso de lanzamiento de software abreviando los bucles de feedback y automatizando las tareas repetitivas. Estas prácticas desempeñan un papel crucial a lo hora de hacer realidad el principio de entregar a los usuarios con frecuencia un software de valor y que funcione.
Para los equipos que han encontrado su ritmo y han adoptado las herramientas de CI/CD y procesos adecuados para un ciclo de lanzamiento con regularidad, un proceso de CI/CD que funcione bien es todo un orgullo; un signo de que los desarrolladores están utilizando sus herramientas para mejorar tanto su propio entorno como el producto final que están creando.
No obstante, para alguien nuevo en esta práctica, transformar su proceso de compilación, pruebas e implementación en un sistema automatizado puede parecer abrumador e imposible. Eso no tiene por qué ser así. Lo bonito de crear un proceso de CI/CD es que se presta perfectamente al desglose en etapas por separado, cada una basada en la anterior. Veámoslas una tras otra.
Echemos un vistazo a lo que significa CI vs CD y a las características principales de cada una.
¿Qué es la integración continua?
Integración continua se trata de ejecutar los pasos que tradicionalmente se llevaban a cabo durante la "integración", poco a poco y más frecuentemente a través del proceso de desarrollo, en lugar de esperar hasta que el código esté completo para reunirlo todo y ponerlo a prueba.
Si hay más de una persona trabajando en un producto de software (lo cual es lo habitual en la mayoría del software comercial y de código abierto), en algún momento tendrá que combinar las piezas en las que ha trabajado cada desarrollador y comprobar que el resultado final funciona como debería. Con la integración continua, esto sucede al menos una vez al día, si no más.
La idea es sencilla. Si pospone la integración hasta que se haya escrito todo el código, es muy posible que tenga que dedicar una gran cantidad tiempo a retirar y reescribir fragmentos de su código para lograr que la solución compile, por no hablar de conseguir que funcione como debe. El código es algo complejo. Incluso con un diseño inicial detallado, es increíblemente difícil predecir exactamente cómo la lógica interactuará y evitará cualquier incidencia. Cuanto más código haya, mayor será su complejidad y más habrá que deshacer cuando algo no funcione.
Con la integración continua, sus desarrolladores comparten sus cambios confirmándolos al control de fuentes con regularidad (al menos una vez al día) y comprueban que la solución compila y supera las pruebas. Esto significa que, si algo no va bien, hay muchos menos cambios que revisar hasta encontrar la fuente del problema. Obtener feedback con rapidez también facilita la resolución de cualquier problema, puesto que no ha perdido el contexto de lo que está haciendo.
Un buen proceso de integración continua requiere unos pocos ingredientes esenciales:
Utilice el control de fuentes
Un sistema de control de fuentes (es decir, de versiones) es absolutamente esencial. Si no dispone de uno, o solo parte de su código se encuentra en control de fuentes, el primer paso es obtener todo lo que contiene e implicar a todos lo que lo usan.
Confirme pronto, confirme a menudo
Una vez que utilice el control de fuentes, haga que todo el mundo confirme pronto y a menudo. El tamaño de la tarea puede influir aquí; dividir cada tarea en fragmentos más pequeños hace que resulte más fácil completar y probar un conjunto de cambios localmente para que estén listos para su confirmación.
Compile su solución en cada confirmación
Compartir con regularidad los cambios en su código con todos los participantes en el proyecto es solo el principio. El siguiente paso es comprobar que la solución todavía puede compilarse con los últimos cambios. Aunque esto puede hacerse manualmente, es mucho más fácil y eficiente desencadenar la compilación automáticamente, y aquí es donde entra en escena un servidor de integración continua.
Automatice las pruebas
Una compilación correcta es buena señal, pero para una mayor confianza, vale la pena ejecutar varias pruebas. De nuevo, es mucho más fácil y eficiente ejecutar las pruebas de forma automática que hacerlo de modo manual. Aunque programar pruebas automatizadas puede parecer un trabajo duro, dará sus frutos en cuanto las ejecute en cada compilación para obtener un feedback rápido.
Haga caso al feedback
Solo vale la pena automatizar compilaciones y pruebas si va a hacer algo con la información que reciba. Las herramientas de integración continua ofrecen una gran variedad de mecanismos de feedback, desde paneles y radiadores a la integración con plataformas de mensajes instantáneos.
Cree una cultura de DevOps
Para disfrutar realmente de las ventajas de la integración continua, tiene que crear una cultura de equipo en la que todo el mundo se responsabilice de reparar las compilaciones incorrectas o las pruebas fallidas. Echar la culpa a quien hiciese la última confirmación es contraproducente, puesto que hace que su equipo no desee confirmar los cambios pronto y a menudo a pesar de que redunde en beneficio de todos.
Reunir todos estos ingredientes le da un feedback rápido y regular acerca de su código. Al comprobar que cualquier cambio en la base de código (ya sea la solución de un error, una refactorización o parte de una nueva funcionalidad) da lugar a una compilación limpia que supera las pruebas, los equipos pueden evitar trabajar sobre unos cimientos inestables, y la inevitable reelaboración que eso conlleva. Implementar la integración continua propiamente dicha es un gran paso para acelerar el proceso de entregar a sus usuarios software que funcione.
La entrega continua
La entrega continua se basa en los cimientos de la automatización de compilaciones y pruebas establecidos con la integración continua.
Con la entrega continua, convierte en un proceso automatizado los pasos manuales utilizados para lanzar un build de su software a la producción.
Aunque anteriormente puede que fuese necesario que los desarrolladores entregasen su trabajo a los ingenieros de pruebas y, a continuación, estos lo pasaran a los jefes de lanzamiento, con la entrega continua su equipo (que podría incluir a personas de diversas disciplinas) tiene en sus manos el proceso completo de compilar, probar y lanzar el producto. Esto supone varias ventajas:
- Evitando los silos tradicionales, su equipo de desarrollo comprende mejor las necesidades empresariales y operativas para entregar su producto a sus usuarios.
- A su vez, esto supone la oportunidad de aplicar prácticas de desarrollo al que solía ser un proceso manual y a menudo bastante tedioso.
- Automatizar los pasos de entrega de un producto no solo acelera el proceso, sino que también reduce el riesgo de errores y lo hace más estable y fiable.
Los pasos a seguir para entregar software a sus usuarios (y, así, las etapas necesarias en el proceso de entrega) varían según las necesidades de la empresa y los usuarios, pero es habitual implementar en al menos un entorno de preproducción antes del lanzamiento al público.
Se puede tratar de entornos de pruebas para capas adicionales de testeo, como pruebas de seguridad, carga y rendimiento; entornos de pruebas tipo sandbox para que los equipos de asistencia y ventas se familiaricen con las nuevas funcionalidades; y entornos de pruebas de aceptación para que los equipos de calidad y de producto comprueben que los cambios funcionan como deberían.
Con la entrega continua, cada compilación correcta se implementa automáticamente en cada entorno de preproducción, confiando en que la calidad aumente en cada etapa.
Se trata de un objetivo que vale la pena, pero que requiere algo de esfuerzo para su puesta en práctica:
Compile una vez
Solo haciendo avanzar el mismo artefacto de compilación a través de cada etapa del proceso podrá confiar en que ha superado todas las etapas de pruebas previas.
Almacene la configuración en el control de versiones
Mantener todos los archivos de configuración en el control de versiones le ayuda a asegurarse de que las implementaciones sean coherentes y repetibles.
Automatice cada implementación
Debería crearse un script para la implementación en cada entorno, de modo que pueda ejecutarse automáticamente y, así, repetirse siempre igual en cada ocasión. Para lanzamiento al público convendría elaborar un script por el mismo motivo, pero con la entrega continua este último paso no es automático.
Limpie los entornos
Para que el enfoque sea totalmente coherente, los propios entornos deben restablecerse a las mismas condiciones para cada nueva implementación. Gracias a los contenedores, esto resulta mucho más sencillo de implementar, ya sea en la infraestructura local o en la nube.
Separe los posibles problemas de entorno
Para automatizar la implementación del mismo artefacto en cada entorno, tiene que existir una separación clara entre la propia aplicación y las variables o parámetros específicos de los entornos.
No olvide el mantenimiento del proceso
Al igual que sucede con la integración continua, solo vale la pena invertir en un proceso de entrega automatizado si lo mantiene. La CI/CD es tanto una cuestión de cultura de equipo como de procesos y herramientas. Para que sea eficaz, su equipo tiene que responsabilizarse de mantener el proceso y solucionar cualquier problema que surja, tanto si se debe a un error en el propio código como si es un problema con las pruebas o las implementaciones automatizadas.
Con la entrega continua, su equipo se responsabiliza de la entrega del software, y disfruta de la ventaja de recibir feedback puntual durante todo el proceso. Como sucede con la integración continua, esta práctica puede ir creciendo y mejorando con el tiempo.
La implementación continua
La implementación continua lleva las prácticas de integración y entrega continua a su conclusión lógica:
si una compilación pasa por todas las etapas previas del proceso correctamente, se lanza automáticamente a la producción. Esto significa que, tan pronto como un cambio en su software haya superado todas las pruebas, se entrega al usuario. La implementación continua abrevia el bucle de feedback desde el cambio en el código hasta el uso en la producción, y ofrece así al equipo una visión puntual de cómo se comportan sus cambios en el mundo real sin tener que sacrificar la calidad.
Aunque automatizar la implementación de software para la producción no es lo ideal para todos los productos y organizaciones, vale la pena tener en cuenta los pasos necesarios para ello, puesto que cada uno de los elementos resulta valioso por sí mismo:
Confíe en sus pruebas
Implementar para la producción automáticamente requiere una gran confianza en su proceso, especialmente en sus pruebas automatizadas. Es esencial una estupenda cultura de pruebas, en la que su equipo invierta en cobertura de pruebas y rendimiento, y priorice reparar la compilación y el proceso antes que lanzar nuevas funcionalidades.
Monitorice la producción
Incluso si toma todas las medidas anteriores, la implementación continua puede parecer una práctica arriesgada, ya que ¿qué sucede si un error no se detecta en las pruebas y aparece en la producción? Podría poner en riesgo su tiempo, dinero y reputación. Aunque podría surgir el mismo problema durante una implementación manual, no hay nada como un defecto crítico lanzado automáticamente por "el sistema" para perder la confianza de los grupos de interés. Es en estos casos cuando ser proactivo en la búsqueda de indicios de problemas en lugar de esperar a recibir informes de errores marca la diferencia. Monitorizar las estadísticas para detectar cualquier cambio en la norma, especialmente justo tras el lanzamiento, puede avisarle de incidencias antes de que causen un problema destacable a los usuarios.
Escoja qué desea lanzar
Una objeción habitual de los más noveles en la implementación continua es que, si los desarrolladores confirman pronto y a menudo y dejan salir las cosas sin una supervisión manual, los usuarios encontrarán funcionalidades incompletas o a medio terminar que no están listas para su uso. En lugar de recurrir a ramas y perderse las ventajas de la integración continua, la solución es utilizar feature flags. Así, sus desarrolladores pueden controlar qué es visible y qué queda oculto al usuario cuando escriben el código.
Simplifique su proceso
Si algo va mal durante lo producción, querrá ser capaz de responder rápidamente. En algunos casos, podría ser posible revertir el lanzamiento a la versión anterior. No obstante, a menudo las cosas no son tan sencillas: las migraciones de bases de datos y las soluciones de incidencias conocidas pueden evitarlo todo menos el avance, y la única opción es sacar una corrección. Saltarse estos pasos en su proceso es una falsa economía, puesto que es probable que introduzca otras incidencias que podrían haberse detectado si hubiese ejecutado las pruebas con normalidad. En su lugar, es mejor invertir en simplificar su proceso, desde el ritmo de compilación al rendimiento de pruebas. Esto no solo significa que puede implementar los cambios más rápido cuando lo necesite, sino que también abrevia los bucles de feedback a lo largo del proceso.
Controle el lanzamiento
Aunque la implementación continua significa lanzar automáticamente si todas las etapas previas se han completado con éxito, eso no significa que tenga que renunciar a todo el control. Para minimizar el riesgo y controlar el lanzamiento se utilizan varias prácticas de implementación. Los lanzamientos tipo canary le permiten tantear el terreno con una pequeña parte de sus usuarios inicialmente, mientras que las implementaciones azul-verde pueden utilizarse para gestionar la transición a una nueva versión.
La integración, la entrega y la implementación continuas, todas están destinadas a hacer llegar a los usuarios con frecuencia un software de valor y que funcione. Emplear un enfoque de "poco y a menudo" para la integración y el lanzamiento hace que el proceso sea más manejable y significa que los equipos siguen los pasos con más frecuencia y los perfeccionan.
Agregar la automatización a la ecuación no solo acelera el proceso, sino que lo hace más fiable. Cada paso del proceso se basa en el anterior, de modo que puede escoger cuánto necesita en un momento específico y volver a ampliarlo más adelante.
Diferencias esenciales entre CI (Continuous Integration) y CD (Continuous Delivery, Continuous Deployment)
La integración, la entrega y la implementación continuas son etapas secuenciales del proceso de entrega de software. Ayudan a los equipos a lanzar software con mayor rapidez, abreviar el bucle de feedback y automatizar tareas repetitivas. Identificar las diferencias clave entre la integración, la entrega y la implementación continuas es igual de importante que comprender cómo estos tres pasos se entrelazan para entregar software a los usuarios de forma fiable y estable.
La integración continua es la práctica de fusionar cualquier cambio nuevo en el código con la rama principal. La entrega continua automatiza las tareas manuales necesarias para compilar y probar software (por ejemplo, automatizando pruebas). La implementación continua es una continuación lógica de la práctica de automatizar los pasos de compilación y prueba, y en esta etapa el software se implementa una vez supera los puntos de comprobación necesarios.
En general, no se trata de una cuestión de CI vs CD, sino más bien de cómo funcionan juntos estos componentes a la hora de crear un proceso estable y fiable.