Hasta ahora has trabajado solo, ejecutando apply desde tu ordenador. Pero en una empresa, la infraestructura la gestiona un equipo, y aplicar cambios a la nube de producción «a mano» es peligroso. En este subcapítulo cerramos el capítulo (y la Parte III) viendo cómo los equipos profesionales gestionan Terraform de forma segura y colaborativa: mediante Pull Requests y revisión de planes.

Imagina cinco personas modificando la misma infraestructura desde sus portátiles. Surgen problemas inmediatos:

• ¿Quién aplicó ese cambio que rompió producción? Nadie lo sabe.
• Dos personas hacen apply a la vez y corrompen el estado (recuerda el subcapítulo 11.3).
• Alguien aplica un cambio sin que nadie lo revise, y borra una base de datos.
• No hay registro de qué cambió, cuándo ni por qué.

La solución es tratar la infraestructura igual que el código de una aplicación: con Git, ramas, Pull Requests y revisión entre compañeros.

El flujo profesional (a menudo llamado GitOps) funciona así:

La idea central: nadie aplica cambios desde su portátil. Todo pasa por un Pull Request revisado, y es un sistema automático (CI/CD) quien ejecuta apply.

La pieza más valiosa de este flujo es el paso 5: revisar el plan. Cuando abres un Pull Request, una herramienta automática (lo veremos en el Capítulo 22) ejecuta terraform plan y publica el resultado como comentario en el PR. Así, antes de aprobar, todos ven exactamente qué va a pasar:

El revisor mira ese plan y se pregunta:

• ¿Crea lo que el autor dice que quería crear?
• ¿Hay algún destroy inesperado? (¡Una señal de alarma!)
• ¿Toca recursos críticos como bases de datos?

Esta es la red de seguridad definitiva. El plan en el PR convierte cada cambio de infraestructura en algo visible y revisable. Si alguien propone, sin querer, un cambio que destruiría la base de datos de producción, el plan lo mostrará con un - destroy, y el revisor lo frenará antes de que ocurra. Recuerda lo que vimos en el subcapítulo 11.4: leer el plan con atención evita desastres; aquí ese hábito se vuelve un proceso de equipo obligatorio.

Imagina que en una empresa de comercio electrónico, Ana necesita añadir un segundo servidor para soportar más tráfico. En lugar de entrar en producción y crearlo a mano:

1. Ana crea una rama feature/segundo-servidor y añade el recurso en el código.
2. Abre un Pull Request titulado «Añadir segundo servidor web para el Black Friday».
3. El sistema de CI publica el plan: Plan: 1 to add, 0 to change, 0 to destroy.
4. Carlos, su compañero, revisa el plan. Ve que solo se añade una instancia, nada más. Todo correcto.
5. Carlos aprueba el PR. Se fusiona.
6. El CI ejecuta apply automáticamente. El servidor nuevo aparece.

Resultado: hay un registro permanente (el PR) de qué se cambió, quién lo propuso, quién lo revisó y por qué. Si algo falla, basta con revertir el PR. Trazabilidad total.

Resumimos las reglas de oro, que recogen mucho de lo aprendido en la Parte III:

• En equipo, nunca se aplica Terraform «a mano» desde el portátil: todo pasa por Git, Pull Requests y CI/CD.
• El flujo GitOps: rama → cambias el código → PR → el CI publica el plan → un compañero lo revisa → se aprueba y fusiona → el CI hace apply.
• El paso estrella es revisar el plan en el PR: hace cada cambio visible y permite frenar operaciones peligrosas (como un destroy inesperado) antes de que ocurran.
• Este flujo da trazabilidad total: quién cambió qué, cuándo, por qué y quién lo aprobó.
• Se apoya en lo aprendido: estado remoto con locking, fmt/validate, y el hábito de leer el plan con atención.

¡Enhorabuena! Has cerrado la Parte III y tienes las bases sólidas de Terraform: lenguaje, providers, estado, comandos, una infraestructura real construida y el flujo de trabajo en equipo. En la Parte IV daremos un salto: arquitecturas más avanzadas en AWS, empezando por el balanceo de carga y el autoescalado (Capítulo 13).