Integración Continua

Teoría

Los artefactos de software

En un proyecto de desarrollo se producen muchos archivos: código, configuraciones, scripts, datos de prueba. Todos estos artefactos los crean y modifican distintas personas a lo largo del tiempo —meses durante el desarrollo inicial, y potencialmente años durante la vida útil del producto—. Administrarlos bien es importante: la alternativa es perder información, perder tiempo rehaciendo cosas que no se encuentran, y afectar la calidad de lo que se construye.

Una vez decidida la arquitectura, debe haber un mapeo claro entre sus conceptos y los artefactos concretos: carpetas, archivos, esquemas de nombramiento. Por ejemplo, para el recurso Editorial del modelo del proyecto Book que usamos en las páginas de Backend, un mismo concepto se transforma en varios artefactos:

Clase	Ubicación
EditorialDTO	co.edu.uniandes.dsw.books.dtos.EditorialDTO
EditorialDetailDTO	co.edu.uniandes.dsw.books.dtos.EditorialDetailDTO
EditorialEntity	co.edu.uniandes.dsw.books.entities.EditorialEntity
EditorialRepository	co.edu.uniandes.dsw.books.repositories.EditorialRepository
EditorialService	co.edu.uniandes.dsw.books.services.EditorialService
EditorialController	co.edu.uniandes.dsw.books.controllers.EditorialController
EditorialServiceTest	co.edu.uniandes.dsw.books.services.EditorialServiceTest

Con un modelo conceptual de apenas 10 clases y algunas asociaciones entre ellas, fácilmente se llega a más de 100 artefactos distintos que hay que mantener organizados, solo en el backend.

El problema de la integración

Cuando varios desarrolladores trabajan en el mismo proyecto, hay que dividirse el trabajo —por capas, por conceptos, por historias de usuario— y luego integrar lo que cada quien hizo. Una estrategia posible es esperar a que todos terminen su parte y dedicar una fase aparte, al final, solo para integrar. Suena práctica, pero trae varios problemas:

1. Se descubren tarde los malentendidos sobre los requerimientos o el diseño: “las piezas no encajan”.
2. Corregir defectos en esta etapa —sobre problemas que se introdujeron mucho antes— es más costoso y puede generar problemas nuevos.
3. La calidad del software es difícil de asegurar.
4. Las pruebas de integración llegan muy tarde en el desarrollo para ser útiles.

A este escenario se lo conoce como Integration Hell, y su consecuencia directa es retrasar las entregas porque hay que rehacer trabajo, comprometiendo la calidad.

La alternativa —hoy parte de casi cualquier metodología de desarrollo— es la Integración Continua: en vez de integrar al final, se integra de forma constante, a medida que avanza el trabajo de cada persona. La práctica nació con Extreme Programming (XP) y fue descrita por primera vez por Martin Fowler en su artículo Continuous Integration.

Las prácticas de la Integración Continua

Según Fowler, estas son las prácticas que hacen posible la Integración Continua:

1. Usar un repositorio central para el código de todo el proyecto.
2. Automatizar la construcción del ejecutable (el build).
3. Ejecutar las pruebas automáticamente.
4. Cada integrante hace commit/push todos los días.
5. Cada commit dispara un build y una corrida de pruebas nuevos.
6. Probar en un clon del ambiente de producción.
7. Facilitar que cualquiera obtenga los últimos entregables.
8. Que todos puedan ver el resultado del último build.
9. Automatizar el despliegue.

Profundicemos en tres de ellas: el repositorio central, el manejo de dependencias, y la automatización del build.

Nota

La práctica 3, ejecutar las pruebas automáticamente, no se profundiza acá porque la vas a trabajar a lo largo de todo el curso: cada capa tiene su propio material y su propia forma de probarse — el backend, el frontend y el API REST. Consulta el material complementario correspondiente según lo que estés probando, por ejemplo Pruebas de lógica de negocio y Pruebas de API con Postman.

1. Un repositorio central para el código

Cada desarrollador trabaja con su propia copia local del repositorio: clona el repositorio central, hace sus commits localmente, y cuando su trabajo está listo, hace push para que los demás lo integren con un pull. Ya viste este flujo —commits, ramas, Pull Requests— con detalle en el taller de Git; la Integración Continua se construye directamente sobre él.

Lo que agrega la Integración Continua es la frecuencia: mientras más rápido y seguido se integra el trabajo de todos al repositorio central, más rápido aparece un conflicto o un error de integración, y más barato es corregirlo.

2. El manejo de dependencias

Todo proyecto depende de librerías de terceros —y no de cualquier versión, sino de una versión específica—. Hay que asegurar que todos los desarrolladores usen exactamente las mismas.

Sin importar el lenguaje, las herramientas de manejo de dependencias comparten dos ideas:

• Existe un repositorio de librerías, distinto al del código fuente del proyecto: puede ser un repositorio público de acceso universal, o uno propio de la organización.
• Cada proyecto declara, en un archivo, cuáles librerías necesita y en qué versión.

En nuestro backend en Spring Boot usamos Maven, que declara las dependencias en pom.xml:

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>

En el frontend en Angular usamos npm, que las declara en package.json:

"dependencies": {
  "@angular/core": "^18.0.0"
}

En ambos casos, cualquiera que clone el repositorio y corra mvn install o npm install termina con exactamente las mismas versiones que todos los demás.

3. Automatizar la construcción del ejecutable

