# Cómo crear pipelines CI/CD con GitHub Actions

**Categoría:** DevOps y cloud · **Nivel:** Intermedio · **Lectura:** 11 min
**Publicada:** 2026-07-28 · **Actualizada:** 2026-07-28 · **Autoría:** Underc0de
**Versión HTML (canónica):** https://underc0de.org/guias/devops-cloud/como-crear-pipelines-ci-cd-con-github-actions/

## Respuesta rápida

Un **pipeline de CI/CD** es una cadena automática de pasos que lleva un cambio de código desde que se sube hasta que llega a producción, sin intervención manual. **CI** (integración continua) es la primera mitad: con cada cambio, el sistema **construye** la aplicación y **corre las pruebas**, para detectar de inmediato lo que rompe. **CD** es la segunda: entrega continua (dejar el cambio listo para desplegar con un clic) o despliegue continuo (llevarlo a producción de forma totalmente automática). **GitHub Actions** es una plataforma integrada en GitHub que ejecuta esos pasos: se describe un *workflow* en un archivo YAML dentro del repositorio, se define qué lo **dispara** (un push, una pull request), y GitHub corre los *jobs* en máquinas temporales. La regla de oro: si una etapa falla —la compilación, una prueba—, el pipeline **se detiene** y el cambio no avanza. Y los **secretos** que el despliegue necesita (claves, tokens) van en el almacén de secretos cifrados, nunca en el YAML. Esta guía cubre el pipeline completo; la etapa de pruebas en detalle está en la [guía de Testing](../../testing/pruebas-automaticas-con-github-actions/index.md).

## CI y CD: qué es cada cosa

Las siglas CI/CD juntan tres ideas que conviene separar:

- **CI, integración continua.** Cada vez que alguien sube un cambio, se integra con el resto y se comprueba automáticamente: se **construye** la aplicación y se **corren las pruebas**. El objetivo es detectar problemas en minutos, no días, y evitar que el código de varias personas «se pelee» al juntarse.
- **CD como entrega continua.** Además de probar, el pipeline deja el cambio **listo para desplegar** en cualquier momento, con una aprobación manual final.
- **CD como despliegue continuo.** Un paso más: si todo pasa, el cambio va a producción **de forma totalmente automática**, sin intervención.

> **Por qué importa**
>
> Antes de CI/CD, integrar y desplegar eran eventos raros, manuales y temidos: se juntaba meses de trabajo y se rezaba. Con CI/CD, cada cambio es pequeño, se prueba solo y se despliega seguido, así los errores se descubren cuando todavía son fáciles de arreglar. Es la práctica que hace posible entregar software con frecuencia y sin dramas.

## Las etapas del pipeline

Un pipeline típico encadena cuatro etapas, y la clave es que cada una es una **compuerta**: solo se pasa a la siguiente si la anterior terminó bien.

1. **Construir.** Tomar el código y armar la aplicación: compilarla, o construir la [imagen de contenedor](../docker-desde-cero-imagenes-contenedores-y-volumenes/index.md). Si no compila, todo se detiene acá.
2. **Probar.** Correr las [pruebas automáticas](../../testing/introduccion-al-testing/index.md) sobre lo construido. Si una falla, el cambio no avanza. El detalle de esta etapa está en la [guía específica de Testing](../../testing/pruebas-automaticas-con-github-actions/index.md).
3. **Empaquetar y publicar.** Guardar el resultado ya probado como un *artefacto* versionado (una imagen de contenedor) en un registro.
4. **Desplegar.** Llevar ese artefacto al entorno: primero a uno de pruebas (*staging*), luego a producción, con una [estrategia que evite cortes](../despliegues-blue-green-canary-y-rolling-update/index.md).

## Cómo lo ejecuta GitHub Actions

**GitHub Actions** es la plataforma de automatización integrada en GitHub. Se describe un **workflow** en un archivo YAML dentro de `.github/workflows/`, y GitHub lo ejecuta cuando ocurre el evento que lo dispara.

```yaml
name: CI/CD
# Qué dispara el pipeline: un push a la rama principal
on:
  push:
    branches: [main]
jobs:
  build-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run build   # construir
      - run: npm test        # probar: si falla, se detiene todo
```

Los conceptos: un **workflow** es el pipeline entero; se compone de **jobs** (trabajos), que corren en máquinas temporales y limpias que GitHub provee; cada job tiene **steps** (pasos), que ejecutan comandos o *actions* reutilizables. Como la máquina se crea nueva cada vez, el pipeline es reproducible: no arrastra el estado de ejecuciones anteriores.

## Secretos y entornos

