A 05-02 vam desplegar servei-comandes a Kubernetes escrivint kubectl apply a mà. És exactament el que TechCorp no es pot permetre: amb sis serveis i un gateway, cadascun desplegant diverses vegades per setmana, la mà humana és lenta, inconsistent i la font dels "desplegaments de dijous a la nit amb reversions" del mòdul 1. La integració contínua (CI) fa que cada canvi es provi automàticament en minuts; el desplegament continu (CD) porta el que passa les proves fins a producció sense intervenció. Aquesta lliçó construeix el pipeline de servei-comandes amb GitHub Actions: proves unitàries, d'integració amb Testcontainers i de contracte amb Pact (04-05), construcció i publicació de la imatge de 05-01, can-i-deploy com a porta, actualització dels manifestos Kustomize de 05-02 i desplegament amb GitOps. Al final apliquem la regla del Luis perquè els altres cinc serveis no copiïn 150 línies de YAML, i mesurem el resultat amb les mètriques DORA. Com canviar de versió sense tallar el servei és de 05-04.

1. Què canvia el CI/CD amb microserveis
2. Les etapes del pipeline de TechCorp
3. .github/workflows/ci.yml de servei-comandes, línia a línia
4. Proves de contracte al pipeline: Pact Broker i can-i-deploy
5. Desplegament continu: .github/workflows/cd.yml
6. GitOps amb Argo CD: techcorp/plataforma com a font de veritat
7. Versions, etiquetes i changelogs per servei
8. Entorns i promoció: dev → staging → prod
9. Secrets a CI
10. El pipeline de @techcorp/comu-http
11. La regla del Luis: un workflow reutilitzable per als sis serveis
12. Mètriques DORA: mesurar el pipeline

El monòlit techcorp-shop tenia un pipeline: 40 minuts de suite, un artefacte, un desplegament coordinat. Amb microserveis:

La independència de desplegament és la promesa central de l'arquitectura (01-02, 02-01) i només es compleix si el pipeline de cada servei pot desplegar sol, sense un "tren de releases" que els agrupi tots. La condició per atrevir-s'hi és la confiança que donen les proves de contracte: és Pact, no una prova E2E de tot el sistema, qui respon "trencaré algú?".

Tot el que és anterior a la imatge és CI: ràpid, a cada canvi. El que ve després és CD.

Notes de lectura:

• Dos jobs (proves, imatge) amb needs: la imatge només es construeix si tot passa; en un PR (pull_request) només corre proves.
• ubuntu-latest porta Docker, així que test:integracio funciona tal qual: Testcontainers descarrega postgres:16 i rabbitmq:3-management al runner. És la raó per la qual a 04-05 vam separar test (sense Docker) de test:integracio.
• docker/metadata-action produeix les dues etiquetes de 05-01 sense scripts a mà: sha-<commit> sempre, i la semver quan l'esdeveniment és un tag v1.0.1.
• secrets: npmrc= a build-push-action alimenta el --mount=type=secret,id=npmrc del Dockerfile: el token no queda en cap capa.
• cache-from/to: type=gha desa les capes a la memòria cau de GitHub Actions: un canvi a src/ no repeteix npm ci a CI, igual que al portàtil.
• permissions mínims: contents: read per clonar, packages: write per publicar. Res de tokens personals.

A 04-05 el fitxer de pacte viatjava a mà de servei-comandes a servei-cataleg. A CI viatja pel Pact Broker (autoallotjat o PactFlow), que desa cada pacte amb la versió (github.sha) i la branca del consumidor, i cada resultat de verificació amb la versió del proveïdor:

Al CI del proveïdor (servei-cataleg), el test:contracte de 04-05 s'executa amb pactBrokerUrl en lloc de pactUrls, amb publishVerificationResult: true i providerVersion: process.env.GITHUB_SHA, i després de desplegar registra a quin entorn hi ha cada versió (pact-broker record-deployment --environment staging). Amb això, la porta abans de desplegar és una línia:

