Fins ara has treballat sol, executant apply des del teu ordinador. Però en una empresa, la infraestructura la gestiona un equip, i aplicar canvis al núvol de producció «a mà» és perillós. En aquest subcapítol tanquem el capítol (i la Part III) veient com els equips professionals gestionen Terraform de manera segura i col·laborativa: mitjançant Pull Requests i revisió de plans.

Imagina cinc persones modificant la mateixa infraestructura des dels seus portàtils. Sorgeixen problemes immediats:

• Qui va aplicar aquell canvi que va trencar producció? Ningú ho sap.
• Dues persones fan apply alhora i corrompen l’estat (recorda el subcapítol 11.3).
• Algú aplica un canvi sense que ningú el revisi, i esborra una base de dades.
• No hi ha registre de què va canviar, quan ni per què.

La solució és tractar la infraestructura igual que el codi d’una aplicació: amb Git, branques, Pull Requests i revisió entre companys.

El flux professional (sovint anomenat GitOps) funciona així:

La idea central: ningú aplica canvis des del seu portàtil. Tot passa per un Pull Request revisat, i és un sistema automàtic (CI/CD) qui executa apply.

La peça més valuosa d’aquest flux és el pas 5: revisar el pla. Quan obres un Pull Request, una eina automàtica (ho veurem al Capítol 22) executa terraform plan i publica el resultat com a comentari al PR. Així, abans d’aprovar, tothom veu exactament què passarà:

El revisor mira aquest pla i es pregunta:

• Crea el que l’autor diu que volia crear?
• Hi ha algun destroy inesperat? (Una senyal d’alarma!)
• Toca recursos crítics com bases de dades?

Aquesta és la xarxa de seguretat definitiva. El pla al PR converteix cada canvi d’infraestructura en quelcom visible i revisable. Si algú proposa, sense voler, un canvi que destruiria la base de dades de producció, el pla ho mostrarà amb un - destroy, i el revisor ho aturarà abans que passi. Recorda el que vam veure al subcapítol 11.4: llegir el pla amb atenció evita desastres; aquí aquest hàbit esdevé un procés d’equip obligatori.

Imagina que en una empresa de comerç electrònic, l’Ana necessita afegir un segon servidor per suportar més trànsit. En lloc d’entrar en producció i crear-lo a mà:

1. Ana crea una branca feature/segon-servidor i afegeix el recurs al codi.
2. Obre un Pull Request titulat «Afegir segon servidor web per al Black Friday».
3. El sistema de CI publica el pla: Plan: 1 to add, 0 to change, 0 to destroy.
4. Carlos, el seu company, revisa el pla. Viu que només s’afegeix una instància, res més. Tot correcte.
5. En Carlos aprova el PR. Es fusiona.
6. El CI executa apply automàticament. El nou servidor apareix.

Resultat: hi ha un registre permanent (el PR) de què es va canviar, qui ho va proposar, qui ho va revisar i per què. Si alguna cosa falla, només cal revertir el PR. Traçabilitat total.

Resumim les regles d’or, que recullen molt del que hem après a la Part III:

• En equip, mai s’aplica Terraform «a mà» des del portàtil: tot passa per Git, Pull Requests i CI/CD.
• El flux GitOps: branca → canvies el codi → PR → el CI publica el pla → un company el revisa → s’aprova i es fusiona → el CI fa apply.
• El pas estrella és revisar el pla al PR: fa cada canvi visible i permet aturar operacions perilloses (com un destroy inesperat) abans que passin.
• Aquest flux dona traçabilitat total: qui va canviar què, quan, per què i qui ho va aprovar.
• Es basa en el que hem après: estat remot amb locking, fmt/validate, i l’hàbit de llegir el pla amb atenció.

Enhorabona! Has tancat la Part III i tens les bases sòlides de Terraform: llenguatge, providers, estat, comandes, una infraestructura real construïda i el flux de treball en equip. A la Part IV farem un salt: arquitectures més avançades a AWS, començant pel balanceig de càrrega i l’autoescalat (Capítol 13).