¿Qué es la integración continua? 

La integración continua es la primera parte del pipeline de CI/CD, un flujo de trabajo automatizado de DevOps que agiliza el proceso de entrega de software. La integración continua permite a los equipos de DevOps mejorar continuamente sus aplicaciones de software, recibir feedback coherente, detectar y corregir errores antes de que afecten al rendimiento del software y ofrecer software de mayor calidad en plazos de entrega más predecibles. 

Cuando un desarrollador confirma cambios de código en una rama principal o compartida de un sistema de control de versiones, la acción activa una herramienta de CI para realizar una “compilación” de la base de código actualizada. El sistema CI toma el nuevo código, lo compila con el código existente y lo empaqueta con todas las dependencias, como archivos de configuración, bibliotecas u otros recursos. Esto constituye “la construcción”.

Las pruebas automatizadas se ejecutan para validar esta compilación antes de que se produzca un "artefacto de compilación", el archivo resultante que se pasa para pruebas posteriores o a un entorno de producción. La siguiente parte del pipeline se denomina entrega continua.

CI se creó como solución a los retos asociados al desarrollo tradicional de software, concretamente a sus procesos de integración e implementación. En los paradigmas de desarrollo tradicionales, cada desarrollador es responsable de integrar manualmente el nuevo código en las nuevas iteraciones de una aplicación o servicio, lo que hace que la integración sea un proceso lento y propenso a errores, especialmente para los grandes equipos de desarrollo.

Las diferentes partes del código no siempre funcionaban bien juntas, y los desarrolladores integraban sus cambios en diferentes plazos (a veces en el último minuto), por lo que los comentarios sobre los problemas de integración se retrasaban a menudo. Cuando surgían problemas, los retrasos en el feedback dificultaban a los equipos averiguar qué cambio introdujo el problema y hacían que la depuración fuera un proceso más arduo.

Además, las pruebas de software eran poco frecuentes. Los equipos solían implementar grandes actualizaciones por lotes de una sola vez, lo que permitía que los errores se escaparan y se acumularan en la base de código. Como resultado, los equipos de desarrollo se encontraron con tareas de resolución de problemas más complicadas, tasas de fallos más elevadas y lanzamientos de código más lentos; las empresas perdieron ingresos por la ineficacia de los procesos; y los usuarios vieron más errores y fallos en el software.

La integración continua, un componente fundamental de las prácticas modernas de DevOps, los pipelines de integración continua/implementación continua (CI/CD) y las arquitecturas de microservicios, ayuda a optimizar el proceso de compilación al proporcionar feedback rápida sobre el rendimiento de la integración.

Con un sistema de CI, el código nuevo se añade a un repositorio central (normalmente, varias veces al día), donde permanece para su compilación y prueba. Si el sistema detecta un error, envía notificaciones, corrige el código y confirma que el código actualizado es correcto antes de fusionarlo completamente con la base de código del software.

Aunque la configuración exacta de un sistema de integración continua varía de un equipo a otro y de una empresa a otra, cada sistema de CI utiliza ciertos componentes y procesos para optimizar las tareas de integración de código.

La CI comienza con un repositorio central y compartido donde todos los desarrolladores confirman su código. Los repositorios centrales sirven como piedra angular de las prácticas de CI. Los sistemas de control de versiones (VCS), como Git y Bitbucket, suelen gestionar estos repositorios. Cuando los desarrolladores envían cambios, el repositorio central los rastrea, creando un historial completo de los cambios en el código que los equipos de desarrollo pueden utilizar para colaborar de forma más eficiente.

Los repositorios también utilizan técnicas de ramificación, que crean líneas de desarrollo separadas para aislar los cambios de código en curso de la base de código principal (la rama principal) y facilitar el desarrollo paralelo. La ramificación permite a los desarrolladores crear ramas de característica (para aislar característica específicas de la aplicación) y ramas de corta duración para separar su trabajo antes de fusionarlo nuevamente en la rama del código principal.

Gitflow, por ejemplo, es un modelo de ramificación basado en Git que asigna roles (como "principal", "característica", "desarrollar" y "lanzamiento") a diferentes ramas para gobernar cómo interactúan entre sí. Las ramas de Gitflow requieren que los desarrolladores creen ramas de característica y esperen hasta que la característica esté completa para fusionar los cambios de código en la rama principal.

Los servidores de CI son herramientas que centralizan y gestionan todas las operaciones de CI. Sirven como el centro de automatización del proceso de CI. Los servidores de CI monitorizan los repositorios en busca de cambios de código e inician y potencian los pipelines de CI predefinidos cuando se detectan cambios. Los servidores de CI ejecutan compilaciones, pruebas y lanzamientos de software automatizados; orquestan los protocolos de control de versiones, gestionan los informes de estado y admiten complementos que pueden mejorar la funcionalidad del sistema.