can-i-deploy respon "sí" només si totes les versions de proveïdors actualment desplegades a staging han verificat amb èxit els pactes d'aquesta versió de Comandes (i, si Comandes fos proveïdor d'algú, si els seus consumidors desplegats continuen satisfets). És la garantia d'integració al cost d'una consulta HTTP: la raó per la qual l'única E2E de TechCorp pot continuar sent una.

El desplegament a staging és directe des del workflow: actualitza l'etiqueta d'imatge a l'overlay de Kustomize (05-02), llança el Job de migracions, aplica i espera el rollout, i executa l'E2E.

Dos detalls respecte de 05-02: el Job de migracions passa a dir-se servei-comandes-migracions a seques i el workflow esborra l'anterior abans d'aplicar (un Job és immutable); és l'alternativa al nom versionat, i funciona perquè migrar.js és idempotent. I kustomize edit set image modifica la línia images: que vam deixar preparada a l'overlay: el YAML continua sent la font de veritat, el pipeline només canvia una etiqueta. Amb Helm l'equivalent seria helm upgrade --set image.tag=$ETIQUETA.

rollout status és el que converteix "he aplicat" en "està desplegat i llest": espera que les rèpliques noves passin el readinessProbe i falla (i el job falla) si en 180 s no ho aconsegueixen. Què fa Kubernetes mentrestant amb les rèpliques velles és 05-04.

Per a producció, TechCorp no vol que un workflow amb un kubeconfig en un secret executi kubectl apply contra el clúster de producció. Adopta GitOps: l'estat desitjat de producció és el que hi ha a git (techcorp/plataforma, branca main, overlays/prod), i un agent dins del clúster (Argo CD; Flux és equivalent) el llegeix i l'aplica contínuament.

Per què TechCorp ho adopta: (1) auditoria: cada desplegament a producció és un commit revisable a plataforma; (2) sense credencials del clúster fora del clúster: Argo CD fa pull, ningú no fa push; (3) detecció de desviacions: si algú fa kubectl scale a mà un divendres, Argo ho torna a l'estat de git (o avisa); (4) rollback = revertir el commit. El Job de migracions s'anota com a argocd.argoproj.io/hook: PreSync amb hook-delete-policy: BeforeHookCreation, que és la manera GitOps d'"esborrar l'anterior i executar abans del Deployment". Argo CD i Flux també poden desplegar a staging; TechCorp comença amb el workflow directe a staging per aprendre i amb GitOps a producció, i ho unificarà més endavant.

• Semver per servei: servei-comandes 1.0.1 no té res a veure amb servei-cataleg 1.4.2. Major = canvi incompatible de contracte (que a 03-06 vol dir /v2/), menor = funcionalitat compatible, pedaç = correcció.
• La imatge sha-<commit> es construeix sempre; la semver, en etiquetar: git tag v1.0.1 && git push --tags dispara ci.yml amb el tag i metadata-action afegeix 1.0.1 a la mateixa imatge (mateix digest) que ja va passar per staging com a sha-.... No es reconstrueix res per a producció.
• Changelog: CHANGELOG.md a cada repositori, alimentat a mà o generat a partir de missatges de commit amb la convenció conventional commits (feat:, fix:, feat!:), que eines com semantic-release o release-please fan servir per calcular la versió i publicar la release automàticament. TechCorp adopta la convenció de missatges; l'automatització de la versió queda com a pas següent.

Els tres entorns apliquen la mateixa base Kustomize amb overlays diferents (05-02): l'única cosa que canvia entre staging i prod és l'etiqueta d'imatge, les rèpliques i dues claus de ConfigMap. Promocionar és obrir un PR a plataforma que canvia newTag a overlays/prod (el workflow l'obre sol amb peter-evans/create-pull-request); revisar i fusionar és l'aprovació.

