GitHub Actions: prueba una app antes de desplegar

GitHub Actions permite ejecutar tareas cuando cambia un repositorio. Para empezar, conviene construir integración continua: instalar dependencias y comprobar el proyecto. El despliegue debe añadirse como una etapa separada con permisos y condiciones explícitos.

Este ejemplo supone una aplicación Node.js con package.json, package-lock.json y un script test que realmente detecta errores. El archivo del workflow no crea esas pruebas por sí solo.

Prepara el repositorio

Ejecuta localmente la instalación y los tests con una versión Node mantenida. Si npm test termina siempre con éxito aunque la aplicación falle, la automatización solo repetirá una comprobación inútil.

Conserva el lockfile para que npm ci pueda reconstruir las dependencias acordadas. Revisa también los scripts de instalación de paquetes, porque forman parte del código que ejecuta el runner.

Workflow inicial

Guarda .github/workflows/ci.yml:

name: Comprobaciones
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
permissions:
  contents: read
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-node@v7
        with:
          node-version: "24"
          cache: npm
      - run: npm ci
      - run: npm test

Comprueba compatibilidad de las acciones y del runner con el proyecto. Para mayor control de cadena de suministro, fija acciones a un commit revisado y establece un mecanismo para actualizarlas.

Verifica un éxito y un fallo

Abre la ejecución y revisa cada etapa. Después introduce un fallo controlado en una rama de prueba y confirma que produce un resultado fallido.

Una salida verde puede ocultar comandos que ignoran errores o pruebas que nunca se ejecutaron. Consulta el detalle y verifica que el evento y commit corresponden al cambio esperado.

Permisos y código no confiable

Una solicitud de cambios puede contener código de otras personas. No le proporciones credenciales de producción ni ejecutes configuraciones privilegiadas sin revisar el modelo de seguridad del evento.

Evita usar pull_request_target como sustitución automática de pull_request: cambia el contexto de ejecución y exige controles adicionales. Los nombres parecidos no implican permisos equivalentes.

Separar construcción y despliegue

Cuando añadas una imagen, registra una etiqueta ligada al commit o un digest. “latest” no explica qué revisión estás desplegando ni cómo regresar a la anterior.

El despliegue necesita un destino definido, permisos mínimos y, cuando corresponda, un entorno con revisión. Usa credenciales temporales o identidades federadas cuando la plataforma lo permita y evita claves permanentes compartidas.

Secretos y conexiones remotas

Guarda los secretos en mecanismos apropiados del entorno y no los imprimas. Una redacción en logs no protege todas las transformaciones posibles de un secreto.

Para SSH, valida la identidad del host por un canal confiable. Desactivar host key checking para que el job deje de fallar elimina una comprobación importante, no resuelve la causa.

Recuperación y costo

Define límites de tiempo, concurrencia y conservación de artefactos según tu uso. Revisa condiciones del plan y consumo sin suponer ejecución ilimitada.

Antes de automatizar producción, prueba cómo revertir código y qué ocurre con datos o migraciones. Un rollback de imagen no deshace necesariamente una modificación de base de datos.

Preguntas frecuentes

¿CI/CD significa que todo cambio se publica automáticamente?

No. Puedes usar integración continua y mantener un paso de aprobación para desplegar. El nivel de automatización depende del proceso.

¿Un secret puede compartirse con cualquier job?

No conviene. Limita su disponibilidad a los trabajos que lo necesitan y revisa el origen del código que ejecutarán.

¿Por qué usar npm ci?

Instala según un lockfile compatible y favorece repetibilidad. No sustituye revisar dependencias, mantenerlas ni escribir pruebas útiles.

En pocas palabras

Un pipeline útil comprueba cambios de forma repetible y limita qué puede hacer cada ejecución. Pasar tests no autoriza automáticamente publicar una aplicación o modificar producción.

Conclusión

Comienza con integración continua, prueba fallos deliberados y confirma que el workflow los detecta. Añade despliegue únicamente cuando exista una revisión, un destino claro y una forma de volver atrás.

Para continuar, revisa Docker: qué es y cómo usarlo para ejecutar contenedores y Cómo instalar Docker en Ubuntu 24.04: guía práctica paso a paso.

Fuentes y documentación

Documentación de docs.github.com.

Documentación de docs.github.com.