Muchos servidores de CI cuentan con interfaces de usuario que ayudan a los equipos a modelar y visualizar flujos de trabajo y a construir sus pipelines de entrega continua (CD).

Los sistemas de CI animan a los desarrolladores a enviar cambios de código varias veces al día, dando prioridad a los cambios pequeños y centrados en tareas o características específicas. Las herramientas de CI permiten a los equipos iniciar revisiones de código y debatir problemas antes de fusionar el nuevo código, de modo que los errores se detectan antes en el proceso de desarrollo.

Un sistema de CI basado en Git puede, por ejemplo, iniciar solicitudes de extracción para obtener los cambios de código de una sucursal local (almacenar localmente en el ordenador de un solo desarrollador) e integrarlos en la sucursal remota actual (almacenar remotamente y compartidos por todo el equipo de desarrollo). Las solicitudes de fusión permiten a los desarrolladores integrar los cambios propuestos de una rama local con otra rama local para que el equipo los revise, debata y apruebe antes de fusionarlos con la rama remota.

Los servidores y herramientas de integración continua (incluidas las herramientas populares de código abierto, como Jenkins, CircleCI, GitHub, AWS CodePipeline y GitLab CI) monitorizan el repositorio central para detectar cambios en el código. Cuando detectan un nuevo cambio, los servidores de CI activan el proceso de compilación y ejecutan flujos de trabajo predefinidos y scripts, compilando y empaquetando el código en preparación para las pruebas y, en última instancia, la implementación.

Las herramientas de CI ejecutan una serie de pruebas para validar el código antes de que se fusione con la base de código. Las pruebas unitarias validan componentes o funciones individuales, lo que proporciona información inmediata sobre el comportamiento del código. Las pruebas de integración evalúan las interacciones entre los componentes de software y los módulos para asegurarse de que funcionan juntos correctamente y para detectar cualquier problema que las pruebas unitarias puedan pasar por alto.

En algunos flujos de trabajo de CI, las pruebas de principio a fin validan el software mediante la simulación de las interacciones del usuario para verificar que el software se comporta de manera correcta desde la perspectiva del usuario. Los equipos también pueden ejecutar pruebas de calidad del código y análisis estáticos para comprobar la capacidad de respuesta y la estabilidad de la aplicación bajo carga y para identificar infracciones de los estándares de codificación y vulnerabilidades de seguridad.

Los servidores de CI notifican a los desarrolladores de inmediato si se produce un error en una compilación o prueba. Cuando ocurre un fallo, los desarrolladores pueden priorizar la reparación del código para ayudar a garantizar que la rama principal siga siendo implementable.

Si una compilación de software tiene éxito, los servidores producen artefactos, archivos, como código compilado, imágenes Docker y bibliotecas, creados durante el proceso de compilación, que se versionan y se almacenan en repositorios para futuras pruebas e implementación. Independientemente del resultado, los principales sistemas de CI registran los intentos de integración, las tasas de éxito y otras métricas para garantizar que los miembros del equipo siempre puedan acceder a la documentación completa de la versión.

Las pruebas son un componente vital de los procesos de integración continua. Como mínimo, las pruebas constituyen alrededor de un tercio de las actividades de CI, pero eso solo es cierto cuando los equipos ejecutan una única etapa de pruebas. A menudo, las actividades de prueba constituyen la mayor parte de la carga de trabajo de las herramientas de CI. 

Las pruebas continuas en un entorno de CI comienzan cuando un desarrollador confirma un nuevo código en una base de código. Esta acción desencadena una compilación y un proceso de prueba automatizado. En muchos casos, se realizan pruebas adicionales una vez que se ha creado un artefacto de compilación (antes de que el código entre en producción). También es importante que los desarrolladores ejecuten pruebas (y subconjuntos de pruebas) en su entorno local para asegurarse de que solo confirman el código fuente en el control de versiones después de que los nuevos cambios en el código superen sus pruebas.

Esta prueba multifacética de diversas funciones, casos de uso e integraciones se denomina colectivamente "conjunto de pruebas". Este enfoque maximiza la cobertura de las pruebas, evita la regresión y sienta las bases para el éxito de la entrega continua.

El desarrollo basado en pruebas (TDD) es otro enfoque para el desarrollo de software. TDD es un enfoque en el que los desarrolladores "trabajan al revés", escribiendo una prueba antes de escribir cualquier código. En este enfoque, los desarrolladores escriben un caso de prueba a nivel de unidad que falla, antes de escribir la cantidad mínima de código para que pase. Una vez hecho esto, tanto el código de prueba como el de producción pueden refactorizarse y mejorarse.

Este enfoque ayuda a los desarrolladores a centrarse en requisitos bien definidos y evitar código extraño. También hace hincapié en el feedback continuo y puede ser una técnica exitosa para acelerar los ciclos de desarrollo.