• secrets.GITHUB_TOKEN: el genera GitHub per a cada execució, amb els permissions declarats; serveix per a ghcr.io i GitHub Packages sense crear res.
• Secrets de repositori/organització (PACT_BROKER_TOKEN, PLATAFORMA_TOKEN) i d'entorn (KUBECONFIG_STAGING, lligat a l'environment: staging, amb revisors obligatoris si es vol).
• OIDC en lloc de claus de llarga durada: per parlar amb el núvol (AWS/GCP/Azure) o amb un registre extern, el workflow obté un token efímer per identitat federada (permissions: id-token: write + aws-actions/configure-aws-credentials) en lloc de desar una access key en un secret. És la pràctica recomanada i la que TechCorp farà servir per al clúster de producció si algun dia un workflow necessita tocar-lo (amb GitOps, no ho necessita).
• Mai echo d'un secret als logs; GitHub els emmascara, però base64 o transformacions els destapen.

La llibreria (04-01) té el seu propi workflow, més curt: npm ci, npm test, i en tag v*, npm publish a GitHub Packages:

Cada servei fixa al seu package.json la versió que fa servir ("@techcorp/comu-http": "^2.3.0") i l'actualitza quan vol, amb Renovate/Dependabot obrint el PR: la llibreria no obliga a redesplegar ningú, que era la condició perquè existís (04-01).

"Si es fa més d'una vegada per servei, s'automatitza abans de la segona." El ci.yml de l'apartat 3 té 80 línies i seria idèntic a Catàleg, Inventari, Pagaments, Notificacions i Clients tret del nom. GitHub Actions permet un workflow reutilitzable (workflow_call) que viu a techcorp/plataforma:

I a cada servei, el ci.yml es redueix a:

