¿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 constante, detectar y arreglar errores antes de que afecten el rendimiento del software y ofrecer software de mayor calidad en cronogramas 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 compilación”.

Se ejecutan pruebas automatizadas para validar esta compilación antes de que se produzca un "artefacto de compilación", el archivo resultante que se pasa para realizar más pruebas o a un entorno de producción. La siguiente parte del proceso se denomina entrega continua.

CI se creó como una solución a los desafíos asociados con el desarrollo de software tradicional, a saber, sus procesos de integración y despliegue. 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.

Los diferentes fragmentos de código no siempre funcionaban bien juntos, y los desarrolladores integraban sus cambios en diferentes plazos (a veces en el último minuto), por lo que la retroalimentación sobre los problemas de integración a menudo se retrasaba. Cuando surgían problemas, los retrasos en la retroalimentación hacían más difícil para los equipos averiguar qué cambio introdujo el problema y convertían la depuración en un proceso más arduo.

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

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

Con un sistema de CI, el nuevo código se agrega a un repositorio central (normalmente, varias veces al día), donde permanece para la creación y pruebas. 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.

Si bien 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 emplea ciertos componentes y procesos para optimizar las tareas de integración de código.

CI comienza con un repositorio central compartido donde todos los desarrolladores envían 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, a menudo gestionan estos repositorios. Cuando los desarrolladores envían cambios, el repositorio central les hace un seguimiento, creando un historial completo de los cambios de código que los equipos de desarrollo pueden usar para colaborar de manera más eficiente.

Los repositorios también emplean 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ísticas (para aislar características específicas de la aplicación) y ramas de corta duración para separar su trabajo antes de fusionarlo nuevamente en la rama de código principal.

Gitflow, por ejemplo, es un modelo de ramificación basado en Git que asigna roles (como “principal”, “característica”, “desarrollo” y “lanzamiento”) a diferentes ramas para controlar 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 administran todas las operaciones de CI. Sirven como el centro de automatización del proceso de CI. Los servidores de CI monitorean los repositorios en busca de cambios de código e inician pipelines de CI predefinidas cuando se detectan cambios. Los servidores de CI ejecutan compilaciones, pruebas y versiones de software automatizadas; orquestan protocolos de control de versiones; manejan 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 construir sus pipelines de entrega continua (CD).

Los sistemas de CI incentivan a los desarrolladores a enviar cambios de código varias veces al día, priorizando cambios pequeños y enfocados en tareas o características específicas. Las herramientas de CI permiten a los equipos iniciar comentarios y debatir problemas antes de fusionar código nuevo para que los errores se detecten antes en el proceso de desarrollo.

Un sistema de CI basado en Git puede, por ejemplo, iniciar solicitudes de extracción para obtener cambios de código de una rama local (almacenado localmente en la computadora de un solo desarrollador) e integrarlos en la rama remota actual (almacenado de forma remota y compartido por todo el equipo de desarrollo). Y 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 debata y apruebe y haga comentarios 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) supervisan el repositorio central para detectar cambios en el código. Cuando detectan un nuevo cambio, los servidores de CI activan el proceso de creación y ejecutan flujos de trabajo predefinidos y textos de creación, compilando y empaquetando el código en preparación para las pruebas y, en última instancia, el despliegue.

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

En algunos flujos de trabajo de CI, las pruebas de extremo a extremo validan el software simulando interacciones del usuario para verificar que el software se comporta correctamente desde la perspectiva del usuario. Los equipos también pueden ejecutar pruebas de calidad de código y análisis estáticos para verificar la capacidad de respuesta y la estabilidad de la aplicación bajo carga e identificar violaciones de estándares de codificación y vulnerabilidades de seguridad.

Los servidores de CI notifican a los desarrolladores de inmediato si falla una compilación o prueba. Cuando hay una falla, los desarrolladores pueden priorizar la reparación del código para ayudar a garantizar que la rama principal siga siendo desplegable.

Si una compilación de software se realiza correctamente, los servidores producen artefactos (archivos, como código compilado, imágenes de Docker y bibliotecas, creados durante el proceso de compilación) que se versionan y almacenan en repositorios para futuras pruebas y despliegues. 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 sola etapa de prueba. 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 creó 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 ayudar a garantizar que solo confirmen el código fuente en el control de versiones después de que los nuevos cambios de código pasen sus pruebas.

Esta prueba multifacética de varias funciones, casos de uso e integraciones se denomina colectivamente suite de prueba. Este enfoque maximiza la cobertura de las pruebas, evita la regresión y sienta las bases para una entrega continua exitosa.

El desarrollo basado en pruebas (TDD) es otro enfoque para el desarrollo de software. El 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 se pueden refactorizar y mejorar.

Este enfoque ayuda a los desarrolladores a centrarse en requisitos bien definidos y evitar código extraño. También enfatiza la retroalimentación continua y puede ser una técnica exitosa para acelerar los ciclos de desarrollo.

Los procesos 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 su propio silo.

Los procesos y las culturas de DevOps exitosos se extienden más allá del desarrollo y las operaciones para incluir la ingeniería de plataforma e infraestructura, la seguridad, el cumplimiento, la gobernanza, la gestión de riesgos, la línea de negocio, los usuarios finales y los clientes. En otras palabras, un buen DevOps debe incorporar las entradas de todos los stakeholders de la aplicación en el ciclo de vida del desarrollo de software.

