Sin automatización, cada lanzamiento va así: alguien ejecuta las pruebas, alguien compila la aplicación, alguien copia archivos a un servidor. La gente olvida pasos. La gente comete erratas. Los lanzamientos se vuelven lentos y aterradores.

GitHub Actions elimina ese dolor. Describes los pasos una vez y GitHub los ejecuta en cada cambio.

CI/CD en palabras sencillas

• Integración continua (CI): cada vez que alguien sube código, el sistema lo compila y ejecuta las pruebas. Encuentras los problemas en minutos.
• Entrega o despliegue continuo (CD): el código que pasa las comprobaciones se prepara para el lanzamiento, o se lanza automáticamente.

GitHub Actions es la herramienta de CI/CD integrada en GitHub. Si eres nuevo en GitHub, empieza con nuestro tutorial de Git para principiantes.

Las partes principales de GitHub Actions

Tu primer workflow

Crea un archivo llamado .github/workflows/hello.yml en tu repositorio:

name: Hello
on: [push]

jobs:
  greet:
    runs-on: ubuntu-latest
    steps:
      - name: Say hello
        run: echo "Hola desde GitHub Actions"

Haz commit y push. Abre la pestaña Actions de tu repositorio y verás la ejecución. Haz clic en ella para leer los registros.

Un workflow real: instalar, probar y compilar

Esta es una configuración habitual para un proyecto de Node.js. Se ejecuta en cada push y pull request a main.

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

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - run: npm ci
      - run: npm test
      - run: npm run build

Línea por línea: checkout descarga tu código, setup-node instala Node y guarda en caché los paquetes, y los tres pasos run instalan, prueban y compilan. Si cualquier paso falla, falla todo el job y GitHub marca el pull request en rojo.

Usa los secretos de forma segura

No escribas nunca contraseñas, claves de API ni tokens en tu archivo de workflow. Añádelos en Settings → Secrets and variables → Actions y luego léelos en el workflow:

- name: Deploy
  run: ./deploy.sh
  env:
    API_TOKEN: ${{ secrets.API_TOKEN }}

GitHub oculta los valores de los secretos en los registros. Aun así, evita imprimirlos y da a cada token solo el acceso que necesita.

Prueba muchas versiones con una matriz y ve más rápido con la caché

Una matriz ejecuta el mismo job con distintas configuraciones, como varias versiones de Node:

strategy:
  matrix:
    node: [18, 20, 22]
steps:
  - uses: actions/setup-node@v4
    with:
      node-version: ${{ matrix.node }}
      cache: npm

La caché guarda los paquetes descargados entre ejecuciones, para que la siguiente empiece más rápido. La mayoría de las acciones de configuración tienen una opción cache sencilla, como se muestra arriba.

Despliega automáticamente

Cuando las pruebas pasan, puedes desplegar. Un patrón seguro es desplegar solo desde main y solo después de que el job de pruebas termine bien:

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

La línea needs hace que el despliegue espere a las pruebas. La línea environment te permite añadir una aprobación manual antes de producción. Si lanzas aplicaciones en contenedores, aprende lo básico en nuestro tutorial de Docker.

Buenas prácticas

• Mantén los jobs pequeños y rápidos. Los pipelines lentos se ignoran.
• Fija las versiones de las acciones. Usa @v4 o un hash de commit completo, no una rama que se mueve.
• Usa el mínimo privilegio. Define permissions en el workflow solo con lo que necesita.
• Ejecuta primero las comprobaciones rápidas. Lint y pruebas unitarias antes de las pruebas end-to-end lentas.
• Guarda los informes. Sube los informes de pruebas como artefactos para poder leer los fallos.
• Ten cuidado con las acciones de terceros. Prefiere las conocidas y lee lo que hacen.

¿Quieres añadir pruebas de navegador a tu pipeline? Consulta las buenas prácticas de pruebas end-to-end para saber qué ejecutar y cuándo.

Errores comunes y soluciones rápidas

Preguntas frecuentes

Sigue aprendiendo