Sin un proceso de build automatizado y repetible, cada desarrollador puede terminar haciendo las cosas un poco distinto, y aparecen inconsistencias: se usan versiones de librerías que no son, no queda claro qué fuentes se empaquetaron, no se corrieron las pruebas sobre lo que se empaquetó, el servidor de destino no quedó bien configurado.

Automatizar el build significa que un solo comando —no una serie de pasos manuales— resuelve las dependencias, compila las fuentes, empaqueta la aplicación y corre las pruebas. Con Maven, ese comando es mvn clean test; con npm, npm run build y npm test. Esto ya lo puede correr cualquier desarrollador en su máquina local; lo que falta es que ocurra automáticamente, para todos, cada vez que alguien integra.

Herramientas de Integración Continua

Repositorio central, dependencias declaradas y build automatizado son los ingredientes. Lo que falta es una herramienta que los conecte: que detecte automáticamente cada push al repositorio central y, sin intervención manual, dispare el build y las pruebas — y que le avise a todo el equipo si algo se rompió.

flowchart LR
    A["git push"] --> B["La herramienta de CI<br/>detecta el push"]
    B --> C["Descarga dependencias<br/>(mvn / npm install)"]
    C --> D["Compila y empaqueta"]
    D --> E["Corre las pruebas"]
    E -->|"Todo pasa"| F["✅ Reporta éxito"]
    E -->|"Algo falla"| G["❌ Reporta el error"]
    F --> H["(Opcional)<br/>Despliega"]

Dos herramientas cubren este rol en el curso:

GitHub Actions

Corre dentro del propio GitHub: se configura con un archivo .yml dentro de .github/workflows/ en el repositorio, y no necesita infraestructura propia — GitHub la ejecuta por ti. Es la opción más simple cuando el código ya vive en GitHub.

Jenkins

Es un servidor de CI aparte, que hay que instalar y mantener (propio o en la nube), configurado con un Jenkinsfile. A cambio de ese costo de infraestructura, es independiente de dónde viva el repositorio y muy configurable para pipelines complejos.

GitHub Actions

Este mismo sitio de recursos usa GitHub Actions para correr sus pruebas en cada Pull Request. Así se ve su configuración real, en .github/workflows/test.yml:

name: Tests

on:
  pull_request:
  push:
    branches: [main]

jobs:
  e2e:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - name: Instalar dependencias
        run: pnpm install --frozen-lockfile
      - name: Correr las pruebas
        run: pnpm test

Para un backend en Maven, el equivalente es igual de corto:

name: CI Backend

on:
  push:
  pull_request:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Configurar Java
        uses: actions/setup-java@v4
        with:
          distribution: "temurin"
          java-version: "21"
      - name: Compilar y correr pruebas
        run: mvn -B test

on define qué evento dispara el workflow —en ambos casos, cada push y cada Pull Request—, y steps es, en esencia, el mismo pipeline que correrías a mano: descargar dependencias, compilar, probar.

Jenkins

Un Jenkinsfile describe el mismo tipo de pipeline, pero lo ejecuta el propio servidor de Jenkins en vez de GitHub:

pipeline {
  agent any
  stages {
    stage('Checkout') {
      steps { checkout scm }
    }
    stage('Build y pruebas') {
      steps { sh 'mvn clean test' }
    }
    stage('Empaquetar') {
      steps { sh 'mvn package' }
    }
    stage('Desplegar') {
      steps { sh './deploy.sh' }
    }
  }
}

Jenkins necesita que alguien instale y mantenga el servidor (propio, o en un proveedor en la nube), y que el repositorio le avise —por webhook— cuando hay un push nuevo. A cambio, es una herramienta independiente de GitHub: sirve igual si el código vive en GitLab, Bitbucket o un servidor propio.

Consejo

Muchos pipelines —con cualquiera de las dos herramientas— agregan un paso de análisis estático con una herramienta como SonarQube, que mide métricas de calidad del código (duplicación, complejidad, cobertura de pruebas) en cada build.

Autoevaluación

1. ¿Qué es un 'artefacto de software' en el contexto de un proyecto?

Solo el código fuente compiladoCualquier archivo que el equipo produce y versiona: código, configuración, scripts, datos de pruebaÚnicamente los archivos de configuración del servidor

2. ¿Por qué la estrategia de 'integrar todo al final' suele terminar en 'Integration Hell'?

Porque Git no permite integrar cambios de más de una personaPorque los problemas de entendimiento y los defectos se descubren tarde, cuando ya son más costosos de corregirPorque las pruebas automáticas no existen

3. ¿Qué dos cosas comparten todas las herramientas de manejo de dependencias (Maven, npm, etc.)?

Un repositorio de librerías distinto al del código fuente, y un archivo donde el proyecto declara qué necesitaQue solo funcionan con proyectos escritos en JavaQue no permiten fijar una versión específica de una librería

4. ¿Cuál es la diferencia clave entre GitHub Actions y Jenkins?

GitHub Actions corre dentro de GitHub sin infraestructura propia; Jenkins requiere instalar y mantener su propio servidorJenkins solo sirve para proyectos en Java; GitHub Actions solo para JavaScriptNo hay ninguna diferencia real entre las dos

5. En un pipeline de CI disparado por un push, ¿qué ocurre si las pruebas fallan?

El pipeline reporta el error y el equipo se entera de inmediatoEl código se despliega a producción de todas formasEl push se deshace automáticamente en el repositorio

Comprobar