Concepto clave

Un workflow de CI/CD en GitHub Actions es una secuencia automatizada que transforma tu código en una aplicación desplegada. Piensa en ello como una línea de ensamblaje en una fábrica: cada commit que haces es una pieza que entra, pasa por estaciones de build (compilación/construcción), test (pruebas) y finalmente deploy (despliegue), saliendo como un producto terminado y listo para usar. Este proceso elimina el trabajo manual repetitivo y reduce errores humanos.

Para una aplicación moderna, este workflow no solo compila código, sino que gestiona dependencias, ejecuta pruebas unitarias y de integración, genera artefactos y los despliega en un entorno (como staging o producción). La clave está en la automatización completa: desde que un desarrollador hace push hasta que la aplicación está disponible para los usuarios, todo ocurre sin intervención manual, asegurando consistencia y velocidad.

Cómo funciona en la práctica

Imagina que trabajas en una aplicación Node.js con una API REST. Tu workflow se activa con cada push a la rama main. Primero, GitHub Actions inicia un runner (una máquina virtual) con el sistema operativo que especifiques. Luego, ejecuta los jobs en el orden que definas, típicamente:

Build: Instala dependencias con npm install y compila la aplicación si es necesario (por ejemplo, usando TypeScript).
Test: Ejecuta pruebas con un framework como Jest, asegurando que el código funciona correctamente.
Deploy: Si las pruebas pasan, despliega la aplicación en un servidor, como AWS EC2 o un PaaS como Heroku, usando credenciales seguras almacenadas en secrets.

Este flujo se define en un archivo YAML en tu repositorio, bajo .github/workflows/, lo que lo hace versionable y colaborativo. Por ejemplo, un push desencadena el workflow, y si falla en cualquier paso, se notifica al equipo para corregirlo antes de llegar a producción.

Código en acción

Aquí tienes un ejemplo funcional de un workflow para una aplicación Node.js que build, test y deploy a Heroku. Primero, el código básico:

name: CI/CD Pipeline

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'
      - name: Install dependencies
        run: npm ci
      - name: Run tests
        run: npm test
      - name: Build application
        run: npm run build
  deploy:
    needs: build-and-test
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
      - name: Deploy to Heroku
        uses: akhileshns/[email protected]
        with:
          heroku_api_key: ${{ secrets.HEROKU_API_KEY }}
          heroku_app_name: "tu-app-aqui"
          heroku_email: ${{ secrets.HEROKU_EMAIL }}

Ahora, mejoremos este código agregando caching para acelerar el build y manejo de artefactos. Observa el antes y después:

Antes: Sin caching, cada run reinstala dependencias desde cero, lo que es lento.

Después: Con caching, reutiliza dependencias si no cambian, ahorrando tiempo. Agrega esto después de Setup Node.js:

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

Errores comunes

No usar secrets para credenciales: Nunca hardcodear API keys o passwords en el YAML. Usa GitHub Secrets (en configuración del repo) y referéncialas con ${{ secrets.NOMBRE }}.
Olvidar el caching: Sin cache, builds lentos aumentan costos y tiempo. Implementa caching para node_modules, pip, u otros gestores de paquetes.
No manejar fallos en tests: Si un test falla, el workflow debería detenerse y no proceder a deploy. Asegúrate de que los jobs tengan dependencias (needs) y condiciones (if) correctas.
Desplegar en cada push: Para ramas de desarrollo, usa condiciones como if: github.ref != 'refs/heads/main' para evitar deploys no deseados a producción.
Ignorar el tamaño del runner: Usar un runner más grande de lo necesario (como ubuntu-latest vs ubuntu-20.04) puede incrementar costos. Elige el adecuado para tu aplicación.

Checklist de dominio

He definido un archivo YAML en .github/workflows/ con al menos dos jobs: build-and-test y deploy.
Uso GitHub Secrets para todas las credenciales sensibles, como API keys de servicios en la nube.
He implementado caching para dependencias (ej., con actions/cache) para optimizar el tiempo de ejecución.
Mi workflow se activa solo en eventos relevantes (push a main, pull requests) y tiene condiciones para controlar el deploy.
Incluyo pasos para instalar dependencias, ejecutar pruebas y construir la aplicación antes de cualquier deploy.
Verifico que los jobs tengan dependencias definidas (needs) para asegurar un orden correcto de ejecución.
He probado el workflow en un entorno de staging o con un dry-run antes de aplicarlo a producción.

Crea un workflow CI/CD para una app web simple

En este ejercicio, implementarás un workflow completo de GitHub Actions para una aplicación web básica. Sigue estos pasos:

Prepara tu repositorio: Crea un nuevo repositorio en GitHub o usa uno existente. Asegúrate de tener una aplicación simple, como un sitio estático HTML/CSS o una app Node.js con un archivo package.json.
Define el evento de trigger: Crea un archivo llamado ci-cd.yml en la carpeta .github/workflows/. Configúralo para que se ejecute en push a la rama main y en pull requests a main.
Configura el job de build y test: Agrega un job que use ubuntu-latest, haga checkout del código, instale dependencias (si las hay), ejecute un comando de test simple (puede ser un echo para simular) y construya la aplicación (ej., copiar archivos a una carpeta dist).
Agrega caching: Implementa caching para optimizar, por ejemplo, cache de npm si usas Node.js, o de otros gestores.
Crea el job de deploy: Añade un segundo job que dependa del primero y se ejecute solo en push a main. Simula un deploy subiendo artefactos con actions/upload-artifact, o si tienes un servicio configurado, usa un action como peaceiris/actions-gh-pages para GitHub Pages.
Prueba el workflow: Haz un push a tu repositorio y verifica en la pestaña Actions de GitHub que el workflow se ejecute correctamente, pasando por todos los pasos.

Entrega: Comparte el enlace a tu repositorio con el workflow funcionando, o pega el contenido de tu archivo YAML en un gist.

Pistas

Usa actions/checkout@v3 como primer paso en cada job para obtener el código.
Para simular tests, puedes usar un comando como 'echo "Tests passed"' en el run.
Si no tienes un servicio real para deploy, sube artefactos con actions/upload-artifact para practicar.

Evalua tu comprension

Completa el quiz interactivo de arriba para ganar XP.

Implementa el workflow de build, test y deploy