¿Qué es CI/CD? Integración y Despliegue Continuo Explicados
Desglosa los pilares de CI/CD: qué es Integración Continua frente a Entrega Continua, cómo funciona una pipeline con GitHub Actions, pruebas automatizadas y despliegue sin tiempo de inactividad (Zero-Downtime).
CI/CD (Continuous Integration / Continuous Delivery o Deployment) es una filosofía y conjunto de prácticas automatizadas de ingeniería de software que permite a los equipos compilar, probar y desplegar cambios en el código de forma frecuente, automática y segura desde el repositorio hacia los servidores de producción.
Elimina el terror histórico a los 'viernes de despliegue': automatiza la ejecución de pruebas unitarias, análisis de vulnerabilidades y la subida al servidor en cada `git push`, detectando errores en minutos en lugar de semanas y permitiendo lanzar actualizaciones constantes sin estrés.
Imagina la línea de ensamblaje automatizada de una fábrica moderna de automóviles: los operarios no arman el auto a mano ni lo pintan con brocha; cada pieza que entra pasa por brazos robóticos con sensores láser que miden tolerancias milimétricas y prueban los frenos automáticamente. Si una pieza está defectuosa, la línea de montaje se detiene al instante (CI). Si todas las pruebas pasan la luz verde, el auto se transporta solo al tren de despacho hacia las tiendas (CD).
Explicación Paso a Paso del Tema
Diferenciar CI, Continuous Delivery y Continuous Deployment
Comprende el nivel de automatización de cada etapa.
CI (Integración Continua): Cada desarrollador empuja código a Git -> La máquina virtual en la nube descarga el código, instala dependencias, corre linters y pruebas unitarias. Si una prueba falla, avisa de inmediato. Continuous Delivery: El código probado se compila en un artefacto listo (ej. una imagen Docker) y queda preparado para lanzarse esperando que un humano presione el botón 'Aprobar lanzamiento'. Continuous Deployment: No hay botón humano; si las pruebas pasaron en verde, el sistema se despliega solo a producción.
Código -> Pruebas Automáticas (CI) -> Artefacto Listo (Continuous Delivery) -> En Producción Vivo (Continuous Deployment)
| Parámetro / Flag | Tipo / Rol | Significado y Uso |
|---|---|---|
| CI (Integración) | Filtro de calidad | Verifica que el código nuevo no rompa funcionalidades existentes |
| CD (Despliegue) | Entrega de valor | Pone el software a disposición de los usuarios finales de manera predecible |
Comienza con CI: antes de preocuparte por desplegar automáticamente a servidores, asegura que tu pipeline ejecute tus pruebas en cada Pull Request.
Llamar a un script manual que sube archivos por FTP 'hacer CI/CD'. Si no hay pruebas automatizadas que bloqueen errores, no es CI/CD.
Configurar una pipeline con GitHub Actions
Crea el archivo de flujo de trabajo en la carpeta `.github/workflows/`.
GitHub Actions busca archivos YAML dentro de `.github/workflows/`. Cada flujo define: 1. `on`: los eventos desencadenantes (ej. `push: branches: [main]`). 2. `jobs`: tareas que corren en máquinas virtuales independientes (ej. `ubuntu-latest`). 3. `steps`: la lista secuencial de acciones (ej. descargar repositorio, configurar runtime, ejecutar scripts).
mkdir -p .github/workflows && touch .github/workflows/deploy.yml
| Parámetro / Flag | Tipo / Rol | Significado y Uso |
|---|---|---|
| on: push | Disparador (Trigger) | Activa la ejecución automática de la pipeline ante cualquier push a las ramas indicadas |
| runs-on: ubuntu-latest | Entorno de ejecución (Runner) | Máquina virtual efímera y limpia provista por GitHub para ejecutar las instrucciones |
Aprovecha las acciones preconstruidas oficiales del marketplace de GitHub (`actions/checkout`, `actions/setup-node`, `docker/build-push-action`) para no reinventar la rueda.
Cometer errores de sangría o espaciado en archivos YAML; el formato YAML es estricto y no admite tabulaciones, solo espacios.
Asegurar credenciales con GitHub Secrets
Transmite llaves y tokens a la pipeline sin exponerlos en el código público.
JAMÁS escribas claves de servidores, contraseñas de bases de datos o tokens de SSH en el archivo YAML del repositorio. Ve a Settings > Secrets and variables > Actions en tu repositorio de GitHub y guárdalas como secretos cifrados. En tu archivo YAML accedes a ellas mediante la sintaxis segura `${{ secrets.NOMBRE_SECRETO }}`.
ssh -i ${{ secrets.SSH_PRIVATE_KEY }} ${{ secrets.SERVER_USER }}@${{ secrets.SERVER_IP }} "cd /app && git pull && docker compose up -d --build"| Parámetro / Flag | Tipo / Rol | Significado y Uso |
|---|---|---|
| ${{ secrets.VARIABLE }} | Inyección segura | Inserta el valor cifrado en tiempo de ejecución enmascarándolo automáticamente en los logs visuales |
Utiliza entornos protegidos (GitHub Environments) para exigir aprobación manual de un líder técnico antes de que los secretos de producción sean accesibles.
Hacer un `echo ${{ secrets.PASSWORD }}` en la terminal de la pipeline para depurar, exponiendo potencialmente credenciales.
Casos Prácticos Reales en Producción
Situaciones de ingeniería reales sin mención de presupuestos ficticios.
1Caso de Producción: De Despliegues Manuales Estresantes a 15 Despliegues Diarios en Paz
Un equipo de 8 desarrolladores realizaba despliegues manuales conectándose por SSH cada dos semanas. La sesión tomaba 3 horas de noche, solía fallar por dependencias olvidadas y requería revertir cambios a ciegas con el servicio caído.
Se diseñó una pipeline completa en GitHub Actions: cada Pull Request ejecuta la suite de 150 pruebas unitarias; al fusionar a `main`, la pipeline construye una imagen Docker inmutable, la envía a un registro privado y notifica al servidor para actualizar el contenedor sin corte de servicio.
Fichas Nemotécnicas de Conceptos Clave
Glosario rápido para recordar los términos fundamentales de la lección.
Práctica de integrar y validar automáticamente los cambios de código de todos los desarrolladores varias veces al día mediante compilación y pruebas automáticas.
Paso donde cada cambio que supera con éxito todas las pruebas automáticas de la pipeline se despliega directamente a producción sin intervención humana.
Plataforma de CI/CD integrada directamente en GitHub que automatiza flujos de trabajo basados en eventos (push, pull_request, release) mediante archivos YAML.
¿Qué es CI/CD? Integración y Despliegue Continuo Explicados
Selecciona una opción para autoevaluarte al instante. La respuesta se califica de inmediato.
¿Cuál es la función principal de la Integración Continua (CI)?
¿En qué carpeta y formato de archivo deben guardarse los flujos de trabajo de GitHub Actions?
¿Dónde deben almacenarse de forma segura las contraseñas y llaves SSH utilizadas en una pipeline de CI/CD?
Preguntas Frecuentes (FAQ)
¿Es obligatorio pagar para usar GitHub Actions?
No. Para repositorios públicos es 100% gratuito e ilimitado; para repositorios privados, las cuentas gratuitas de GitHub incluyen 2,000 minutos de cómputo gratuitos al mes en máquinas Linux.
¿Qué es un Runner en CI/CD?
Es el servidor o máquina virtual que escucha los trabajos de la pipeline, descarga el código y ejecuta los comandos. Puedes usar los runners gestionados en la nube por GitHub o conectar tus propios servidores privados (Self-Hosted Runners).
¿Qué es un despliegue sin tiempo de inactividad (Zero-Downtime)?
Es una estrategia (como Blue-Green o Rolling Update) donde la nueva versión de la aplicación se enciende y valida primero en paralelo; solo cuando está sana, el tráfico de red se redirige a la nueva versión sin que ningún usuario experimente un segundo de corte de servicio.