Hacer deploy a mano tiene un ciclo de vida bastante predecible. Funciona bien hasta que alguien del equipo sube un cambio apurado un viernes, se olvida de correr los tests, y el bug llega a producción mientras todos están desconectados. No es un problema de disciplina: es un problema de proceso. Un proceso manual se rompe exactamente cuando más presión hay para que no lo haga.

GitHub Actions resuelve eso poniendo el pipeline dentro del repositorio. No hay un servidor de CI separado que mantener, no hay integraciones externas que configurar. Los workflows viven en .github/workflows/ y se ejecutan en respuesta a eventos de Git.

Qué es CI/CD y qué parte hace GitHub Actions

Integración continua (CI) es la práctica de correr tests automáticamente cada vez que alguien sube código. La idea es detectar problemas lo antes posible, cuando el contexto todavía está fresco y el fix es barato. Entrega continua (CD) es llevar ese código validado a un entorno de staging o producción sin intervención manual.

GitHub Actions puede hacer las dos cosas. Es una plataforma de automatización basada en eventos: cuando ocurre algo en el repositorio, un push, la apertura de un pull request, la creación de un tag, un cron schedule, se ejecutan los jobs que hayas definido.

A principios de 2026, la plataforma procesa más de 71 millones de jobs por día y el GitHub Marketplace supera las 10,000 acciones publicadas en 32 categorías. Prácticamente cualquier cosa que necesitás hacer ya tiene una action publicada.

La anatomía de un workflow

Un workflow es un archivo YAML dentro de .github/workflows/. Un repositorio puede tener tantos workflows como necesite. El nombre del archivo es libre, pero tiene que tener extensión .yml o .yaml.

name: CI
 
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
 
jobs:
  test:
    runs-on: ubuntu-latest
 
    steps:
      - uses: actions/checkout@v4
 
      - name: Instalar Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
 
      - name: Instalar dependencias
        run: npm ci
 
      - name: Correr tests
        run: npm test

El campo on define qué eventos disparan el workflow. jobs contiene uno o más trabajos. Cada job corre en un runner, que por defecto es una máquina virtual efímera que GitHub provisiona, usa y destruye. Los steps dentro de un job se ejecutan en secuencia sobre la misma máquina.

El uses: actions/checkout@v4 es un step que clona el repositorio en el runner. Sin ese step, la máquina existe pero no tiene tu código. Es uno de los pocos steps que prácticamente siempre aparece primero.

Runners, qué son y cuánto cuestan

GitHub Actions es gratuito para repositorios públicos y ofrece 2,000 minutos mensuales en el tier gratuito para repositorios privados. Para proyectos personales y open source, eso alcanza con mucho margen.

En enero de 2026 GitHub bajó los precios de los runners hasta un 39%. El costo actual es de $0.008 por minuto para runners Linux estándar y $0.016 por minuto para runners más grandes. macOS es el caso donde hay que prestar atención porque cuesta $0.08 por minuto, diez veces más que Linux.

El runner ubuntu-latest apunta en este momento a Ubuntu 24.04. En 2026 GitHub sumó nuevas imágenes en preview público: Ubuntu 26.04 para x64 y arm64, y Windows 11 arm64 con Visual Studio 2026.

Las imágenes personalizadas para runners hosteados por GitHub alcanzaron disponibilidad general en abril de 2026. Eso permite definir exactamente qué software viene preinstalado en el runner en lugar de instalarlo en cada run, lo que reduce tiempos de ejecución en pipelines con muchas dependencias del sistema.

Secrets y entornos

Las credenciales nunca van en el YAML. GitHub tiene un sistema de secrets a nivel de repositorio y de organización que los encripta en reposo y los inyecta en los workflows como variables de entorno. Se definen en Settings → Secrets and variables → Actions.

Dentro del workflow se referencian así:

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

Los entornos (environments) agregan una capa de control sobre los secrets y los deployments. Podés definir un entorno production que requiera aprobación manual antes de que cualquier job que use ese entorno pueda ejecutarse. Eso sirve para evitar que un push directo a main despliegue automáticamente a producción sin revisión.

jobs:
  deploy:
    environment: production
    runs-on: ubuntu-latest
    steps:
      - run: echo "Desplegando a producción"

Los secrets definidos en el entorno production solo son accesibles para jobs que declaren ese entorno.

OIDC para conectar con Azure sin secrets

Guardar un secret de Azure en GitHub funciona, pero introduce una credencial que tiene que rotarse, que puede filtrarse y que tiene permisos más amplios de los necesarios. OpenID Connect (OIDC) resuelve eso de forma más elegante.

