CI/CD: pipeline de despliegue con GitHub Actions

Las cuatro etapas del pipeline

Todo despliegue automatizado, por complejo que parezca, se descompone en la misma secuencia de cuatro etapas. Entenderlas como pasos con un orden fijo —cada uno depende del anterior— es la clave para leer y escribir cualquier pipeline.

El orden no es decorativo: es una cadena de confianza. Se instala antes de probar porque las pruebas necesitan el árbol de dependencias; se prueba antes de construir porque no tiene sentido gastar tiempo compilando código roto; se construye antes de desplegar porque solo se publica lo que existe y funciona. Cada etapa es una compuerta, y la última —deploy— solo se abre si todas las anteriores dieron luz verde. Ese encadenamiento es lo que convierte un montón de comandos en una garantía.

Vale la pena notar que estas cuatro etapas son las mismas que ya ejecutas a mano en tu máquina —instalas, pruebas, construyes, subes—. El pipeline no inventa pasos nuevos: toma el ritual que ya conoces y lo mueve a un entorno limpio y automático donde nadie puede saltarse ninguno ni ejecutarlos en el orden equivocado. Por eso migrar a CI casi nunca exige reescribir nada; exige, más bien, escribir explícitamente lo que antes vivía en tu memoria y en tu costumbre.

Puesto en negativo, cada compuerta existe para atrapar un tipo concreto de error antes de que llegue a producción:

• Install atrapa el árbol de dependencias roto: un paquete que falta o una versión que no resuelve.
• Test atrapa la regresión: el cambio que rompe algo que antes funcionaba, sin que nadie lo note al escribirlo.
• Build atrapa el fallo de compilación: un import muerto, un tipo inválido, un schema de contenido que no valida.
• Deploy no atrapa, veda: si cualquier etapa anterior falla, la publicación sencillamente no ocurre.

Un workflow de GitHub Actions

En GitHub Actions, el pipeline vive en un fichero YAML dentro de .github/workflows. Su estructura es una jerarquía sencilla: un disparador que dice cuándo corre, y una lista de pasos que dicen qué hace.

name: deployon:  push:    branches: [main]  pull_request:jobs:  build:    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v4      - uses: actions/setup-node@v4        with:          node-version: 22          cache: npm      - run: npm ci      - run: npm run test --if-present      - run: npm run build      - uses: actions/upload-artifact@v4        with:          name: dist          path: dist

Léelo de arriba abajo y verás las cuatro etapas. El bloque on define los disparadores: cada push a main y cada pull request. Dentro del job, checkout trae el código y setup-node prepara el entorno; luego vienen las etapas en orden —npm ci instala, npm run test prueba, npm run build construye— y el último paso guarda dist/ como artefacto. El detalle de --if-present es cortesía profesional: no rompe el pipeline si aún no has escrito pruebas, pero deja el hueco listo para cuando las tengas. Fíjate en que cada uses apunta a una versión fija —@v4—: como con las dependencias, fijar la versión de las acciones es lo que hace el pipeline reproducible en el tiempo.

La anatomía del fichero se reduce a un puñado de piezas que se repiten en cualquier workflow:

• on: los eventos que disparan la corrida —push a una rama, pull request, o una programación horaria—.
• jobs: los trabajos, que corren en paralelo salvo que declares dependencias entre ellos.
• runs-on: la máquina virtual efímera donde todo ocurre, creada de cero en cada corrida.
• steps: los pasos en orden, donde uses invoca una acción reutilizable y run ejecuta un comando de shell.

Cache de dependencias y previews por PR

Un pipeline correcto puede ser lento, y la lentitud tiene un coste: cada minuto de espera es fricción que desincentiva desplegar a menudo. Dos técnicas lo transforman de peaje a fluido.

La primera es el cacheado de dependencias. Instalar desde cero en cada corrida descarga los mismos paquetes una y otra vez; con cache: npm en setup-node, GitHub guarda el almacén de descargas entre corridas y lo restaura, de modo que npm ci reutiliza lo que ya existía en lugar de bajarlo de internet. En un proyecto Astro con muchas dependencias, esto recorta una fracción notable del tiempo total sin ningún riesgo, porque el lockfile sigue siendo la fuente de verdad.

La segunda son las previews por pull request. En lugar de fusionar a ciegas y ver el resultado en producción, el pipeline despliega cada PR a una URL temporal y aislada. Revisas el cambio funcionando, no solo el diff; el equipo lo prueba en vivo; y solo cuando convence se fusiona. Las plataformas Git-driven ofrecen estas previews casi de fábrica, y son la diferencia entre revisar código y revisar la experiencia real.

La preview cambia la naturaleza de la revisión. Un diff te dice qué líneas cambiaron; una preview te dice qué le pasa al usuario. Un cambio de estilos, una animación, un ajuste de maquetación son casi imposibles de juzgar leyendo código, pero obvios de aprobar o rechazar en una URL viva. Cuando cada PR trae su propio sitio desplegado, la conversación deja de ser sobre la implementación y pasa a ser sobre el resultado, que es donde de verdad se decide si un cambio entra.

# El disparo por pull_request es lo que habilita las previews:on:  pull_request:# cada PR corre el pipeline y la plataforma publica una URL temporal

Reunidas, cache y previews cambian la economía del despliegue. La cache recorta el tiempo de cada corrida, así que publicar deja de ser una espera; las previews eliminan el riesgo de revisar a ciegas, así que fusionar deja de dar miedo. Un pipeline lento y opaco desincentiva desplegar a menudo, y un equipo que despliega poco acumula cambios grandes y arriesgados. Uno rápido y transparente invita a lo contrario: cambios pequeños, frecuentes y fáciles de revertir, que es la forma más segura de hacer evolucionar un sitio en producción.