Los pipelines de DevOps aceleran la entrega de software de alta calidad al automatizar y combinar los esfuerzos de los equipos de desarrollo y operaciones de TI, que tradicionalmente existían en sus propios silos.

Los procesos y culturas de DevOps exitosos se extienden más allá del desarrollo y las operaciones para incluir ingeniería de plataformas e infraestructuras, seguridad, cumplimiento, gobierno, gestión de riesgos, áreas de negocio, usuarios finales y clientes. En otras palabras, un buen DevOps debe incorporar las aportaciones de todos los stakeholders en la aplicación al ciclo de vida de desarrollo del software.

En un marco de DevOps, la integración continua se sitúa al principio del proceso de desarrollo de software y la canalización de CI/CD. La CI permite a los desarrolladores comprobar con frecuencia su código para evitar que las copias locales se alejen demasiado de la rama principal de la compilación del código. Este enfoque ayuda a los equipos a evitar conflictos de fusión que podrían "romper" la compilación en las fases de entrega e implementación.

La CI también permite a los desarrolladores enviar actualizaciones pequeñas y frecuentes que promueven bucles de comentarios rápidos y coherentes y una mejora continua basada en la priorización de las necesidades de los clientes, principios clave de la filosofía DevOps.

La integración continua es la primera parada en el pipeline de CI/CD y, por lo general, va seguida de procesos de entrega e implementación continuas. La integración continua se refiere a las frecuentes fusiones de código y las compilaciones y pruebas unitarias que siguen.

La entrega continua (CD) recoge el testigo donde lo deja la Integración continua, automatizando la entrega de cambios validados en la base de código (incluidas actualizaciones, correcciones y incluso nuevas características) en entornos o repositorios de código seleccionados. Los equipos de DevOps reciben notificaciones sobre la última compilación y pueden mover manualmente las actualizaciones a un entorno de producción en vivo. El objetivo de la etapa de pipeline de entrega es implementar código nuevo con el mínimo esfuerzo, pero permitiendo un cierto nivel de supervisión humana antes de que el código se ponga en marcha.

La implementación continua libera automáticamente los cambios de código a los usuarios finales después de pasar una serie de pruebas predefinidas, como las pruebas de integración que prueban el código en un entorno de imitación para ayudar a garantizar la integridad del código. Tanto la entrega continua como la implementación continua se ocupan de la automatización más adelante que la CI y, a menudo, se usan indistintamente.

La diferencia entre la entrega continua y la implementación continua es en el nivel de automatización utilizada en los lanzamientos de software o aplicación. En la entrega continua, el código se mueve automáticamente a entornos similares a los de producción para realizar más pruebas y garantizar la calidad, como la evaluación de riesgos y la identificación de vulnerabilidades del código fuente. Se requiere intervención humana para pasar a la producción después de las pruebas exitosas.

En la implementación continua, la automatización va más allá. Una vez que el código pasa las pruebas, la implementación en producción se realiza automáticamente; la aprobación humana no es necesaria¹.

El desarrollo ágil es un enfoque iterativo de la ingeniería de software que prioriza la flexibilidad, la colaboración, la mejora continua y la rápida adaptación al cambio. Es una práctica que organiza el desarrollo en grupos de trabajo más pequeños, o "sprints", para agilizar la colaboración entre desarrolladores y stakeholders y acelerar la entrega de software.

Del mismo modo, la CI requiere actualizaciones de código frecuentes e incrementales y una validación continua del código. Se trata de un enfoque iterativo del desarrollo que permite a los desarrolladores actualizar y escalar rápidamente las soluciones de software a lo largo del tiempo y ofrecer productos de alta calidad a los usuarios con mayor rapidez. Como tal, la integración continua es una práctica inherentemente ágil. 

La integración continua ayuda a los equipos de desarrollo a iterar más rápido y entregar un mejor software a los usuarios, pero hay pasos adicionales que una empresa puede tomar para optimizar el proceso. Entre las prácticas de CI aplicadas habitualmente se incluyen:

Las prácticas de integración continua, y, en términos más generales, los marcos DevOps, ayudan a las empresas a optimizar la colaboración y la integración de código, y a mantener pipelines de entrega continua. Estas prácticas mejoran la calidad del software y aceleran los procesos de lanzamiento de software. Las herramientas modernas de CI incorporan una gama de tecnologías emergentes que fortalecen estas prácticas y mejoran su valor.

Por ejemplo, el uso de la inteligencia artificial (IA) y el machine learning (ML) en los procesos de integración continua se está convirtiendo en una práctica de desarrollo estándar. Las herramientas habilitadas por IA pueden ayudar a los desarrolladores a crear sistemas de autorreparación que identifiquen y corrijan de forma automática y autónoma el código problemático antes de que afecte al flujo principal de desarrollo. Los sistemas de CI basados en ML también pueden autogenerar casos de prueba a medida en función de los envíos de código y las modificaciones, de modo que los desarrolladores dedican menos tiempo a crear manualmente pruebas de código.

