Les cinc lliçons anteriors eren laboratoris: cada pas estava escrit, cada fitxer estava donat i cada fallada estava prevista. Aquesta no. Aquesta és l'encàrrec. Aquí tens un context d'empresa, unes restriccions, un pressupost i una llista de requisits amb els seus criteris d'acceptació, i a partir d'aquí decideixes tu: quina eina, quina estratègia de desplegament, quines proves escriure primer, quins escaneigs executar a cada PR i quins només a main, on posar les portes, què deixar fora i —el més difícil— com justificar cadascuna d'aquestes decisions davant d'algú que no hi era quan les vas prendre.

Ho pots fer sobre un projecte teu (millor, si en tens un) o sobre Mini-Reservalia. El que no pots fer és copiar el pipeline de la 07-05 tal qual: el context de l'encàrrec té restriccions que obliguen a apartar-se'n en almenys tres punts, i trobar-les forma part de l'exercici.

1. L'encàrrec
2. El context: Citas Norte, S.L.
3. Requisits obligatoris i criteris d'acceptació
4. Lliurables
5. Rúbrica d'autoavaluació
6. Pla de treball en cinc sessions
7. Reptes opcionals
8. Errors típics del projecte final
9. Errors Comuns i Consells
10. Exercicis
11. Conclusió i tancament del curs en la pràctica

T'incorpores com a responsable de lliurament a una empresa petita que té un producte en producció i cap pipeline. Despleguen a mà, els divendres no despleguen, i l'última vegada que alguna cosa va sortir malament van trigar dues hores a tornar enrere perquè ningú no recordava quina versió hi havia abans.

El teu encàrrec: portar aquest producte des de l'estat actual fins a un pipeline complet d'extrem a extrem, amb portes de qualitat, artefacte immutable, desplegament automatitzat amb rollback i mètriques que demostrin que la situació ha millorat.

La condició de l'encàrrec: tot el que construeixis ha de poder ser verificat per un revisor extern que no ha parlat amb tu, en menys d'una hora, mirant només el repositori.

Aquesta darrera condició és la que converteix l'exercici en una cosa semblant a la feina real. Un pipeline que només funciona quan tu ets al davant per explicar-lo no és un lliurable: és una dependència.

Les restriccions són les que fan que les decisions s'hagin de justificar. Si tot fos possible, no hi hauria res a decidir.

L'empresa. Citas Norte, S.L. ven un programari de reserves per a petits negocis. Té:

Les restriccions, que són innegociables:

1. Pressupost d'eines: 0 €/mes. L'empresa no aprova cap despesa nova fins al proper exercici. Tot ha de cabre en plans gratuïts.
2. Ningú no es pot dedicar a operar el pipeline. L'equip són tres persones i les tres estan al 100 % en producte. Un Jenkins autoallotjat queda descartat per això, no pel que és tècnic.
3. La finestra de manteniment actual és sagrada per al negoci: els dissabtes al matí, entre les 9:00 i les 13:00, s'hi concentra el 40 % de les reserves del cap de setmana. Una caiguda aquí costa clients.
4. Hi ha dades personals (nom, telèfon i correu dels clients finals dels 180 negocis). Qualsevol filtració és un incident reportable.
5. La tech lead se'n va de vacances tres setmanes d'aquí a dos mesos. Durant aquest temps, les altres dues persones han de poder desplegar i revertir sense ella.
6. L'equip desconfia de l'automatització. El backend, en concret, ha dit literalment: «cada minut que hi dediquem és un minut que no dediquem al que ens paguen». La teva proposta ha de rendir aviat i ho has de poder demostrar amb números.

Tres conseqüències de llegir bé les restriccions (comprova-les contra les teves decisions quan acabis):

• La restricció 2 i la 6 juntes descarten qualsevol solució que requereixi manteniment continu. Menys peces i més estàndard guanya a més potent.
• La restricció 5 significa que el rollback ha de ser executable per algú que no el va escriure, amb un botó i sense recordar ordres. Documentar no és opcional aquí: és un requisit funcional.
• La restricció 3 no vol dir «finestres de desplegament». Vol dir que el temps de restauració importa més que la freqüència. Si pots revertir en 3 minuts, el dissabte deixa de fer por; si trigues 2 hores, cap finestra no et salva.

