CI/CD con GitHub Actions desde cero | Alteo

Un buen pipeline de integración y despliegue continuo (CI/CD) convierte un despliegue manual, lento y con miedo en algo aburrido y repetible. Ese es exactamente el objetivo: que desplegar deje de dar miedo. Aquí va cómo montarlo con GitHub Actions.

Qué es CI/CD y por qué importa

• Integración continua (CI): cada vez que alguien sube código, se ejecutan automáticamente las pruebas y la construcción. Si algo se rompe, lo sabes al minuto, no el día del despliegue.
• Despliegue continuo (CD): cuando el código pasa las pruebas, se despliega automáticamente al entorno correspondiente.

El beneficio real no es la velocidad por sí sola, sino la confianza: cambios pequeños, verificados y desplegables en cualquier momento.

Antes de escribir el pipeline

Necesitas tener claro:

1. Cómo se construye tu aplicación (build).
2. Cómo se ejecutan sus pruebas (test).
3. Cómo se despliega (a un servidor, un contenedor, un servicio gestionado).
4. Dónde viven los secretos (claves de despliegue, tokens).

Si el despliegue hoy es “entrar por SSH y hacer cosas a mano”, el primer paso es automatizar exactamente eso en un script. El pipeline solo lo ejecutará por ti.

Estructura básica de un workflow

En GitHub Actions, un workflow es un archivo YAML dentro de .github/workflows/. Un esqueleto típico:

name: CI/CD

on:
  push:
    branches: [main]
  pull_request:

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

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/deploy.sh
        env:
          DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}

Lo importante:

• El job de test se ejecuta siempre (también en pull requests).
• El de deploy solo corre en main y solo si el test ha pasado (needs).
• Los secretos van en GitHub Secrets, nunca en el código.

Los secretos, bien guardados

Reglas de oro:

• Nunca metas credenciales en el repositorio.
• Usa GitHub Secrets (o un gestor como AWS Secrets Manager / Azure Key Vault).
• Usa cuentas de despliegue con el mínimo privilegio necesario.
• Rota las claves periódicamente.

Buenas prácticas que marcan la diferencia

1. Mergea a main solo si CI pasa. Activa la protección de rama y exige que los checks estén en verde.
2. Cambios pequeños. Un despliegue con 200 cambios es un despliegue que no quieres depurar.
3. Entornos por rama. main despliega a producción, develop a staging, etc.
4. Assets/artefactos versionados. Construye una vez y despliega ese mismo artefacto.
5. Rollback fácil. Debes poder volver a la versión anterior en cuestión de minutos.
6. Notificaciones. Que el equipo sepa cuándo un pipeline falla, en Slack o por email.

Errores comunes al empezar

• Ponerse a hacer un pipeline gigante de golpe. Empieza con test + deploy simple y crece.
• Ignorar el entorno real. Probar en un entorno distinto del de producción lleva a sorpresas.
• No fijar versiones. Usa versiones concretas de las acciones (@v4), no @main.
• Secretos en logs. Cuidado con imprimir variables sensibles en el pipeline.

El siguiente paso

Una vez tienes CI/CD, encaja de forma natural con contenedores (Docker) y con monitorización: cada despliegue es un evento medible y reversible.

Si quieres montar esto sin pelearte con la configuración, en el CloudStart Pack dejamos un pipeline completo listo para tu equipo, y en la gestión continua lo mantenemos actualizado.

¿Empezamos? Cuéntanos tu caso.