Tanquem la Part V ajuntant tot el que hem après en un flux automàtic complet: un pipeline de CI/CD per a Terraform. Hem vist les peces soltes (revisió de plans al subcapítol 12.5, testing al Capítol 21); ara les unim en una «cadena de muntatge» automàtica que va des que escrius codi fins que es desplega. Ho farem amb GitHub Actions, una de les eines de CI/CD més populars.

Un pipeline (tub) de CI/CD és una seqüència automàtica de passos que s’executa quan canvies el codi. Recorda els dos conceptes:

• CI (Integració Contínua): comprovar automàticament que el codi és correcte (ho vam veure al subcapítol 21.1: fmt, validate, seguretat...).
• CD (Continuous Delivery/Deployment, Entrega/Desplegament Continu): portar automàticament el codi aprovat al seu destí (en el nostre cas, aplicar la infraestructura).

Analogia: un pipeline és com una cadena de muntatge d’una fàbrica. El producte (el teu codi) avança per estacions: en una s’inspecciona, en una altra es prova, en una altra s’assembla, i al final surt acabat. Cada estació fa la seva part automàticament, i si alguna cosa falla en una, la cadena s’atura abans que el defecte avanci.

GitHub Actions és el sistema de CI/CD integrat a GitHub. Et permet definir pipelines en un fitxer dins del teu repositori, i s’executen automàticament davant d’esdeveniments com obrir un Pull Request o fusionar a la branca principal. Hi ha alternatives equivalents (GitLab CI, Jenkins, CircleCI...), però GitHub Actions és molt popular i fàcil de començar; els conceptes són els mateixos a totes.

El pipeline es defineix en un fitxer YAML dins de .github/workflows/:

Un pipeline bàsic de Terraform té tres etapes, que recullen tot el que hem vist:

«Lint» vol dir revisar el codi a la recerca de problemes. Aquí s’executen les comprovacions barates del Capítol 21: terraform fmt -check, terraform validate i l’anàlisi de seguretat (Checkov/tfsec). Si alguna cosa falla, el pipeline s’atura: no té sentit seguir amb codi mal formatat, invàlid o insegur.

S’executa terraform plan (subcapítol 11.4) i el seu resultat es publica al Pull Request perquè un company el revisi (exactament el flux del subcapítol 12.5). Aquesta és l’etapa clau de seguretat: ningú aplica res sense que abans es vegi i s’aprovi què canviarà.

Un cop el PR es aprova i es fusiona a la branca principal, el pipeline executa terraform apply automàticament, aplicant els canvis revisats. Com ja s’ha revisat el plan, aquest apply és segur i controlat.

Un pipeline simplificat a GitHub Actions tindria aquesta forma (no cal memoritzar la sintaxi, només entendre l’estructura):

Fixa’t en els desencadenants (on):

• En un Pull Request (pull_request): s’executen el lint i el plan (es revisa, no s’aplica).
• En fusionar a main (push a main): s’executa l’apply (ja revisat).

Això implementa exactament el flux d’equip del subcapítol 12.5, però automatitzat.

Recorda el principi del subcapítol 12.5: en equip, ningú aplica Terraform a mà. El pipeline ho fa complir de manera automàtica:

• Els canvis passen sempre per les comprovacions (no es poden saltar).
• El plan sempre es revisa abans d’aplicar.
• L’apply l’executa el sistema, de manera consistent i registrada, no una persona des de la seva màquina (amb la seva configuració particular i possibilitat d’error).

Perquè el pipeline pugui aplicar canvis a AWS, necessita credencials. ⚠️ Mai s’escriuen al fitxer del pipeline (seria com deixar les claus posades). S’utilitzen els secrets de GitHub Actions (un magatzem segur) o, encara millor, una connexió segura sense claus permanents (OIDC), aplicant el mínim privilegi (Capítol 7): el pipeline només ha de tenir permisos per al que necessita gestionar. Aprofundirem en seguretat de credencials al Capítol 23.

• Un pipeline de CI/CD és una seqüència automàtica de passos que s’executa en canviar el codi: CI comprova que és correcte, CD el desplega. Com una cadena de muntatge.
• GitHub Actions defineix pipelines en un fitxer YAML a .github/workflows/; hi ha alternatives equivalents (GitLab CI, Jenkins...), amb els mateixos conceptes.
• El pipeline bàsic de Terraform té tres etapes: Lint (fmt, validate, seguretat), Plan (es publica al PR i es revisa) i Apply (després d’aprovar i fusionar).
• Els desencadenants: en un PR es fa lint + plan (revisió); en fusionar a main es fa l’apply (ja revisat). És el flux del subcapítol 12.5, automatitzat.
• El gran avantatge: ningú aplica des del seu portàtil; tot passa per la cadena automàtica, de manera consistent, segura i traçable.
• ⚠️ Les credencials del pipeline van en secrets (mai al fitxer) i amb mínim privilegi.

Al següent subcapítol veurem una eina especialitzada en aquest flux per a Terraform: Atlantis, que porta el GitOps de la infraestructura a un altre nivell.