Automatizar tu infraestructura con CI/CD de Terraform y GitHub Actions te permite que cada commit en la rama principal actualice tus recursos en Azure sin intervención manual. Esta guía está pensada para desarrolladores y equipos DevOps que ya manejan Terraform y quieren llevar su flujo de trabajo al siguiente nivel.

La idea es simple: cada vez que alguien de tu equipo hace un push a main, una GitHub Action se encarga de validar y planificar los cambios en tu infraestructura. Y aquí viene lo interesante: el proceso es mucho más accesible de lo que parece.

¿Cómo preparo el repositorio y el archivo Terraform base?

Lo primero es organizar tu proyecto. Crea una carpeta dedicada (por ejemplo, CI-CD) dentro de tu repositorio para mantener el ejemplo aislado [01:05].

Dentro de esa carpeta crea un archivo main.tf con un script base. En el ejemplo se incluyen cuatro elementos clave:

• El proveedor de Azure.
• Un grupo de recursos.
• Una cuenta de almacenamiento llamada Continuous Deployment.
• Un contenedor con un nombre identificable.

Idealmente reemplazarías estos valores por variables, pero para enfocarte en la GitHub Action puedes dejarlos hardcoded por ahora.

¿Cómo creo las credenciales de Azure para GitHub Actions?

Necesitas un Service Principal de Azure Active Directory que actúe como puente entre GitHub y tu suscripción. Desde la terminal ejecutas el comando az ad sp create-for-rbac con permisos de Role Based Access Control a nivel contributor sobre tu suscripción [02:30].

¿Qué es un Service Principal en Azure? Es una identidad que usan herramientas externas para acceder a tu suscripción sin requerir usuario y contraseña. Le asignas un rol (como contributor) y obtienes credenciales en formato JSON.

El resultado es un JSON con cuatro datos críticos: appId, password, subscription y tenant. Esos cuatro valores son los que vas a guardar como secretos en GitHub.

Un detalle importante: Terraform usa por debajo la CLI de Azure que instalaste desde la primera clase, por eso esta herramienta ya está disponible en tu sistema.

¿Cómo configuro los secretos en GitHub para Terraform?

En tu repositorio ve a Settings > Secrets and variables > Actions y crea cuatro secretos de repositorio en mayúsculas [04:15]:

• CLIENT_ID: corresponde al campo appId del JSON.
• CLIENT_SECRET: corresponde al campo password.
• SUBSCRIPTION_ID: el ID de suscripción que ya usas en Terraform.
• TENANT_ID: el campo tenant del JSON.

Usar mayúsculas no es obligatorio, pero hace el flujo más cómodo de leer y mantener. Con estos cuatro secretos, cualquier acción dentro del repositorio podrá autenticarse contra Azure como contributor.

¿Cómo escribo el workflow YAML para Terraform?

Desde la pestaña Actions selecciona set up a workflow yourself en lugar de las plantillas sugeridas. Renombra el archivo a terraform-deploy.yml dentro de .github/workflows/.

Un detalle que puede costarte tiempo: la carpeta debe llamarse workflows (con S al final). Si la nombras workflow, GitHub no detecta tu acción [09:40].

¿Qué triggers y variables de ambiente necesito?

El workflow debe ejecutarse cuando hay un push o pull request cerrado sobre la rama main. Después defines un job llamado terraform que se ejecuta sobre la última versión de Ubuntu.

Las variables de ambiente se mapean directamente desde los secretos del repositorio:

• ARM_CLIENT_ID
• ARM_CLIENT_SECRET
• ARM_SUBSCRIPTION_ID
• ARM_TENANT_ID

Con esas variables Terraform se autentica contra tu cuenta de Azure de forma transparente.

¿Qué pasos debe ejecutar el job de Terraform?

Dentro del job configuras la ruta de trabajo apuntando a tu carpeta CI-CD y luego encadenas los pasos clásicos:

1. Checkout del código del repositorio.
2. Setup de la action oficial de Terraform.
3. terraform init para inicializar el proveedor.
4. terraform validate con la opción -no-color para verificar la sintaxis.
5. terraform plan -out plan.out para previsualizar cambios.

¿Para qué sirve terraform validate en CI/CD? Detecta errores de sintaxis y configuración antes de ejecutar el plan. Es el mismo comando que usas localmente, pero ahora protege tu pipeline productivo.

La indentación en YAML es fundamental, igual que en Python. Un espacio mal puesto y el workflow falla.

¿Cómo verifico que la GitHub Action funcionó?

Después del commit y push, ve a la pestaña Actions del repositorio. Si todo está bien configurado, verás una palomita verde junto al nombre del flujo.

Al entrar al detalle puedes inspeccionar cada paso:

• Terraform init muestra el mismo output que en tu máquina local.
• Terraform validate confirma que la configuración es válida.
• Terraform plan lista los recursos a crear: la cuenta de almacenamiento y el contenedor definidos.

Con todos los pasos en verde, tu etapa de integración continua queda lista. El siguiente paso natural es complementar este flujo con la fase de despliegue continuo, donde aplicarás los cambios automáticamente sobre Azure.

¿Ya tienes tu primer workflow de Terraform corriendo? Cuéntanos qué error te tomó más tiempo resolver.