Antes de que existiera CI/CD como práctica estándar, desplegar era un ritual: alguien se conectaba por SSH al servidor un viernes por la tarde (nunca falla que sea un viernes), copiaba archivos a mano, cruzaba los dedos y esperaba que nada se rompiera. Si algo fallaba, tocaba deshacerlo también a mano, bajo presión, con gente esperando. CI/CD es la respuesta a ese ritual: convertir el despliegue en un proceso automático, repetible y aburrido — aburrido es bueno cuando hablamos de poner código en producción.
Qué significan realmente las siglas
CI/CD junta dos prácticas relacionadas pero distintas:
- CI (Integración Continua): cada vez que alguien sube cambios al repositorio, se ejecutan automáticamente pruebas y comprobaciones. El objetivo es detectar errores en minutos, no días después cuando ya es difícil recordar qué cambio los causó.
- CD (Entrega o Despliegue Continuo): si el código pasa todas las comprobaciones, se prepara automáticamente para publicarse (entrega continua) o se publica directamente en producción sin intervención humana (despliegue continuo). La diferencia entre ambas es si hay o no un botón manual antes del paso final a producción.
Juntas forman un pipeline: una secuencia de pasos automáticos que llevan el código desde que alguien hace git push hasta que esos cambios están funcionando de verdad, sin que nadie tenga que copiar archivos a mano.
Por qué importa aunque trabajes solo
CI/CD suele presentarse como algo de "equipos grandes", pero un proyecto personal se beneficia igual. Automatizar el despliegue elimina la fricción de publicar cambios pequeños con frecuencia (en vez de acumular semanas de trabajo en un único despliegue arriesgado), y las pruebas automáticas en cada cambio actúan como una red de seguridad que detecta errores antes de que lleguen a un usuario real. Si ya usas Git y GitHub para versionar tu código, montar un pipeline básico es más sencillo de lo que parece: la mayoría de plataformas lo integran directamente sobre el mismo repositorio.
Las etapas de un pipeline típico
Aunque cada proyecto ajusta los detalles, casi todos los pipelines de CI/CD siguen la misma secuencia lógica. Cada etapa despliega el ejemplo de configuración correspondiente en GitHub Actions, la herramienta de CI/CD integrada directamente en GitHub.
El pipeline arranca en un entorno limpio (una máquina virtual desechable), así que el primer paso siempre es instalar exactamente las mismas dependencias que usas en local, a partir del archivo de bloqueo (package-lock.json, poetry.lock...) para garantizar versiones idénticas.
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
- run: npm ciCon las dependencias instaladas, se lanza la suite de tests automáticos. Si algún test falla, el pipeline se detiene aquí y nadie más avanza en el proceso — es exactamente el punto en el que quieres enterarte de un fallo, no tres pasos después con el código ya en producción. Esto es lo que hace que invertir en tests con Jest compense tanto: cada test que escribes se convierte en una comprobación automática permanente.
- run: npm test -- --ci
- run: npm run lintCon los tests en verde, se genera la versión optimizada de la aplicación: el bundle de producción de un frontend, la compilación de TypeScript a JavaScript, o la imagen de Docker que empaquetará la app junto con todo lo necesario para ejecutarla igual en cualquier entorno.
- run: npm run build
- uses: actions/upload-artifact@v4
with:
name: build-output
path: dist/Si todo lo anterior pasó, el pipeline publica el resultado en el entorno correspondiente. Es habitual condicionar este paso a la rama main, de forma que solo el código ya revisado y fusionado llegue a producción de forma automática; otras ramas pueden desplegarse a un entorno de pruebas aparte.
deploy:
needs: build
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
steps:
- uses: actions/download-artifact@v4
with:
name: build-output
- run: npm run deployEntrega continua vs despliegue continuo, en la práctica
La diferencia entre CI y "solo CD" a veces se difumina, pero entre entrega y despliegue continuo es concreta y práctica: en entrega continua, el pipeline deja el cambio listo para publicarse y una persona aprieta un botón para confirmarlo (útil cuando el negocio necesita controlar el momento exacto del lanzamiento). En despliegue continuo, ese último paso también es automático — si pasa los tests, se publica sin que nadie lo apruebe manualmente. La mayoría de equipos empiezan con entrega continua y avanzan a despliegue continuo cuando confían lo suficiente en su cobertura de tests.
| Aspecto | Entrega continua | Despliegue continuo |
|---|---|---|
| Paso final a producción | Manual (un clic de aprobación) | Automático |
| Requiere | Pipeline con tests fiables | Cobertura de tests muy alta y confianza en el proceso |
| Riesgo si un test se cuela | Se detecta antes de aprobar | Llega directo a producción |
Automatizar el despliegue no elimina la necesidad de buenos tests, la hace imprescindible: sin tests fiables, un pipeline automático solo despliega errores más rápido.
Por dónde empezar si nunca has montado un pipeline
No hace falta construir las cuatro etapas de golpe. Empieza por lo más barato de implementar y lo más rentable: ejecutar tests automáticamente en cada pull request. Solo con eso ya evitas que código roto se fusione a la rama principal. Añade el build automático después, y deja el despliegue automático para cuando el proyecto y la cobertura de tests lo justifiquen. GitHub Actions, GitLab CI y CircleCI tienen niveles gratuitos más que suficientes para proyectos personales y pequeños equipos.
