Cerramos la Parte V juntando todo lo aprendido en un flujo automático completo: un pipeline de CI/CD para Terraform. Hemos visto las piezas sueltas (revisión de planes en el subcapítulo 12.5, testing en el Capítulo 21); ahora las unimos en una «cadena de montaje» automática que va desde que escribes código hasta que se despliega. Lo haremos con GitHub Actions, una de las herramientas de CI/CD más populares.

Un pipeline (tubería) de CI/CD es una secuencia automática de pasos que se ejecuta cuando cambias el código. Recuerda los dos conceptos:

• CI (Integración Continua): comprobar automáticamente que el código es correcto (lo vimos en el subcapítulo 21.1: fmt, validate, seguridad...).
• CD (Continuous Delivery/Deployment, Entrega/Despliegue Continuo): llevar automáticamente el código aprobado a su destino (en nuestro caso, aplicar la infraestructura).

Analogía: un pipeline es como una cadena de montaje de una fábrica. El producto (tu código) avanza por estaciones: en una se inspecciona, en otra se prueba, en otra se ensambla, y al final sale terminado. Cada estación hace su parte automáticamente, y si algo falla en una, la cadena se detiene antes de que el defecto avance.

GitHub Actions es el sistema de CI/CD integrado en GitHub. Te permite definir pipelines en un archivo dentro de tu repositorio, y se ejecutan automáticamente ante eventos como abrir un Pull Request o fusionar a la rama principal. Hay alternativas equivalentes (GitLab CI, Jenkins, CircleCI...), pero GitHub Actions es muy popular y fácil de empezar; los conceptos son los mismos en todas.

El pipeline se define en un archivo YAML dentro de .github/workflows/:

Un pipeline básico de Terraform tiene tres etapas, que recogen todo lo que hemos visto:

«Lint» significa revisar el código en busca de problemas. Aquí se ejecutan las comprobaciones baratas del Capítulo 21: terraform fmt -check, terraform validate y el análisis de seguridad (Checkov/tfsec). Si algo falla, el pipeline se detiene: no tiene sentido seguir con código mal formateado, inválido o inseguro.

Se ejecuta terraform plan (subcapítulo 11.4) y su resultado se publica en el Pull Request para que un compañero lo revise (exactamente el flujo del subcapítulo 12.5). Esta es la etapa clave de seguridad: nadie aplica nada sin que antes se vea y apruebe qué va a cambiar.

Una vez el PR se aprueba y fusiona a la rama principal, el pipeline ejecuta terraform apply automáticamente, aplicando los cambios revisados. Como ya se revisó el plan, este apply es seguro y controlado.

Un pipeline simplificado en GitHub Actions tendría esta forma (no necesitas memorizar la sintaxis, solo entender la estructura):

Fíjate en los disparadores (on):

• En un Pull Request (pull_request): se ejecutan el lint y el plan (se revisa, no se aplica).
• Al fusionar a main (push a main): se ejecuta el apply (ya revisado).

Esto implementa exactamente el flujo de equipo del subcapítulo 12.5, pero automatizado.

Recuerda el principio del subcapítulo 12.5: en equipo, nadie aplica Terraform a mano. El pipeline lo hace cumplir de forma automática:

• Los cambios pasan siempre por las comprobaciones (no se pueden saltar).
• El plan siempre se revisa antes de aplicar.
• El apply lo ejecuta el sistema, de forma consistente y registrada, no una persona desde su máquina (con su configuración particular y posibilidad de error).

Para que el pipeline pueda aplicar cambios en AWS, necesita credenciales. ⚠️ Nunca se escriben en el archivo del pipeline (sería como dejar las llaves puestas). Se usan los secretos de GitHub Actions (un almacén seguro) o, mejor aún, una conexión segura sin claves permanentes (OIDC), aplicando el mínimo privilegio (Capítulo 7): el pipeline solo debe tener permisos para lo que necesita gestionar. Profundizaremos en seguridad de credenciales en el Capítulo 23.

• Un pipeline de CI/CD es una secuencia automática de pasos que se ejecuta al cambiar el código: CI comprueba que es correcto, CD lo despliega. Como una cadena de montaje.
• GitHub Actions define pipelines en un archivo YAML en .github/workflows/; hay alternativas equivalentes (GitLab CI, Jenkins...), con los mismos conceptos.
• El pipeline básico de Terraform tiene tres etapas: Lint (fmt, validate, seguridad), Plan (se publica en el PR y se revisa) y Apply (tras aprobar y fusionar).
• Los disparadores: en un PR se hace lint + plan (revisión); al fusionar a main se hace el apply (ya revisado). Es el flujo del subcapítulo 12.5, automatizado.
• La gran ventaja: nadie aplica desde su portátil; todo pasa por la cadena automática, de forma consistente, segura y trazable.
• ⚠️ Las credenciales del pipeline van en secretos (nunca en el archivo) y con mínimo privilegio.

En el siguiente subcapítulo veremos una herramienta especializada en este flujo para Terraform: Atlantis, que lleva el GitOps de la infraestructura a otro nivel.