El workflow reutilitzable és als pipelines el que @techcorp/comu-http als serveis: es versiona (@v1), cada servei adopta la versió nova quan vol, i la plantilla plantilla-servei-node (04-01) ja porta aquestes nou línies. Un canvi al pipeline (afegir Trivy, canviar la versió d'una acció) es fa una vegada.

Les quatre mètriques DORA (DevOps Research and Assessment) mesuren si tot l'anterior serveix per a alguna cosa:

Les dues primeres les dona el mateix pipeline (data del commit, data del sync d'Argo); les altres dues necessiten la gestió d'incidents de 06-05. L'important és la relació entre elles: desplegar més sovint amb canvis més petits abaixa la taxa de fallada i el MTTR, que és el contrari de la intuïció del dijous a la nit ("despleguem poc per arriscar poc").

• Un pipeline "de sistema" que prova i desplega tots els serveis junts. És el tren de releases del monòlit amb més YAML. Un pipeline per servei i contractes com a garantia.
• Reconstruir la imatge per a producció. El que es va provar no és el que es desplega. Etiqueta semver sobre la imatge sha- ja provada.
• can-i-deploy com a pas opcional o continue-on-error. S'acaba ignorant. És una porta: si diu que no, no es desplega.
• kubectl apply sense rollout status. El pipeline és verd i les rèpliques noves en CrashLoopBackOff.
• Copiar ci.yml entre repositoris. A la tercera versió d'una acció, sis PR idèntics. workflow_call.
• Secrets de llarga durada en variables quan OIDC està disponible; tokens personals d'un desenvolupador en secrets de l'organització (deixen de funcionar quan marxa).
• Consell: executa el workflow localment amb act per depurar; i desa en un README de cada repositori l'enllaç al workflow reutilitzable i als runbooks, perquè "com es desplega això" tingui resposta.

Exercici 1. El CI de servei-cataleg (proveïdor) ha de verificar els pactes que publiquen els seus consumidors. Escriu els passos del job contracte del seu ci.yml (sense repetir checkout/setup-node) i explica quines variables d'entorn necessita el Verifier de 04-05 per treballar amb el Broker en lloc d'un fitxer local, i per què ha d'executar record-deployment després de desplegar.

Exercici 2. Un desenvolupador de Pagaments obre un PR que canvia el payload de l'esdeveniment pagament.confirmat. En quina etapa del pipeline de Pagaments es detectaria una incompatibilitat amb servei-comandes, amb les eines de 04-05, i què caldria afegir perquè can-i-deploy la bloquegés?

Exercici 3. La Marta demana que Catàleg i Notificacions es promocionin a producció automàticament després de passar l'E2E a staging, però que Comandes i Pagaments requereixin aprovació humana. Descriu com s'implementa amb el que s'ha vist (entorns de GitHub, workflow_call, PR de promoció, Argo CD) sense duplicar el workflow.

Solució 1. Passos: npm ci → npm run test:contracte amb PACT_BROKER_BASE_URL, PACT_BROKER_TOKEN, GIT_COMMIT=${{ github.sha }} i GIT_BRANCH=${{ github.ref_name }} a env; el Verifier de 04-05 fa servir pactBrokerUrl i pactBrokerToken en lloc de pactUrls, providerVersion: process.env.GIT_COMMIT, providerVersionBranch, publishVerificationResult: true (només a CI: process.env.CI === 'true') i consumerVersionSelectors: [{ mainBranch: true }, { deployedOrReleased: true }] per verificar tant els pactes de la branca principal de cada consumidor com els de les versions desplegades. Després de desplegar a un entorn, pact-broker record-deployment --pacticipant servei-cataleg --version $GIT_COMMIT --environment staging diu al Broker quina versió de Catàleg hi ha a staging: sense aquest registre, el can-i-deploy de Comandes no sap contra quin proveïdor comprovar i respon "no" per manca d'informació.

Solució 2. A l'etapa contracte, però del costat del consumidor: 04-05 va fixar JSON Schema d'esdeveniments amb Ajv i una prova que servei-comandes tolera camps nous de pagament.confirmat; si Pagaments treu o reanomena un camp (import → quantitat), ho detecta la prova d'esquema del mateix Pagaments si l'esquema està compartit a contractes/asyncapi.yaml (falla a l'npm test de Pagaments), o, si no, la prova d'esdeveniments de Comandes quan actualitzi l'esquema. Perquè can-i-deploy ho bloquegi caldria un pacte de missatges (Pact suporta message pacts: Comandes declara el missatge que espera; Pagaments el verifica amb un MessageProviderPact que produeix l'esdeveniment real) publicat al mateix Broker: llavors la relació Pagaments→Comandes apareix com qualsevol altra i can-i-deploy la comprova. És l'evolució natural del JSON Schema de 04-05.

Solució 3. El workflow reutilitzable de CD (servei-node-cd.yml) rep un input promocio-automatica: boolean. El seu últim job obre el PR de promoció a techcorp/plataforma (canvi de newTag a overlays/prod); si promocio-automatica és true, el mateix job el fusiona (gh pr merge --auto), i Argo CD sincronitza; si és false, el PR queda obert i el CODEOWNERS de k8s/servei-comandes/ i k8s/servei-pagaments/ exigeix la revisió del Luis o del líder de Pagaments. A més, el job de producció fa servir environment: production a GitHub amb required reviewers per a aquests dos serveis. Cap workflow no es duplica: Catàleg crida amb promocio-automatica: true, Comandes amb false.

El pipeline de TechCorp converteix cada push en una seqüència automàtica i per servei: ci.yml amb actions/setup-node@v4 (Node 20, memòria cau d'npm, GitHub Packages), npm run lint, npm test, npm run test:integracio amb Testcontainers al runner, npm run test:contracte i publicació de pactes al Pact Broker, docker/build-push-action amb etiquetes sha-<commit> i semver cap a ghcr.io/techcorp/servei-comandes (amb permissions: packages: write i el .npmrc com a secret de build), escaneig amb Trivy, i can-i-deploy com a porta; cd.yml que fixa la imatge a l'overlay de Kustomize (kustomize edit set image), executa el Job de migracions, fa kubectl apply + rollout status i llança l'E2E contra staging; GitOps amb Argo CD i techcorp/plataforma com a font de veritat per a producció; semver i sha- sobre la mateixa imatge; entorns amb els mateixos manifestos; secrets de GitHub i OIDC; el pipeline de @techcorp/comu-http; el workflow reutilitzable servei-node-ci.yml@v1 que aplica la regla del Luis; i les mètriques DORA per comprovar que els dijous a la nit s'han acabat. Queda una pregunta que rollout status amaga: què passa exactament amb el trànsit mentre les rèpliques de la 1.0.0 deixen pas a les de la 1.0.1, i com es desplega una versió a un 10 % dels usuaris abans de donar-la a tothom? Això és la lliçó següent: estratègies de desplegament.