La línia base que has de mesurar abans de tocar res (és el requisit més incomplert de tot el projecte):

Cada requisit porta el seu criteri verificable. La fórmula «un revisor extern ha de poder comprovar que…» és deliberada: si no es pot comprovar mirant el repositori i les seves execucions, no compta.

Total: 29 requisits. No s'espera que tots quedin impecables; s'espera que tots estiguin considerats i que les absències siguin decisions documentades, no oblits.

Públic (o privat amb accés al revisor), amb historial real: branques, PR, comprovacions, execucions amb èxit i execucions amb fallada. Un repositori amb un sol commit gegant no demostra un pipeline; demostra un fitxer.

Estructura suggerida:

Aquest és el lliurable que més es nota i el que pitjor es fa. No és documentació de què fa el pipeline —això es llegeix al YAML—: és el registre de per què és així i què es va sacrificar.

Plantilla mínima:

La secció «Què NO hem fet i per què» és la que distingeix una feina professional d'un exercici. Un pipeline sense límits explícits és un pipeline que creixerà sense control fins que algú l'abandoni.

Provoca una fallada real, deixa-la arribar fins on el teu pipeline la aturi, i escriu el post-mortem. Suggeriments de fallada, en ordre de dificultat:

Estructura del post-mortem, sense culpables:

Un panell de Grafana versionat, o —si no muntes Prometheus— un $GITHUB_STEP_SUMMARY d'un job programat amb les quatre DORA, l'estat de l'SLO i el consum del pressupost d'error. El que s'avalua és que existeixi una superfície on algú que no ets tu pugui veure com va la cosa sense demanar-te res.

Aplica-te-la amb honestedat. La columna «Insuficient» descriu el que la majoria lliura al primer intent.

Com puntuar-te: compta quantes files cauen a cada columna.

• Majoria a Insuficient: tens un pipeline que funciona però no és defensable. Prioritza el grup A i el B4/B6.
• Majoria a Correcte: és un pipeline professional, lliurable. És l'objectiu realista del curs.
• Diverses a Excel·lent: estàs per damunt del que tenen molts equips en producció. Tria'n dues o tres per portar a excel·lent en comptes de pujar-les totes alhora.

Cinc sessions de 2-4 hores. L'ordre no és arbitrari: cada sessió deixa alguna cosa funcionant i mesurable, i cap no depèn d'acabar la següent per aportar valor. És el mateix principi dels set increments de la 05-04.

1. Mesura la línia base. Les quatre DORA amb les dades que tinguis, encara que siguin aproximades. Anota-les al PIPELINE.md avui, perquè d'aquí a tres setmanes no les podràs reconstruir.
2. Aconsegueix que el projecte es verifiqui amb una sola ordre: npm ci && npm run lint && npm test && npm run build. Si això no funciona en una màquina neta, arregla-ho abans d'escriure una línia de YAML.
3. Escriu la prova que falta per al bug més recent que hàgiu tingut.
4. Comet el lockfile si no hi és.

Lliurable de la sessió: una ordre que verifica el projecte i la línia base escrita.

1. ci.yml incremental, com a la 07-01: primer que s'executi, després que instal·li i provi, després jobs en paral·lel, després memòria cau. Mesura els temps a cada pas i anota'ls.
2. Les tres capes de proves (07-02). Comença per la que més por et fa trencar.
3. Cobertura amb llindar 2-3 punts per sota del valor actual.
4. Protecció de main amb un job agregador com a única comprovació requerida.
5. Trenca alguna cosa expressament i comprova que bloqueja.

Lliurable: A1-A6 complerts, amb els temps abans/després de la memòria cau.

1. Dockerfile multietapa, no-root, HEALTHCHECK (07-03).
2. Publicació al registre per digest, amb el digest visible al resum.
3. scripts/desplegar.sh idempotent i executable en local. Escriu-lo abans que el YAML: si comences pel YAML, acabaràs amb lògica dins del YAML.
4. scripts/smoke.sh que verifiqui salut, funcionalitat i versió.
5. cd.yml amb dos entorns i aprovació al segon.
6. rollback.yml cronometrat. Executa'l i anota el temps.
7. Provoca un desplegament dolent i comprova que el smoke test l'atura.

Lliurable: B1-B7 complerts, amb l'execució del rollback cronometrada i la del desplegament bloquejat.

