Implementa el workflow de build, test y deploy

Tipo de lección: Video

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:

1. Build: Instala dependencias con npm install y compila la aplicación si es necesario (por ejemplo, usando TypeScript).
2. Test: Ejecuta pruebas con un framework como Jest, asegurando que el código funciona correctamente.
3. 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/heroku-deploy@v3.12.12
        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:

1. 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.
2. 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.
3. 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).
4. Agrega caching: Implementa caching para optimizar, por ejemplo, cache de npm si usas Node.js, o de otros gestores.
5. 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.
6. 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.