En un marco de DevOps, la integración continua se encuentra al comienzo del proceso de desarrollo de software y el pipeline de CI/CD. 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 y despliegue.

CI también permite a los desarrolladores enviar actualizaciones pequeñas y frecuentes que promueven ciclos de retroalimentación rápidos y constantes y una mejora continua basada en la priorización de las necesidades del cliente, principios clave de la filosofía DevOps.

La integración continua es la primera parada en el proceso de CI/CD y generalmente le siguen procesos de entrega continua y despliegue continuo. 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) sigue donde lo hace la integración continua, automatizando la entrega de cambios validados en la base de código (incluidas actualizaciones, arreglos y característica) 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 fase del pipeline de entrega es desplegar código nuevo con el mínimo esfuerzo, pero permitiendo un cierto nivel de supervisión humana antes de que el código entre en funcionamiento.

El despliegue continuo libera automáticamente los cambios de código para los usuarios finales luego de pasar una serie de pruebas predefinidas, como pruebas de integración que analizan el código en un entorno de copia para ayudar a garantizar la integridad del código. Tanto la entrega continua como el despliegue continuo se ocupan de la automatización más adelante en el pipeline que la CI y, a menudo, se usan indistintamente.

La diferencia entre la entrega continua y el despliegue continuo está en el nivel de automatización utilizado en los lanzamientos de software o aplicaciones. En la entrega continua, el código se traslada 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 el despliegue continuo, la automatización va más allá. Una vez que el código pasa las pruebas, el despliegue a producción ocurre 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.

De manera similar, la CI requiere actualizaciones de código frecuentes e incrementales y una validación de código continua. Es un enfoque iterativo para el desarrollo que permite a los desarrolladores actualizar y escalar rápidamente las soluciones de software a lo largo del tiempo y entregar productos de alta calidad a los usuarios más rápido. 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 ofrecer un mejor software a los usuarios, pero hay medidas adicionales que una empresa puede tomar para optimizar el proceso. Las prácticas de CI comúnmente implementadas incluyen:

Las prácticas de integración continua, y las infraestructuras de DevOps en general, ayudan a las empresas a optimizar la colaboración y la integración de código y a mantener pipelines de entrega. 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 inteligencia artificial (IA) y machine learning (ML) en procesos de integración continua se está convirtiendo en una práctica de desarrollo estándar. Las herramientas habilitadas para IA pueden ayudar a los desarrolladores a crear sistemas de autocorrección que identifiquen y corrijan de manera automática y autónoma el código problemático antes de que afecte el flujo de desarrollo principal. Los sistemas de CI impulsados por ML también pueden generar automáticamente casos de prueba personalizados basados en envíos y modificaciones de código, por lo que los desarrolladores pasan menos tiempo creando manualmente pruebas de código.

Con las ciberamenazas cada vez más sofisticadas,² los desarrolladores están incorporando 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 controles de seguridad en las primeras fases de desarrollo, incluidos los procesos de CI, para ayudar a garantizar que las vulnerabilidades se detecten durante la programación en lugar de después del despliegue.

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 ecosistemas tan 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 el despliegue, la gestión y el escalado de aplicaciones en contenedores.

Tradicionalmente, los equipos de DevOps confiaban en un equipo de seguridad independiente para identificar vulnerabilidades y luego utilizaban el feedback para implementar cambios de código en la siguiente ronda de actualizaciones de aplicación. Ahora, se espera que los desarrolladores protejan los contenedores y los clústeres de Kubernetes y apliquen principios de confianza cero en todas sus aplicaciones de software y en el proceso de desarrollo, lo que refleja un nuevo paradigma operativo^.3 La adopción de prácticas de DevSecOps significa que la programació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 de hoy en día.

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 o infraestructura de backend. Los servidores en una configuración sin servidor existen, pero son gestionados completamente por un proveedor de servicios en la nube (CSP). En los pipelines de CI, las plataformas sin servidor liberan a los desarrolladores de las preocupaciones de la infraestructura de backend, para que puedan centrarse en la programación frontend 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 de la computación en la nube. Los EDA admiten la comunicación en tiempo real entre sistemas frontend y backend poco acoplados, lo que permite que los sistemas funcionen de forma independiente y procesen eventos (cualquier cambio o acción que ocurra dentro de un sistema) de forma asíncrona.

En los pipelines de CI, eso significa que los desarrolladores pueden escalar componentes individuales de 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, receptivos y escalables.

Configurar 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 procesos 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, implementar CI puede ofrecer a los equipos de desarrollo de software una serie de beneficios, que incluyen:

Los procesos de CI permiten a los equipos abordar 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 del código y los errores de integración, lo que simplifica el intercambio de conocimientos y mejora la calidad del código y del software a través de la retroalimentación de los compañeros.

Debido a que el código nuevo se integra continuamente, los equipos pasan menos tiempo integrando y probando grandes lotes de código. Y el ciclo de retroalimentación acelerado que ofrecen las herramientas CI ayuda a los desarrolladores a iterar y entregar actualizaciones de software y nuevos productos a los usuarios finales más rápidamente.

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