1. Auditoria del que portes construït, amb la llista de la 07-05.
2. permissions de mínim privilegi, provocant una fallada per entendre-ho.
3. Accions per SHA + Dependabot.
4. Els cinc escaneigs, un cada vegada, comprovant que cadascun detecta alguna cosa real abans de passar al següent.
5. Política de severitats escrita i el job de caducitat d'excepcions.
6. SBOM, signatura i verificació abans de desplegar.

Lliurable: D1-D6, amb evidència que cada escaneig ha detectat alguna cosa.

1. /metriques amb les senyals d'or (07-04).
2. SLO amb l'aritmètica del pressupost escrita.
3. Una alerta per símptoma, disparada expressament i amb captura.
4. Job programat de DORA. Executa'l dues vegades amb dies de diferència per tenir tendència.
5. Provoca la fallada del post-mortem i escriu-lo.
6. PIPELINE.md complet, inclosa la secció de què no has fet.
7. Passa't la rúbrica.

Lliurable: E1-E5, PIPELINE.md, POSTMORTEM.md i l'autoavaluació.

Consell sobre el ritme. Si vas curt de temps, sacrifica el grup E abans que el B. Un pipeline que desplega i reverteix però no es mesura és incomplet; un que es mesura però no pot revertir és perillós. I si has de triar un sol requisit dels 29, que sigui B6: rollback cronometrat. És el que converteix la por en un número.

Per quan el bàsic estigui tancat. Cadascun val per si sol.

El més instructiu de tots, si vols tancar el curs amb alguna cosa que et canviï la perspectiva, és la matriu de dues eines: reimplementar el pipeline a GitLab CI t'obliga a separar el que és el teu procés del que és sintaxi de GitHub, i aquesta separació és exactament la que defensava la 06-07. Es triga menys del que sembla —la feina real ja és als scripts— i el resultat és una taula d'equivalències que has escrit tu.

Aquests tres són, de bon tros, els que més es repeteixen. Tots tres tenen la mateixa forma: fer la part visible abans que la part que la sosté.

Com es manifesta. S'obre ci.yml i es comença a escriure. Al cap de tres dies hi ha 200 línies de YAML amb run: | de vint línies cadascun, i l'única manera de provar un canvi és fer push i esperar quatre minuts.

Per què és greu. El cicle de depuració passa de segons a minuts, i multiplicat per cada intent. Un problema que en local es resol en cinc iteracions de deu segons es converteix en cinc iteracions de quatre minuts, amb commits d'«arreglar CI», «arreglar CI 2», «ara sí». A més, aquesta lògica no és testejable, no és revisable i no es pot executar en una emergència si el CI està caigut.

L'ordre correcte:

Prova de foc: pots desplegar sense GitHub Actions? Si la resposta és no, la lògica és al lloc equivocat.

Com es manifesta. Un pipeline preciós que desplega en noranta segons... el codi trencat. Les proves existeixen, passen sempre, i no cobreixen res del que es trenca de debò.

Per què és greu. Automatitzar el desplegament multiplica la velocitat a la qual arriben els canvis a producció. Si la verificació és feble, el que has multiplicat és la velocitat a la qual arriben els bugs. Un pipeline ràpid sobre proves dolentes és objectivament pitjor que el desplegament manual del principi, perquè el manual almenys incloïa una persona mirant.

L'ordre correcte: una prova que detecti l'últim bug real que vau tenir, abans d'automatitzar el desplegament. Si no la pots escriure, no automatitzis encara: automatitza només fins a staging i deixa producció manual fins que la xarxa de seguretat existeixi.

El senyal d'alarma: si la teva suite no ha estat mai en vermell per un bug real —només per errors de sintaxi—, no està provant res.

Com es manifesta. Tres setmanes de feina, un pipeline excel·lent, i a la reunió amb la direcció: «i això què ha millorat?» — «Doncs... va tot molt millor».

Per què és greu. És l'error que fa que la següent inversió no s'aprovi. Recorda la restricció 6 del context: el backend ja pensa que això és temps robat al producte. Sense números, té raó ell, perquè el seu escepticisme sí que està basat en alguna cosa concreta (les hores invertides) i la teva defensa no.

I hi ha un agreujant tècnic: la línia base no es pot reconstruir a posteriori. Un cop el pipeline està muntat, l'«abans» ja no existeix. És informació que es destrueix en fer la feina.

