Integración continua (CI)

La integración continua (CI, continuous integration) significa que los desarrolladores integran cambios pequeños en la rama principal con frecuencia, y un servidor compila el código y ejecuta las pruebas automatizadas en cada push o pull request. El objetivo es el feedback rápido: si un cambio rompe algo, su autor se entera mientras el cambio aún está fresco, no días después durante un merge enorme.

Ejemplo (GitHub Actions)

Un pipeline mínimo que ejecuta la suite de pruebas en cada pull request y en cada push a main:

name: CI
on:
  pull_request:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm test

Si npm test termina con un código distinto de cero, el job falla y la pull request muestra un check rojo. Combinado con una protección de rama que exija este check, el código roto no se puede integrar.

De qué se encarga un tester en CI

• Qué pruebas se ejecutan y dónde. Pruebas unitarias y de API rápidas en cada pull request; suites end-to-end más lentas al hacer merge o de forma programada. Un pipeline de pull request que tarda 40 minutos deja de usarse.
• Calidad de la señal. Un test flaky en un job bloqueante acostumbra a la gente a pulsar “re-run”. Pon en cuarentena los tests inestables para que un build rojo siempre signifique algo.
• Artefactos. Publica informes, traces y capturas de pantalla de las ejecuciones fallidas para que nadie tenga que reproducir un fallo en local solo para verlo.
• Paralelismo. Repartir (sharding) una suite larga entre varias máquinas mantiene estable el tiempo de feedback a medida que la suite crece.

En qué se diferencia de CD

La entrega continua (continuous delivery) amplía la CI: cada build que pasa se empaqueta y queda lista para publicarse, normalmente pasando por entornos de staging. El despliegue continuo (continuous deployment) va un paso más allá y publica en producción automáticamente cada cambio que pasa. La CI es la base de ambos; sin una suite de pruebas fiable en cada commit, ninguno de los dos es seguro.

Errores comunes

Ejecutar la CI solo por la noche, dejar la rama principal en rojo durante días y tratar el pipeline como el lugar donde se escriben las pruebas en vez de donde se ejecutan. La CI es tanto un hábito de equipo como una herramienta: merges pequeños, y arreglar o revertir cuando se rompe el build.