Para desplegar, el pipeline necesita credenciales: la clave del servidor, el token del registro, la contraseña de la base de datos. Y acá la regla es absoluta:

> **Atención**
>
> El YAML del pipeline se versiona en el repositorio, así que cualquier secreto escrito ahí queda expuesto a todo el que vea el código. Las credenciales van en el **almacén de secretos cifrados** de GitHub, y el workflow las lee en tiempo de ejecución sin que su valor aparezca nunca en el código ni en los registros. Este tema es tan central que tiene su propia guía: [cómo administrar secretos en pipelines y aplicaciones](../como-administrar-secretos-en-pipelines-y-aplicaciones/index.md).

Además, conviene separar **entornos** (pruebas y producción) con credenciales y aprobaciones distintas, de modo que un despliegue a producción pueda requerir la confirmación de una persona. Y un principio que no hay que perder de vista: un pipeline **solo es tan bueno como sus pruebas**. Automatizar el despliegue con [pruebas débiles](../../testing/introduccion-al-testing/index.md) no hace más que llevar los errores a producción más rápido.

## Errores frecuentes

- **Secretos en el archivo del workflow.** Se versiona; van en el almacén de secretos cifrados.
- **Un pipeline que no frena ante fallos.** Si una prueba falla y el cambio avanza igual, el pipeline no protege nada.
- **Automatizar despliegues con pruebas pobres.** Solo acelera la llegada de errores a producción.
- **Pipelines lentísimos.** Si tarda una hora, la gente lo evita; cachear dependencias y paralelizar jobs.
- **Desplegar directo a producción sin staging.** Un entorno de pruebas intermedio atrapa problemas antes.
- **Depender del estado de la máquina.** Cada ejecución debe partir limpia; no asumir nada de corridas anteriores.
- **Confundir CI con CD.** Construir y probar no es lo mismo que desplegar; conviene tener claras las etapas.

## Preguntas frecuentes

**¿Qué es un pipeline de CI/CD?**
Es una cadena automática de pasos que lleva un cambio de código desde que se sube al repositorio hasta que llega a producción, idealmente sin intervención manual. Las siglas reúnen tres ideas. La integración continua, o CI, hace que con cada cambio el sistema construya la aplicación y ejecute las pruebas automáticas, para detectar de inmediato lo que se rompe y evitar que el trabajo de varias personas entre en conflicto al juntarse. La entrega continua, una de las lecturas de CD, agrega que el cambio queda siempre listo para desplegarse con una aprobación final. El despliegue continuo, la otra lectura de CD, va un paso más allá y lleva el cambio a producción de forma totalmente automática cuando todo pasa. El valor de fondo es transformar la integración y el despliegue, que antes eran eventos raros, manuales y temidos, en algo frecuente, pequeño y rutinario, de modo que los errores se descubran cuando todavía son baratos de corregir.

**¿Cuál es la diferencia entre CI y CD?**
CI, la integración continua, es la primera mitad del proceso y se ocupa de la calidad del código: cada vez que alguien sube un cambio, el sistema lo integra con el resto, construye la aplicación y corre las pruebas automáticas, con el objetivo de encontrar problemas en minutos en lugar de días. CD abarca la segunda mitad y tiene dos variantes que conviene distinguir. La entrega continua deja el cambio ya construido y probado listo para desplegarse en cualquier momento, pero reserva la decisión final del despliegue a una aprobación manual. El despliegue continuo elimina también ese paso manual y lleva el cambio a producción automáticamente en cuanto supera todas las etapas. En resumen, CI responde a la pregunta de si el cambio es correcto, y CD responde a cómo y cuándo ese cambio correcto llega a los usuarios. Muchas organizaciones adoptan CI completo y una forma de entrega continua, dejando la variante totalmente automática para cuando la confianza en las pruebas es muy alta.

**¿Qué es GitHub Actions y cómo funciona?**
GitHub Actions es la plataforma de automatización integrada en GitHub que permite ejecutar pipelines directamente desde el repositorio, sin necesidad de un servidor de integración aparte. Funciona a partir de archivos de configuración llamados workflows, escritos en formato YAML y guardados dentro de una carpeta específica del repositorio. Cada workflow define qué evento lo dispara —por ejemplo un push a una rama, la apertura de una pull request o una programación horaria— y una serie de trabajos, o jobs, que se ejecutan en máquinas temporales y limpias que GitHub provee. Cada job se compone de pasos, que ejecutan comandos concretos o acciones reutilizables ya empaquetadas por la comunidad. Como la máquina se crea nueva en cada ejecución, el proceso es reproducible y no arrastra el estado de corridas anteriores. Gracias a esta integración, todo el ciclo de construir, probar y desplegar queda descrito junto al código y se dispara solo con cada cambio.

