CI/CD pipelines

Si estás harto de hacer git push y luego entrar al servidor por SSH a hacer un git pull y reiniciar manualmente el proceso, ya tienes la mitad del camino andado. Estás listo para dejar de ser un operario de tu propio código y empezar a delegar en GitHub Actions.

A mediados de 2026, la realidad es que si tu pipeline no está automatizado, estás perdiendo tiempo valioso. GitHub Actions ha madurado un montón. Ya no es solo esa herramienta "curiosa" que probamos hace años; es el estándar de facto. Vamos a montar un flujo de trabajo serio sin marearte con teoría innecesaria.

La estructura del archivo .yaml

Todo empieza en la carpeta .github/workflows/. Ahí es donde viven tus automatizaciones. Cada archivo .yaml en ese directorio es un workflow independiente. Olvídate de herramientas externas; esto vive pegado a tu repo, lo que significa que el versionado de tu infraestructura de despliegue va de la mano con tu código.

Para que esto funcione, necesitas entender el trigger (disparador). ¿Cuándo quieres que corra esto? Normalmente, en cada push a la rama main o en cada pull request.

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

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '22'
      - name: Install and Test
        run: |
          npm ci
          npm run test

Aquí hay un detalle técnico clave: npm ci en lugar de npm install. En un entorno de CI, no quieres actualizar dependencias por accidente. npm ci asegura que vas a instalar exactamente lo que dice tu package-lock.json. Si el lock no coincide, el proceso falla. Eso es lo que queremos: consistencia.

La regla de oro: nunca subas secretos

Uno de los errores más comunes cuando estás empezando con este tutorial de GitHub Actions es hardcodear credenciales en el archivo .yaml. Por favor, no lo hagas. GitHub tiene una pestaña llamada "Secrets and variables" en la configuración de tu repositorio.

Ahí es donde metes tu AWS_SECRET_ACCESS_KEY, tu token de Docker Hub o la API Key de tu proveedor de Cloud. Luego, en tu archivo de workflow, los invocas así:

      - name: Deploy to Cloud
        env:
          MY_API_KEY: ${{ secrets.MY_API_KEY }}
        run: ./deploy.sh

El log de GitHub Actions es inteligente y censura los valores de los secretos (los cambia por asteriscos), pero si los imprimes explícitamente en un echo, podrían aparecer. Ten cuidado con los logs.

El salto de CI a CD: Entornos y Despliegue

La integración continua (CI) es fácil: es solo pasar tests. La entrega continua (CD) da más respeto. Mi consejo: empieza por automatizar el despliegue a un entorno de Staging.

Usa los Environments de GitHub. Puedes configurarlos para que requieran aprobación manual. Esto es oro puro para evitar que un bug llegue a producción por error. Vas a Settings > Environments y creas uno llamado "production". Activa la casilla de "Required reviewers".

Ahora, cuando tu pipeline llegue al job de despliegue, GitHub pausará la ejecución hasta que tú (o el lead técnico) hagas clic en "Approve". Esto te da una red de seguridad brutal.

Para el despliegue en sí, en 2026 lo normal es mover contenedores. Si usas Docker, el flujo debería ser:

1. Build de la imagen.
2. Login en el registry (GitHub Packages o ECR).
3. Push con el tag basado en el SHA del commit (${{ github.sha }}).
4. Actualización del deployment en Kubernetes o el servicio de contenedores que uses.

Performance: Por qué tus builds son lentos

Si tu pipeline tarda 15 minutos en terminar, vas a terminar odiando hacer commits. Aquí es donde los principiantes fallan. Tienes que usar caching.

GitHub Actions tiene una acción oficial para manejar caché. Si estás usando una app de Next.js o un proyecto de Go, no quieres descargar las dependencias de internet cada vez.

      - name: Cache node modules
        uses: actions/cache@v4
        with:
          path: ~/.npm
          key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-node-

Al incluir el hashFiles('**/package-lock.json'), el caché solo se invalida cuando cambias tus dependencias. Si solo cambias código fuente, el job de install será casi instantáneo. Esos segundos cuentan cuando tienes un equipo haciendo merge constantemente.

¿Qué pasa cuando algo falla?

Es inevitable. Un test fallará, el linter se quejará o el despliegue al cloud dará timeout. GitHub Actions te manda un email, pero es molesto.

Lo mejor que puedes hacer es configurar notificaciones en Slack o Discord. Hay acciones prefabricadas, como 8398a7/action-slack, que te avisan con el enlace directo al commit que rompió la build. No esperes a que el cliente te diga que la web está caída; entérate tú primero.

Un último consejo de "colega"

No intentes hacer todo el flujo de CI/CD perfecto el primer día. Empieza solo con los tests. Cuando confíes en que tu pipeline te avisa si rompes algo, añade el despliegue automático.

Muchos se obsesionan con el "GitOps" avanzado desde el día uno y terminan con un archivo .yaml de 400 líneas que nadie entiende. Mantén tus workflows modulares. Si una tarea es compleja, crea un script en bash (scripts/deploy.sh) y llama al script desde el workflow. Así puedes probar el script en tu máquina local sin tener que hacer push a GitHub mil veces para ver si el comando está bien escrito.

GitHub Actions es una herramienta potente, pero al final del día es código. Trátalo como tal: testeable, versionable y, sobre todo, sencillo. Si puedes explicar lo que hace tu workflow en una frase, vas por buen camino. Si necesitas un diagrama de flujo de diez páginas para entender cómo se despliega tu app, es hora de simplificar.

¿Ya tienes tu primer .yaml configurado? Si no, hoy es el mejor día para subir ese archivo al repo y dejar que GitHub haga el trabajo sucio por ti.