L'ordre correcte: mesurar a la sessió 1, abans de tocar res, encara que sigui amb estimacions grolleres. Quatre números i la data. Deu minuts de feina que valen per les tres setmanes següents.

Com es presenta després:

Aquesta darrera fila és la que tanca la discussió, i per això convé tenir-la: tradueix la feina a hores de persones, que és la unitat en què pensa qui aprova pressupostos. És exactament l'argument del TCO de la 06-07, aplicat al teu propi projecte.

Símptoma: el projecte s'encalla a la sessió 3 i no arriba a producció. Causa: intentar muntar l'entorn de destinació «de debò» (un VPS, Kubernetes, AWS) abans de tenir el pipeline. Arranjament: fes servir una destinació simulada com la de la 07-03 i acaba el circuit complet. Un pipeline que desplega a un contenidor local però cobreix les set peces de B1-B7 val infinitament més que mig pipeline apuntant a infraestructura real. Canvia la destinació al final; és la part més fàcil de canviar.

Símptoma: 29 requisits semblen inabastables i no es comença. Causa: intentar fer-los en paral·lel. Arranjament: el pla de cinc sessions està ordenat per dependència. Fes A sencer abans de tocar B. Un grup acabat val més que cinc a mitges, perquè els grups incomplets no es poden verificar.

Símptoma: el PIPELINE.md acaba sent una descripció del YAML. Causa: documentar mentre s'escriu el codi, quan encara no hi ha perspectiva. Arranjament: escriu cada decisió en el moment en què descartes una alternativa, amb una línia: «descartat X perquè Y». Al final, aquestes línies són el document. Si no vas descartar mai res, no vas prendre decisions: vas copiar.

Símptoma: la rúbrica surt majoritàriament en «Correcte» i no saps què millorar. Consell: no ho pugis tot a «Excel·lent». Tria'n dues o tres amb criteri: les que més redueixin el risc en el teu context concret. Amb les restriccions de Citas Norte, les tres candidates òbvies són el rollback (restricció 5), la verificació de signatura (restricció 4, dades personals) i les DORA amb tendència (restricció 6, cal convèncer algú).

Consell — no ho facis tot tu. Si tens amb qui, demana a algú que verifiqui el teu repositori seguint els criteris d'acceptació, sense que li expliquis res. Els punts on t'hagi de preguntar alguna cosa són exactament els que et falten per documentar. És la prova més barata i la més reveladora del projecte.

Consell — el pipeline no està mai acabat. Quan tanquis els 29 requisits, el pipeline serà bo per al context d'avui. Amb el doble d'equip i deu vegades el trànsit, tres de les teves decisions seran incorrectes. Per això cada decisió del PIPELINE.md porta «quan revisar aquesta decisió»: no és burocràcia, és reconèixer que un pipeline és un organisme viu i que l'alternativa a revisar-lo és reescriure'l sencer d'aquí a dos anys.

Aquests tres no són variacions del laboratori: són extensions del mateix projecte final, pensades per fer-les després de lliurar-lo.

Intercanvia repositoris amb una altra persona que hagi fet el projecte (o audita un repositori públic real que faci servir GitHub Actions). Aplica els 29 criteris d'acceptació sense parlar amb ningú i escriu un informe d'auditoria amb les troballes prioritzades.

La restricció 5 del context: la tech lead se'n va tres setmanes. Demostra que el sistema hi sobreviu.

Redueix a la meitat el temps del teu pipeline sense treure cap verificació. Documenta cada canvi amb el seu mesurament.

Solució 1. Plantilla d'informe d'auditoria:

El que ensenya aquest exercici: auditar la feina d'un altre és la manera més ràpida de veure els forats de la teva. Gairebé tothom troba al repositori aliè dues o tres coses que també li falten al propi i que no havia vist en setmanes.

Solució 2. El protocol de la prova:

Les tres fallades que apareixen gairebé sempre en aquest exercici, per si vols avançar-t'hi:

1. Trobar el digest anterior. Ningú no sap on mirar. Arranjament: imprimir-lo al resum de cada desplegament i acceptar l'input buit al rollback (07-03 exercici 1).
2. L'alerta no va arribar a ningú. Estava configurada a Prometheus però sense destinatari. Arranjament: Alertmanager amb un canal real, i una prova que hi arriba.
3. El camí manual no existeix. Tot el coneixement és dins del YAML. Arranjament: scripts/desplegar.sh executable en local (requisit C2), documentat al runbook amb l'ordre literal.