**¿En qué se diferencia esta guía de la de pruebas con GitHub Actions?**
La guía de pruebas automáticas con GitHub Actions se concentra específicamente en la etapa de testing: cómo hacer que las pruebas de un proyecto corran solas con cada cambio, cómo se configura ese flujo, cómo frena lo que rompe y cómo se publican los resultados. Esta guía, en cambio, aborda el pipeline completo de CI/CD, del cual las pruebas son una sola etapa. Aquí se explica la cadena entera: construir la aplicación, probarla, empaquetarla como un artefacto versionado y desplegarla a los distintos entornos hasta producción, además de cómo se disparan los flujos, cómo se encadenan las etapas como compuertas y dónde se guardan los secretos necesarios para desplegar. La recomendación es usar esta guía para entender y armar el pipeline de punta a punta, y la guía de Testing para profundizar en la etapa de pruebas, que es el corazón de la parte de integración continua y que aquí se referencia sin repetir en detalle.

**¿Dónde guardo las credenciales que el pipeline usa para desplegar?**
En el almacén de secretos cifrados que ofrece la plataforma de CI/CD, nunca escritas en el archivo del workflow. La razón es que ese archivo se versiona en el repositorio y se comparte con todo el equipo, de modo que cualquier credencial escrita en él —la clave del servidor, el token del registro de imágenes, la contraseña de la base de datos— quedaría expuesta a quien tenga acceso al código, y una filtración así es muy difícil de revertir. En GitHub Actions, los secretos se cargan en una sección específica del repositorio o del entorno, quedan cifrados, y el workflow los lee en tiempo de ejecución sin que su valor aparezca nunca ni en el código ni en los registros de la ejecución. Conviene además separar entornos, con credenciales distintas para pruebas y para producción, y proteger el despliegue a producción con una aprobación manual. Este tema es lo bastante importante como para tener su propia guía dedicada a la administración de secretos en pipelines y aplicaciones.

**¿Un pipeline garantiza que no lleguen errores a producción?**
No por sí mismo: un pipeline es solo tan bueno como las pruebas que ejecuta. La automatización garantiza que cada cambio pase por las mismas etapas de forma consistente y que se detenga si alguna falla, lo cual es muy valioso, pero no puede detectar problemas que las pruebas no cubren. Si las pruebas son escasas o superficiales, el pipeline las pasará sin objeciones y desplegará el error a producción, solo que más rápido y con más confianza de la merecida. Por eso, invertir en un buen pipeline sin invertir en buenas pruebas da una falsa sensación de seguridad. Lo correcto es entender el pipeline como el mecanismo que ejecuta y hace cumplir tus verificaciones de forma disciplinada, y poner el esfuerzo en que esas verificaciones —pruebas unitarias, de integración y las que correspondan— cubran de verdad lo que importa. Sumar además un entorno de pruebas intermedio antes de producción y una estrategia de despliegue que permita revertir rápido completa la red de seguridad.

## Fuentes

Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 28 de julio de 2026.

### Aportes de la comunidad Underc0de

1. **Underc0de, foro.** [Sección Programación](https://underc0de.org/foro/programacion/). Automatización de construcción, pruebas y entrega.
2. **Underc0de, foro.** [Sección GNU/Linux](https://underc0de.org/foro/gnu-linux/). Despliegue en servidores y entornos.

### Documentación oficial

1. **GitHub.** [Documentación de GitHub Actions](https://docs.github.com/es/actions), en español. La referencia de la plataforma usada en la guía.
2. **GitHub.** [Sobre los workflows](https://docs.github.com/es/actions/using-workflows/about-workflows). Estructura, disparadores y trabajos.
3. **GitHub.** [Secretos cifrados](https://docs.github.com/es/actions/security-guides/encrypted-secrets). Cómo entregar credenciales al pipeline de forma segura.
4. **Martin Fowler.** [Continuous Integration](https://martinfowler.com/articles/continuousIntegration.html). El artículo de referencia sobre el concepto.

## Guías relacionadas

- [Ejecutar pruebas con GitHub Actions](../../testing/pruebas-automaticas-con-github-actions/index.md)
- [Docker desde cero](../docker-desde-cero-imagenes-contenedores-y-volumenes/index.md)
- [Estrategias de despliegue](../despliegues-blue-green-canary-y-rolling-update/index.md)
- [Administrar secretos](../como-administrar-secretos-en-pipelines-y-aplicaciones/index.md)
- [Índice de DevOps y cloud](../index.md)