Cada cambio, probado solo
Un pipeline compila, prueba y entrega cada cambio sin que nadie lo haga a mano. Al terminar sabrás qué automatiza la integración continua, en qué se diferencian la entrega y el despliegue continuos, y cómo una prueba en rojo frena un cambio malo.
Integración continua
Cuando cada persona trabaja semanas en su rama y todo se junta al final, aparecen conflictos enormes y errores que nadie sabe de dónde salieron. La integración continua (CI, continuous integration) es la práctica contraria: integrar cambios pequeños a la rama principal varias veces por semana o por día, y que cada integración se compruebe automáticamente: se descarga el código en una máquina limpia, se instalan las dependencias, se compila y se corren las pruebas.
Esa secuencia automática se llama pipeline, y la ejecuta un servidor de CI (GitHub Actions, GitLab CI, Jenkins…) cada vez que alguien sube código o abre un pull request. Si algo falla, el pipeline queda en rojo y avisa en minutos, cuando el cambio todavía está fresco en la cabeza de quien lo hizo. La regla de oro: si main está en rojo, arreglarlo es lo primero.
Los pasos se ordenan para fallar pronto: primero lo rápido y barato (revisar el estilo, compilar), después las pruebas unitarias, y al final lo lento (pruebas de integración, construir la imagen).
Elige dónde falla el cambio y mira hasta dónde llega el pipeline.
Entrega continua y despliegue continuo
Las dos se abrevian CD y se confunden a menudo:
- Entrega continua (continuous delivery): todo cambio que pasa el pipeline queda listo para producción y se despliega automáticamente a un ambiente de pruebas (staging). El paso final a producción es una decisión humana, de un clic.
- Despliegue continuo (continuous deployment): no hay clic. Lo que pasa todas las pruebas llega solo a producción. Exige mucha confianza en las pruebas y poder volver atrás rápido.
En los dos casos rige una idea: construir una sola vez y promover el mismo artefacto. La imagen que se probó en staging es exactamente la que va a producción; no se vuelve a compilar para cada ambiente, porque entonces lo que llega a producción no es lo que se probó.
Compara las tres prácticas: ¿qué se automatiza y dónde decide una persona?
Un pipeline en GitHub Actions
En GitHub Actions, un pipeline es un archivo YAML dentro de .github/workflows/ del propio repositorio, así que viaja con el código y se revisa en los pull requests como cualquier otro cambio:
name: CI
on: # cuándo se ejecuta
push:
branches: [main]
pull_request:
branches: [main]
jobs:
test: # un job: corre en su propia máquina
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4 # trae el código (la máquina empieza vacía)
- uses: actions/setup-node@v4
with:
node-version: 20
- run: npm ci # instala exactamente lo del package-lock.json
- run: npm test
Para que el pipeline sirva de freno, la rama main se protege exigiendo que el job test pase en el pull request: con las pruebas en rojo, el botón de integrar queda bloqueado.
El mismo cambio llega a staging y a producción de dos formas. ¿Qué se probó realmente?
Antes de leer la respuesta
Tu turno: el primer pipeline de la tienda
Clonaste tienda, una pequeña aplicación de Node que calcula el total de una compra con el IVA del 12 %. Tiene pruebas (npm test), pero nadie las corre, y una de ellas falla. La rama main está protegida: exige que pase el job test. El equipo ya guardó en GitHub el secreto DEPLOY_TOKEN para desplegar a staging. Arma el pipeline, deja que encuentre el error, corrígelo e integra hasta ver el cambio desplegado.
Comprueba lo que entendiste
Cada respuesta incorrecta explica por qué parece correcta y en qué falla.