Con OIDC, el workflow solicita un token firmado por GitHub directamente durante la ejecución. Azure verifica ese token contra una federated credential configurada en un service principal y entrega credenciales de acceso temporales para ese run puntual. No hay nada que guardar como secret. Las credenciales duran exactamente lo que dura el job.

jobs:
  deploy:
    permissions:
      id-token: write
      contents: read
    environment: production
    runs-on: ubuntu-latest
 
    steps:
      - uses: actions/checkout@v4
 
      - uses: azure/login@v2
        with:
          client-id: ${{ vars.AZURE_CLIENT_ID }}
          tenant-id: ${{ vars.AZURE_TENANT_ID }}
          subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}
 
      - run: az webapp deploy --name mi-app --resource-group mi-rg --src-path ./dist

Los tres valores del login son variables (no secrets) porque no son credenciales en sí, son identificadores públicos del service principal. Las credenciales temporales las negocia el runtime de OIDC en segundo plano.

En abril de 2026, OIDC para GitHub Actions sumó soporte para custom properties de repositorio como claims en el token, lo que alcanzó disponibilidad general. Eso permite escribir políticas de acceso más granulares en Azure basadas en atributos del repositorio, no solo en el nombre o la rama.

Caché y concurrencia

Instalar dependencias en cada run es el factor que más tiempo agrega a un pipeline típico. La action actions/cache guarda y restaura directorios entre runs basándose en una cache key.

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

setup-node con cache: npm ya maneja la caché de node_modules automáticamente. Para otros lenguajes y herramientas hay que configurarlo explícitamente con actions/cache.

El control de concurrencia evita que múltiples runs del mismo workflow se pisen entre sí. Si hacés tres pushes seguidos rápido, sin control de concurrencia se van a encolar tres runs. Con esto, el run en progreso se cancela cuando llega uno nuevo:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

En ramas de feature tiene sentido cancelar el run anterior. En main puede que no quieras cancelar porque cada run genera un artefacto de deploy. Se puede condicionar usando github.ref.

Novedades de julio y agosto de 2026

GitHub Agentic Workflows entró en preview público a principios de 2026 para automatizar tareas como triage de issues, análisis de fallos de CI y actualizaciones de documentación. En julio se sumó otra integración relevante: ahora podés correr el GitHub Copilot CLI directamente dentro de un workflow usando el GITHUB_TOKEN integrado, sin necesidad de crear ni guardar un personal access token separado. El mismo principio que ya aplicaba a Agentic Workflows se extendió a Copilot CLI.

Dos cambios de seguridad también entraron en vigencia. GitHub Enterprise Cloud con Data Residency comenzó a aplicar desde el 31 de julio de 2026 el enforcement de versión mínima para self-hosted runners. Los runners por debajo de la versión mínima requerida dejan de poder registrarse o ejecutar jobs. GitHub Enterprise Cloud (sin Data Residency) sigue el mismo camino desde el 25 de septiembre de 2026.

El otro cambio es de seguridad de supply chain: GitHub Actions ahora retiene automáticamente runs identificados como potencialmente maliciosos en repositorios públicos, requiriendo aprobación explícita de un colaborador con acceso de escritura antes de que el workflow se ejecute. Eso previene que credenciales comprometidas puedan disparar workflows sin intervención humana.

Ninguna de estas tres novedades afecta el comportamiento de un pipeline estándar bien configurado. Sí afectan a equipos con self-hosted runners desactualizados y a proyectos open source que aceptan contribuciones externas sin revisión.

Una observación práctica antes de terminar

La curva de GitHub Actions no está en entender YAML. Está en entender el modelo de ejecución: qué comparte estado entre steps y qué no, cuándo conviene partir en múltiples jobs y cuándo no, y cómo el contexto de github.* te da información sobre el evento que disparó el workflow.

La documentación oficial es buena. El problema es que tiene mucho de todo y no siempre queda claro cuál es el punto de entrada correcto para alguien que recién arranca. El lugar más útil para empezar es el quickstart de Microsoft Learn que combina GitHub Actions con Azure, que conecta directamente con la mayoría de los casos prácticos de deploy en la nube:

👉 https://learn.microsoft.com/azure/developer/github/github-actions?wt.mc_id=studentamb_510930

La información de este artículo está basada en la documentación oficial de GitHub y fuentes verificadas al momento de su publicación. GitHub puede actualizar precios, features y comportamientos de la plataforma en cualquier momento. Revisá la documentación oficial en docs.github.com antes de tomar decisiones basadas en este contenido.