Si el teu projecte passa l'escenari 3, has complert el criteri més exigent de tot el curs: el pipeline és una comoditat, no una dependència.

Solució 3. L'estratègia, en ordre de rendibilitat:

La lliçó d'aquest exercici és C3: la memòria cau de Docker no funciona si el Dockerfile està mal ordenat, i molta gent afegeix C2, no veu millora i conclou que «la memòria cau no serveix». L'ordre de les capes és el 80 % del resultat, i és gratis.

Si has arribat fins aquí amb el projecte lliurat, tens al teu repositori una cosa que molts equips en producció no tenen: un pipeline que integra, verifica en tres capes, construeix un artefacte immutable identificat pel seu contingut, l'escaneja de cinc maneres diferents, el signa, el desplega després d'una porta explícita, comprova que el desplegament va funcionar, promociona el mateix artefacte sense reconstruir-lo, reverteix en minuts —sol, si les mètriques empitjoren—, i es mesura a si mateix per poder demostrar que tot això serveix d'alguna cosa.

Però el lliurable que més durarà no és el YAML. Són els dos documents.

El PIPELINE.md, perquè conté l'única cosa que no es pot deduir llegint el codi: per què és així i què es va sacrificar a canvi. D'aquí a un any, quan algú —potser tu— es pregunti per què no hi ha canary o per què les accions estan fixades per aquells SHA estranys, la resposta hi serà escrita, amb la seva data i amb la condició que obligaria a revisar-la. Un pipeline sense aquest document es reescriu sencer cada dos anys perquè ningú no gosa tocar el que no entén.

I el POSTMORTEM.md, perquè documenta l'única prova que de debò importa: que el sistema va fallar i ho va aguantar. Qualsevol pot ensenyar un pipeline en verd. Ensenyar-ne un que es va posar en vermell pel motiu correcte, al lloc correcte, i que es va recuperar en tres minuts, és ensenyar que funciona.

Hi ha una última cosa que aquest mòdul t'ha fet fer sense dir-t'ho explícitament, i convé anomenar-la ara. A cada laboratori has trencat alguna cosa expressament: un test, un desplegament, un secret, una consulta SQL, un endpoint lent. Això no era decoració pedagògica. És la pràctica professional que separa qui té un pipeline de qui confia en el seu pipeline: verificar pel costat negatiu. Qualsevol pot comprovar que un control deixa passar el que és bo; comprovar que atura el que és dolent requereix fabricar el que és dolent, i gairebé ningú no ho fa. Si t'emportes un sol costum del curs, que sigui aquest: cada vegada que afegeixis una porta, provoca la fallada que hauria d'aturar, i no donis la porta per bona fins que ho hagis vist.

Amb això es tanca la part pràctica i, amb ella, la matèria del curs. Has recorregut els principis (mòduls 1 a 4), quatre contextos reals (mòdul 5), la maquinària (mòdul 6) i la construcció d'extrem a extrem amb les teves mans (mòdul 7). El que queda ja no és matèria: és on anar després.

El mòdul 8 és el mapa d'aquesta continuació. Les lectures recomanades —Continuous Delivery, Accelerate, The DevOps Handbook, l'SRE Workbook— que donen el fonament i les dades darrere de gairebé tot el que has aplicat aquí. Les comunitats i fòrums on es discuteixen aquests problemes quan se surten del que cap en un curs. Les eines i plugins addicionals que van quedar fora per espai i que resolen problemes concrets que ja sabràs reconèixer: gestió de secrets amb Vault, lliurament progressiu amb Flagger o Argo Rollouts, plataformes internes de desenvolupament, polítiques com a codi. I la ruta d'aprenentatge i certificacions, amb l'ordre raonable per aprofundir segons cap on et vulguis moure —plataforma, SRE, seguretat de la cadena de subministrament— i quines certificacions valen realment la pena en cada cas.

Comença per 08-01: Lectures Recomanades. I, quan ho facis, llegeix-ho amb el pipeline al davant: ara tens un sistema real sobre el qual provar cada idea, que és exactament el que faltava la primera vegada que vas obrir aquest curs.