Con las ciberamenazas cada vez más sofisticadas², los desarrolladores incorporan cada vez más prácticas de seguridad directamente en el proceso de desarrollo de software. Estas estrategias de seguridad de "desplazamiento a la izquierda" introducen comprobaciones de seguridad en las primeras fases de desarrollo, incluidos los procesos de CI, para ayudar a garantizar que las vulnerabilidades se detecten durante la codificación y no después de la implementación.

Hoy en día, Kubernetes y el ecosistema más amplio de tecnologías relacionadas con contenedores forman los componentes básicos de los entornos de TI modernos. DevSecOps integra la seguridad en cada fase de DevOps para abordar los desafíos de seguridad que acompañan a estos ecosistemas dinámicos.

Los contenedores son unidades ejecutables de software que empaquetan el código de la aplicación junto con sus bibliotecas y dependencias para que el código pueda ejecutarse en cualquier entorno informático. Y Kubernetes, también conocido como k8s o kube, es una plataforma de orquestación de contenedores de código abierto para programar y automatizar la implementación, la gestión y el escalado de aplicaciones en contenedores.

Tradicionalmente, los equipos de DevOps dependían de un equipo de seguridad independiente para identificar vulnerabilidades y luego usaban los comentarios para implementar cambios de código en la siguiente ronda de actualizaciones de aplicaciones. Ahora, se espera que los desarrolladores protejan los contenedores y los clústeres de Kubernetes y apliquen los principios zero trust en todas sus aplicaciones de software y en el proceso de desarrollo, lo que refleja un nuevo paradigma operativo³. La adopción de las prácticas de DevSecOps significa que la codificación y el desarrollo de software ya no se tratan solo de crear características, sino también de anticipar riesgos.

La computación sin servidor y las arquitecturas nativas de la nube también son una prioridad para los equipos de DevOps actuales.

La computación sin servidor es un modelo de desarrollo y ejecución de aplicaciones que permite a los desarrolladores crear y ejecutar código de aplicación sin aprovisionar ni gestionar servidores ni infraestructura de backend. Los servidores en una configuración sin servidor existen, pero están gestionados en su totalidad por un proveedor de servicio cloud (CSP). En los pipelines de CI, las plataformas sin servidor liberan a los desarrolladores de las preocupaciones de la infraestructura backend, para que puedan centrarse en la codificación front-end y la lógica empresarial.

Con la proliferación de la computación sin servidor y las aplicaciones de IA, las arquitecturas basadas en eventos (EDA) desempeñan un papel central para ayudar a los equipos a abordar la creciente complejidad del cloud computing. Las EDA admiten la comunicación en tiempo real entre sistemas front-end y backend débilmente acoplados, lo que permite que los sistemas funcionen de forma independiente y procesen eventos (cualquier cambio o acción que se produzca dentro de un sistema) de forma asíncrona.

En los pipelines de CI, eso significa que los desarrolladores pueden escalar componentes individuales de la aplicación sin afectar a toda la aplicación, lo que ayuda a los equipos a crear bases de código y procesos de integración más ágiles, con capacidad de respuesta y escalables.

La configuración de un pipeline de CI sólido requiere una planificación y configuración cuidadosas, incluida la elección de las herramientas adecuadas, la definición de flujos de trabajo de compilación y prueba y la configuración de la infraestructura. Los pipelines de CI también requieren un mantenimiento regular para adaptarse a los cambios en la base de código, las dependencias (como las API) y la infraestructura.

Sin embargo, la implementación de CI puede ofrecer a los equipos de desarrollo de software una serie de beneficios, entre ellos:

Los procesos de CI permiten que los equipos aborden los errores con prontitud, a veces en cuestión de minutos tras el envío del código.

Todos los miembros del equipo pueden cambiar el código, fusionar los cambios de código e identificar las incompatibilidades y los errores de integración del código, lo que simplifica el intercambio de conocimientos y mejora la calidad del código y el software gracias a los comentarios de los compañeros.

Debido a que el nuevo código se integra de forman continua, los equipos dedican menos tiempo a integrar y probar grandes lotes de código. Y el bucle acelerado de comentarios que ofrecen las herramientas de CI ayuda a los desarrolladores a iterar y entregar actualizaciones de software y nuevos productos a los usuarios finales con mayor rapidez.

Las confirmaciones frecuentes de código implican cambios más pequeños y graduales que son más fáciles de entender, revisar y probar. Esto reduce el riesgo de introducir problemas importantes en la base de código durante el desarrollo.