La 08-01 acabava assenyalant un buit: hi ha una classe de coneixement que no és a cap llibre perquè depèn del context i caduca massa ràpid per publicar-se. Per què el teu workflow_run no es dispara encara que el YAML sigui idèntic al de l'exemple. Per què l'OIDC contra AWS funciona en un repositori i no en el del costat. Per què aquella acció de tercers va deixar de funcionar el dimarts sense canviar de versió. Cap d'aquestes respostes no és a Continuous Delivery, i moltes tampoc a la documentació oficial: viuen al cap d'algú que ja hi va topar fa tres setmanes.

Aquesta lliçó tracta d'on és aquesta gent, què esperar de cada lloc, com preguntar perquè et responguin i —el que gairebé ningú no fa i és el que més ràpid ensenya— com tornar alguna cosa des del primer dia. També tracta d'una cosa menys agradable: la major part del contingut que circula per aquests espais és soroll, moda o culte al carregament, i necessites un filtre.

1. Per què això importa de debò
2. El mapa d'espais: què esperar de cadascun
3. Fundacions i ecosistemes
4. Esdeveniments: congressos, meetups i el passadís
5. Comunitats en castellà i per què participar en dues llengües
6. Com preguntar perquè et responguin
7. Com contribuir des del primer dia
8. Higiene informativa: distingir el consell del culte al carregament
9. L'ètica de compartir logs i dades
10. Errors Comuns i Consells
11. Exercicis
12. Conclusió

Hi ha tres tipus de problema i només el tercer justifica aquesta lliçó.

Problemes de coneixement. «Què és un digest?» Es resolen llegint. Els llibres i la documentació basten.

Problemes d'habilitat. «No sé escriure un workflow reutilitzable.» Es resolen practicant. El mòdul 7 era això.

Problemes de context. «El workflow reutilitzable funciona al meu repositori però quan el crido des del repositori de l'organització, secrets: inherit no propaga res i l'error no diu per què.» Aquest no es resol llegint ni practicant, perquè la informació necessària és la intersecció entre una eina concreta, una versió concreta, una configuració concreta i un comportament no documentat. Es resol preguntant a algú que ja hi va ser, o trobant el fil on un altre ho va preguntar.

Quan treballaves seguint un laboratori del mòdul 7, els problemes de context estaven previstos: el material anticipava les fallades. A la teva feina real no ho estaran. I el temps que separa qui es queda bloquejat tres dies de qui ho resol en dues hores gairebé mai no és diferència de talent: és diferència de saber on i com preguntar.

Hi ha un segon motiu, més lent i més important. Les comunitats són on veus la distribució de solucions. Tu has vist una manera de muntar un pipeline: la d'aquest curs, amb les seves decisions i els seus biaixos. En una comunitat veus cinquanta contextos diferents amb cinquanta compromisos diferents, i això és el que converteix una tècnica apresa en criteri propi. No pots calibrar si la teva decisió és raonable si només coneixes una decisió.

GitHub Community (el fòrum de discussions de GitHub) és el primer lloc on anar amb un problema de GitHub Actions que no sigui un bug evident. Té l'avantatge que hi respon gent de la mateixa plataforma i que les respostes queden indexades. La categoria d'Actions concentra exactament els problemes del mòdul 6: permisos del GITHUB_TOKEN, contextos disponibles a cada esdeveniment, límits de concurrència, comportament de workflow_run i dels entorns amb revisors.

El fòrum de GitLab funciona de manera semblant i amb la mateixa estructura Discourse. Per a GitLab hi ha a més una particularitat valuosa: l'issue tracker de GitLab és obert i és el producte mateix. Moltes preguntes de «per què això és així?» tenen resposta literal a la issue on es va discutir.

Jenkins té l'ecosistema més antic i el més dispers: llistes de correu (jenkinsci-users), un Jira propi per a bugs de core i plugins, i canals de xat. Si treballes amb Jenkins —cosa que, com deia la 06-01, continua sent el cas a la meitat de les empreses amb història— aprendre a cercar al seu Jira és una habilitat concreta i rendible: la majoria dels comportaments estranys d'un plugin hi estan reportats, de vegades des de fa anys, amb un workaround al comentari 14.

El Discourse de Kubernetes i els fòrums de CNCF cobreixen la part d'orquestració de la 06-05. Kubernetes té a més un model de governança documentat amb SIG (grups d'interès especial) i les seves pròpies reunions públiques gravades: si algun dia necessites saber per què una API es comporta així, la resposta és a les notes d'un SIG.

Què esperar: precisió sobre l'eina. Què no esperar: consell sobre si hauries d'estar fent servir aquella eina. Al fòrum de Jenkins, la resposta a «hauria de migrar a GitHub Actions?» tindrà un biaix previsible, igual que la contrària a l'altre lloc.

Stack Overflow continua sent el millor arxiu d'errors concrets que existeix. Si tens un missatge d'error literal i estrany, posar-lo entre cometes en un cercador i trobar la pregunta del 2019 amb la resposta acceptada continua funcionant i continua estalviant hores.

Però cal ser honest sobre el seu estat. El volum de preguntes noves ha caigut de manera sostinguda, per tres raons que s'acumulen: els assistents d'IA responen ara la majoria de preguntes de nivell mitjà sense cost social; la cultura del lloc es va tornar notòriament hostil amb qui pregunta malament, cosa que en va expulsar els principiants; i bona part del suport de les eines modernes s'ha mogut a Discord i als fòrums propis de cada producte.

Conseqüència pràctica: tracta'l com a arxiu, no com a comunitat. Cerca-hi sempre, i comprova la data i la versió de cada resposta abans d'aplicar-la. La meitat de les respostes de Docker o d'Actions amb més vots descriuen sintaxi obsoleta o pràctiques avui desaconsellades —hi ha respostes molt votades que recomanen passar secrets per arguments de build, cosa que la 04-03 et va ensenyar a no fer mai perquè queden a les capes de la imatge—. Els vots mesuren antiguitat tant com qualitat.

Kubernetes Slack és l'exemple canònic: desenes de milers de persones, canals per SIG i per tema, i gent que manté el projecte responent. CNCF té espais equivalents per als seus projectes, i moltes eines d'aquest mòdul (Argo, Flux, OpenTelemetry, Backstage) tenen el seu canal allà o un Discord propi.

El que és bo: la velocitat. Un problema de context ben plantejat al canal correcte es pot resoldre en vint minuts per algú que va escriure el codi en qüestió. No hi ha res comparable.

El que és dolent, i és seriós: la conversa no persisteix de manera útil. El que es resol a Slack es perd, no s'indexa i no ajuda ningú més. És un malbaratament sistemàtic de coneixement: els mateixos problemes es resolen una vegada i una altra sense deixar rastre. La contramesura és a la teva mà: quan un canal et resolgui alguna cosa no documentada, escriu-ho. Al teu PIPELINE.md, al wiki del teu equip o —millor— com a resposta al fòrum oficial o com a PR a la documentació del projecte. Convertir una conversa efímera en un artefacte cercable és una de les contribucions més valuoses i menys fetes.

I una regla de convivència: en aquests espais es respon per bona voluntat, en el temps lliure d'algú. Preguntar bé no és cortesia, és el que fa que el sistema continuï funcionant.

r/devops és útil per a una cosa que cap altre espai no et dóna: saber què està frustrant de debò el gremi. Els fils sobre eines concretes, migracions fallides, salaris i esgotament professional et donen una foto de la professió que no apareix en cap congrés, on tothom presenta èxits.

El seu biaix és evident i cal descomptar-lo sempre: la gent publica quan alguna cosa va malament. Ningú no escriu «fa tres anys que anem amb Jenkins i funciona». El resultat és una impressió sistemàticament negativa de totes les eines madures i sistemàticament entusiasta de les noves —fins que deixen de ser noves i comencen a aparèixer els fils de queixa—. És un termòmetre amb l'escala descalibrada: mesura bé les tendències relatives, malament els valors absoluts.

Hi ha un segon biaix: qui publica a r/devops no és representatiu del sector. Hi està sobrerepresentat el perfil d'infraestructura pura, empresa mitjana o gran, entorn anglosaxó. Si hi llegeixes que «ningú no fa servir X ja», vol dir que en aquell subconjunt no ho fan servir.

Serveixen per descobrir que alguna cosa existeix i, ocasionalment, per llegir els comentaris de la persona que va construir el sistema del qual parla l'article, que sovint valen molt més que l'article. Els fils sobre post-mortems públics i sobre arquitectures reals solen tenir una densitat tècnica alta.

Els seus biaixos: forta inclinació cap al que és nou i contrarian, sobrerepresentació de startups i de contextos d'escala extrema, i una tendència al comentari segur-de-si-mateix sobre dominis que qui comenta no coneix. Un consell de HN sobre bases de dades distribuïdes pot venir d'algú que les opera o d'algú que va llegir un article ahir, i el to és idèntic.

Lobsters és més petit i amb menys soroll, però amb el mateix perfil.

Ús recomanat: revisió ràpida, dues o tres vegades per setmana com a màxim, per al radar. Mai com a font de decisió. El cost d'atenció d'aquests llocs és el seu perill real: són addictius i produeixen la sensació d'estar aprenent mentre només t'estàs assabentant.

Hi ha valor real —contactes, ofertes de feina, contingut ocasional de gent que sí que opera sistemes— embolcallat en una capa molt gruixuda de màrqueting personal. El format premia l'afirmació categòrica, la llista de «5 coses» i la història amb moralitat; penalitza el matís, que és exactament el que necessites.

Ús assenyat: xarxa professional i visibilitat de la teva feina (la 08-04 en parlarà), no font d'aprenentatge. I desconfia especialment dels diagrames de «roadmap DevOps» amb quaranta logotips: consoliden la pitjor idea possible, que és que això consisteix a acumular eines.

Aquí hi ha el coneixement més fiable de tots i el pitjor indexat.

Quan vols saber per què una eina es comporta com es comporta, la resposta definitiva és a la issue o a l'RFC on es va decidir. Allà hi veuràs les alternatives considerades, qui s'hi va oposar i amb quin argument, i quin compromís es va acceptar. És una lectura extraordinàriament formativa: t'ensenya com pensen sobre compromisos les persones que dissenyen el que fas servir.

El problema és trobar-ho. La cerca de GitHub sobre issues és mediocre, els RFC estan dispersos i les llistes de correu tenen arxius incòmodes. Tècnica que funciona: cercar en un cercador general amb site:github.com/<org>/<repo>/issues i el missatge d'error o el nom exacte de l'opció. I ordenar per comentaris en comptes de per rellevància: les issues llargues són on hi ha el workaround.

Un hàbit concret i molt rendible: quan una eina et sorprengui —fa alguna cosa que no esperaves i la documentació no ho explica— busca la issue abans d'assumir que és un bug teu. La meitat de les vegades és un comportament conegut, discutit, i amb solució en un comentari.

Tres noms apareixen constantment i convé saber què signifiquen.

CNCF (Cloud Native Computing Foundation). Acull Kubernetes, Prometheus, OpenTelemetry, Argo, Flux, Helm i bona part de l'ecosistema que la 06-05 i la 08-03 toquen. Classifica els seus projectes en tres nivells: sandbox (experimental), incubating (ús real en producció, comunitat creixent) i graduated (madur, governança establerta, múltiples empreses que en depenen).

Què significa per a les teves decisions. Que un projecte sigui graduated és un senyal raonable que no desapareixerà i que no depèn d'una sola empresa —el risc de «projecte abandonat» o «canvi de llicència» baixa molt—. Que sigui sandbox significa el contrari: interessant, possiblement excel·lent, però adoptar-lo en producció és apostar. Aquesta distinció és un criteri directe per a la pregunta «qui manté això?» que la 08-03 proposa abans de ficar cap eina al teu pipeline.

Què no significa. No és un segell de qualitat tècnica ni que ho necessitis. El catàleg de la CNCF —el famós mapa amb centenars de logotips— es fa servir sovint com a llista de la compra, i és exactament l'ús equivocat: és un catàleg de peces per a problemes que la majoria dels equips no tenen.

OpenSSF (Open Source Security Foundation). És on viu bona part de la feina sobre seguretat de la cadena de subministrament que vas aplicar a la 04-03 i la 07-05: Sigstore, el marc SLSA, els scorecards de projectes, guies de bones pràctiques. Si aquella part del curs et va interessar, és l'ecosistema a seguir.

Linux Foundation. El paraigua de les dues anteriors i de molts altres projectes. També l'emissor d'una família de certificacions que la 08-04 valorarà amb detall.

KubeCon + CloudNativeCon és l'esdeveniment gran de l'ecosistema CNCF: milers d'assistents, desenes de pistes paral·leles, i un pes comercial considerable —una part de les xerrades són, amb més o menys dissimul, presentacions de producte—. Les xerrades es graven i es publiquen, cosa que té una conseqüència important per a la teva decisió: si hi vas per les xerrades, no cal anar-hi.

DevOpsDays és un format diferent i, per a la majoria, més útil: esdeveniments locals, d'un o dos dies, organitzats per comunitats en moltes ciutats, amb preus accessibles i un format que inclou open spaces —sessions sense ponent on els assistents proposen els temes i es discuteixen en grup—. Allà és on de debò es comparteix el que no s'explica en una xerrada: els fracassos, els costos reals, les migracions que van sortir malament.

FOSDEM, a Brussel·les, és gratuït, enorme i centrat en programari lliure, amb sales dedicades per projecte. És l'esdeveniment amb millor relació coneixement/preu que existeix, i també el més caòtic.

Meetups locals. Grups de desenes de persones, mensuals, a la teva ciutat. El seu valor no és en el nivell tècnic mitjà de les xerrades —variable— sinó en el fet que són la xarxa professional real del teu mercat laboral. La gent que decideix contractacions a les empreses de la teva ciutat hi és.

Per què el passadís val més que les xerrades. Les xerrades estan gravades, polides i presenten la versió que va quedar bé. La conversa de passadís és on algú et diu «nosaltres ho vam provar i ho vam treure al cap de sis mesos, t'explico per què». Aquest és el contingut que no existeix en cap altre format, perquè ningú no puja a un escenari a explicar que la seva plataforma interna no la fa servir ningú.

Regla pràctica per aprofitar un esdeveniment: tria tres xerrades que vulguis veure de debò, ignora la resta (les veuràs gravades si de cas), i dedica el temps restant a parlar amb gent. Prepara una pregunta concreta sobre el teu propi sistema i fes-la vint vegades a vint persones diferents. Tornaràs amb vint respostes contradictòries, que és exactament el material que necessites per desenvolupar criteri.

Hi ha un ecosistema hispanoparlant actiu: grups locals de Kubernetes i de Docker a les principals ciutats d'Espanya i Llatinoamèrica, comunitats d'AWS i d'altres núvols amb capítols regionals, DevOpsDays en diverses ciutats hispanoparlants, canals de Telegram i Discord per tecnologia, i una producció creixent de contingut tècnic en castellà.

Per què val la pena participar en les dues llengües, no triar-ne una:

• En anglès hi ha el volum i la font. La documentació, les issues, els RFC i la major part de la resposta experta hi són. Renunciar a l'anglès és renunciar a la meitat llarga del coneixement, i la barrera és molt menor del que sembla: l'anglès tècnic escrit és un subconjunt petit i molt repetitiu de l'idioma. S'aprèn llegint issues.
• En castellà hi ha el context del teu mercat. Com són les empreses del teu país, què es paga, què exigeix la teva normativa, com són els processos de contractació. Res d'això no és a r/devops.
• I hi ha una asimetria que et beneficia: en castellà hi ha molt menys contingut de qualitat. Escriure en castellà sobre el que ja saps —el que has construït al mòdul 7, per exemple— té molta més probabilitat de ser llegit i de destacar que fer-ho en anglès, on competeixes amb milers de persones. És la via més ràpida a la visibilitat professional que la 08-04 esmentarà.

Aquesta secció és la més pràctica de la lliçó. La diferència entre una pregunta ignorada i una de resposta en deu minuts gairebé mai no és la dificultat del problema: és quanta feina estalvies a qui respon.

Vegem una fallada real del curs. A la 07-03 desplegaves per digest i diversos laboratoris ensopegaven amb el mateix: el cd.yml es dispara amb workflow_run, el CI va passar en verd, però el desplegament no arriba a executar-se o falla en autenticar-se contra AWS.

Assumpte: No em funciona el deploy

Hola, tinc un workflow de GitHub Actions per desplegar a AWS i no funciona. El CI passa bé però el deploy no. He provat de tot i no sé què fer. Algú ha tingut aquest problema? Gràcies.

Per què ningú no respondrà:

• No hi ha error. «No funciona» descriu una emoció, no un comportament. No es dispara? Es dispara i falla? Falla en quin pas?
• No hi ha codi. Ningú no pot raonar sobre un YAML que no veu.
• No hi ha versions ni entorn. Runner allotjat o propi? Quina versió de les accions? Repositori públic o privat? Hi ha un entorn amb revisors pel mig?
• «He provat de tot» no aporta res i a més és fals, i qui respon ho sap. El que aconsegueix és que el primer suggeriment raonable —que probablement no has provat— sembli una pèrdua de temps per a tots dos.
• L'assumpte no permet cercar. D'aquí a un any, ningú amb el teu mateix problema no trobarà aquest fil.

Assumpte: workflow_run no dispara el workflow de desplegament quan el CI s'executa des d'un PR d'un fork

Context. Tinc dos workflows en un repositori privat: ci.yml (s'executa en push i pull_request) i cd.yml, que s'ha d'executar quan el CI acaba correctament a main. L'objectiu és desplegar a ECS el mateix digest d'imatge que el CI va publicar, sense reconstruir.

Comportament esperat. En fer merge a main, el ci.yml acaba en verd i el cd.yml arrenca.

Comportament real. El ci.yml acaba en verd (execució #482), però el cd.yml no apareix a la pestanya d'Actions. No hi ha cap execució fallida: no hi ha execució en absolut.

Entorn.

• Repositori privat, organització amb pla Team.
• Runners allotjats per GitHub, ubuntu-latest.
• actions/checkout@v4, aws-actions/configure-aws-credentials@v4 (totes dues fixades per SHA).
• Tots dos workflows són a main.

Disparador del cd.yml:

on:
  workflow_run:
    workflows: ["CI"]
    types: [completed]
    branches: [main]

jobs:
  desplegar:
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    runs-on: ubuntu-latest
    environment: produccio

Què he comprovat ja:

1. El name: del workflow de CI és exactament CI (verificat al fitxer, no a la interfície).
2. El ci.yml que va acabar en verd es va executar sobre main — ho confirma la interfície de l'execució.
3. L'entorn produccio existeix i té un revisor assignat; amb un workflow_dispatch manual, el cd.yml sí que s'executa i espera aprovació correctament. Així que el problema sembla estar al disparador, no al desplegament.
4. He mirat si la fallada era de permisos del token, però no arriba a haver-hi execució, així que descarto aquesta via.

Hipòtesi actual. Que branches: [main] a workflow_run filtri per la branca de l'execució del CI i no per la branca de destinació del merge, i que en el meu cas no coincideixin. No he trobat confirmació d'això a la documentació.

La pregunta concreta: sobre quina branca s'avalua exactament el filtre branches en un disparador workflow_run? I hi ha alguna manera de verificar per què un workflow_run no s'ha disparat, atès que no queda cap registre?

Per què aquesta es respon:

L'efecte secundari més útil: escriure la pregunta bona resol el problema sense arribar a publicar-la en un percentatge molt alt dels casos. L'acte d'haver d'enunciar què esperaves, què va passar i què vas descartar és un mètode de depuració. Quan algú et digui «escriu el problema com si el volguessis publicar», no t'està donant llargues: t'està donant la tècnica.

• Un problema per pregunta. Les preguntes amb tres problemes encadenats no es responen.
• Enganxa text, no captures de pantalla, tret que el problema sigui visual. El text es cerca, es cita i es llegeix al mòbil.
• Retalla el log al que és rellevant, però inclou les línies del voltant. Un error sol tenir la causa cinc línies abans.
• Publica en un sol lloc alhora. Preguntar simultàniament a Slack, al fòrum i a Stack Overflow malbarata el temps de tres persones.
• Torna i tanca el fil. Si el resols —tu o algú altre—, escriu la solució. Un fil abandonat amb «ja ho vaig arreglar, gràcies» és una crueltat amb qui hi arribi en el futur amb el teu mateix problema.

La creença estesa és que cal ser expert per contribuir a un projecte obert. És falsa, i creure-la et costa la via d'aprenentatge més ràpida que existeix.

Per què contribuir ensenya tan ràpid: t'obliga a entendre un sistema real que no vas escriure tu, amb estàndards de qualitat que no pots negociar, i reps revisió de persones que en saben més que tu, gratis. No hi ha cap altra manera d'aconseguir això.

Cinc maneres de contribuir sense ser expert, ordenades per facilitat:

1. Reproduir issues. Un mantenidor rep «això no funciona» sense versions i sense exemple. Algú que agafi aquella issue, la reprodueixi en un repositori mínim, confirmi en quines versions passa i ho escrigui en un comentari ha fet la meitat de la feina d'arreglar-la. És el que més agraeixen els mantenidors i gairebé ningú no ho fa. I per a tu és un exercici de depuració amb solució coneguda al final.

2. Documentació. Acabes de recórrer un curs complet ensopegant amb coses mal explicades. Aquesta perspectiva de nouvingut és un actiu que es perd en setmanes: qui fa dos anys que és en un projecte ja no veu què hi falta. Arreglar un exemple que no funciona, afegir el pas que faltava, aclarir una frase ambigua: tot això són PR petits i benvinguts.

3. Exemples. Molts projectes tenen un directori examples/ amb el bàsic. Un exemple real d'integració —com fer servir aquella eina dins d'un workflow de GitHub Actions, per dir una cosa que ara saps fer— és una contribució d'alt valor i baix risc.

4. Traduccions. Si el projecte té documentació traduïda, hi ha lloc en castellà gairebé sempre. És una contribució que no requereix entendre el codi a fons i que serveix a molta gent.

5. Revisar PR d'altres. No cal permís per llegir un PR obert i comentar-lo. Provar-lo i dir «l'he aplicat al meu entorn i funciona / falla amb això» és una revisió útil, i llegir els PR d'un projecte és la millor manera d'aprendre com s'escriuen les coses allà.

El lloc per on començar: el projecte que ja fas servir i amb el qual ja has ensopegat. La motivació d'arreglar una cosa que et va molestar a tu és l'única que aguanta el primer PR rebutjat. Busca les etiquetes good first issue o help wanted, llegeix el CONTRIBUTING.md sencer abans de tocar res, i comença petit de debò.

Un advertiment honest: contribuir és lent i de vegades frustrant. Els PR es queden sense revisar durant setmanes, els mantenidors estan saturats i treballen gratis, i de vegades la teva proposta es rebutja per raons de direcció del projecte que no coneixies. Res d'això no és personal. Si busques gratificació ràpida, aquesta no és la via; si busques aprendre de debò com es construeix programari que altres fan servir, no n'hi ha cap de millor.

El terme «culte al carregament» ve de la pràctica d'imitar la forma d'una cosa sense entendre'n la funció. En aquesta disciplina és endèmic: gent que copia l'estructura del pipeline d'una empresa gran sense tenir ni els seus problemes ni els seus recursos.

Té marcadors igual d'identificables:

• Declara el context sense que li ho demanin: «en un equip de vuit, amb desplegaments diaris i sense guàrdies formals…».
• Esmenta el que va costar: «va funcionar, però ens va menjar dues setmanes i vam haver de formar tot l'equip».
• Inclou el fracàs: «primer ho vam intentar amb X i ho vam treure perquè…». Qui explica el que va treure ha operat el sistema de debò.
• Distingeix el que sap del que suposa: «no ho he provat en aquella versió, però hauria de…».
• Respon amb una pregunta abans de recomanar res. La primera resposta de la gent que en sap sol ser «quanta gent sou i què falla ara mateix?».

El risc d'aquesta lliçó és que la converteixis en una llista de subscripcions. El resultat seria la sensació permanent d'anar endarrerit, que és l'estat d'ànim més comú i més inútil de la professió.

Una dieta que funciona:

• Profunditat, setmanal. Una cosa llarga i de fons: un capítol del pla de la 08-01, un post-mortem públic, un RFC. 45 minuts. És l'única cosa d'aquesta llista que produeix criteri.
• Actualitat, diària i limitada. Quinze minuts com a sostre, i només de l'eina que fas servir en producció: les seves notes de versió, el seu changelog, els seus avisos de seguretat. Això és tot el que necessites saber al dia.
• Radar, setmanal. Una passada per HN o r/devops o el butlletí que sigui, amb una regla explícita: assabentar-se que una cosa existeix no és una tasca pendent. Anota-ho en una llista d'«existeix» i continua.
• Comunitat, quan la necessitis. Preguntar i respondre quan toqui; no viure-hi.
• I una regla de descart: si fa sis mesos que veus un nom i mai no t'ha resolt un problema, esborra'l del teu radar. Tornarà si importa.

El que cal interioritzar del cicle del hype: les eines que de debò importen continuen allà d'aquí a cinc anys, i les aprendràs llavors amb millor documentació, més exemples i menys arestes. Arribar tard a una eina bona costa poc; arribar aviat a una de dolenta costa una migració.

Aquest és l'únic apartat de la lliçó on un error té conseqüències serioses i potencialment legals.

Quan demanes ajuda, enganxes logs. I els logs d'un pipeline contenen, amb més freqüència de la que la gent creu:

• Credencials. Tokens en URL, capçaleres Authorization, cadenes de connexió amb contrasenya, claus d'accés en variables d'entorn bolcades per un env de depuració.
• Identificadors d'infraestructura. ID de compte d'AWS, ARN, noms de bucket, endpoints d'RDS, IP internes, ARN de rol d'OIDC. Individualment semblen innocus; junts són un mapa per a qui vulgui atacar-te.
• Dades personals. Un log d'un test d'integració pot portar noms, telèfons i correus reals si algú va poblar l'entorn de proves amb un bolcat de producció —pràctica més comuna del que és admissible—.
• Informació comercial. Noms de clients en rutes, en noms de branca o en identificadors de projecte.

La 04-03 et va ensenyar el mecanisme defensiu: els secrets s'emmascaren als logs del CI, es roten quan s'exposen, i Gitleaks els detecta al repositori. Però cap d'aquestes defenses no actua quan copies i enganxes un log en un fòrum. L'emmascarat de GitHub Actions només cobreix els valors registrats com a secrets en aquell repositori, no un token que una ordre va imprimir pel seu compte ni un ARN que mai no va ser secret.

Protocol abans de publicar qualsevol log o fragment de configuració:

1. Anonimitza de manera consistent. Substitueix per marcadors evidents (<ID_COMPTE>, arn:aws:iam::<COMPTE>:role/<ROL>, empresa.example.com). Consistent vol dir que el mateix valor real sigui sempre el mateix marcador; si no, el problema deixa de ser reproduïble.
2. No inventis valors plausibles. Un ARN fals però versemblant pot pertànyer a una altra empresa de debò. Fes servir example.com i <PLACEHOLDER>, que existeixen precisament per a això.
3. Retalla abans d'anonimitzar, no després. Com menys text publiquis, menys n'hi ha per revisar.
4. Llegeix-ho sencer una vegada més abans de prémer enviar, buscant específicament: password, token, key, secret, Authorization, Bearer, números de dotze dígits i adreces de correu.
5. Si dubtes, no ho publiquis. Descriu l'error amb paraules.
6. I si publiques alguna cosa per error: rota el secret immediatament i després esborra el missatge. En aquest ordre. Esborrar no desfà: el contingut pot ser a memòries cau, a clients d'escriptori, a correus de notificació i a arxius de tercers. L'única acció efectiva és invalidar la credencial. El mateix que la 04-03 deia d'un secret comès: no s'esborra, es rota.
7. Dades de clients: mai, sota cap circumstància. No és una qüestió de prudència sinó de normativa de protecció de dades, i publicar en un fòrum un log amb noms i telèfons dels clients finals de Reservalia és un incident reportable, exactament com deia la restricció 4 de l'encàrrec de la 07-06.

A l'inrevés també s'aplica. Si algú publica un secret en un canal, avisa'l en privat i immediatament. No el citis, no el comentis en públic i no el facis servir. És el que esperaries que fessin amb tu.

• Preguntar abans de cercar. Una part enorme de les preguntes ja està resposta a la primera pàgina de resultats. Cercar primer no és només cortesia: és més ràpid que esperar resposta.
• Cercar només a Google i no a l'issue tracker. Els problemes recents d'una eina són a les seves issues abans que a cap blog. És el lloc on menys gent mira i on més sol ser.
• Confondre popularitat amb adequació. Que una eina domini les converses vol dir que molta gent en parla, no que resolgui el teu problema. El mòdul 6 sencer era un exercici de separar aquestes dues coses.
• Prendre el consens d'un espai pel consens del sector. Cada comunitat té el seu biaix: el fòrum d'una eina la defensa, r/devops es queixa de tot, HN prefereix el que és nou. Triangula sempre entre almenys dos espais diferents.
• Consumir sense tornar mai res. A més de ser injust amb qui sosté això, és una pèrdua pròpia: respondre és el que fixa el que s'ha après. La primera vegada que expliquis a algú per què es promociona per digest descobriràs quines parts no tenies clares.
• Enganxar logs sense revisar. L'error d'aquesta lliçó amb conseqüències reals. Protocol de l'apartat 9, sempre, encara que tinguis pressa. Sobretot si tens pressa.
• Consell: guarda les teves pròpies respostes. Quan resolguis un problema difícil, escriu-lo on sigui cercable —el teu wiki, el teu blog, el fòrum—. El teu jo d'aquí a un any és el principal beneficiari, i de passada ajudes desconeguts.
• Consell: tria dos espais i sigues constant. Ser present en dues comunitats durant un any construeix reputació i contactes reals. Passar per deu durant un mes no construeix res.
• Consell: respon preguntes de nivell immediatament inferior al teu. És on més pots ajudar i on més aprens, perquè t'obliga a articular el que saps de manera aproximada. No cal ser expert per ajudar qui va començar fa tres mesos.

Un company publica això al canal de la comunitat:

«Bones! Tinc un problema amb Terraform, quan faig apply em dóna error de state lock i no puc desplegar. Ja vaig provar de tot, fins i tot vaig esborrar el .terraform. Algú sap com arreglar-ho? Urgeix, tenim release avui.»

Reescriu-la de manera que tingui probabilitat alta de resposta. Inventa els detalls tècnics que calguin —sent coherent amb l'stack del curs— i assenyala explícitament quina informació hi has afegit i per què cada peça importa. Afegeix també què li diries al teu company sobre dues coses concretes del seu missatge original més enllà de la manca de dades.

En un fil sobre pipelines, algú amb molts seguidors escriu:

«Regla d'or: no facis servir mai accions de tercers als teus workflows. Escriu-ho tot tu. És el que fan totes les empreses serioses, i qualsevol altra cosa és una bretxa de seguretat esperant a passar.»

Analitza el consell: quina part té fonament real (connecta-ho amb la lliçó concreta del curs), quines senyals d'alarma presenta, quin context hi falta, i com reformularies el consell perquè fos útil. Decideix després què faries tu a Mini-Reservalia i justifica-ho.

Dissenya la teva pròpia dieta d'informació per als propers sis mesos, amb un límit de tres hores setmanals en total, i justifica cada elecció en funció de la teva situació (pots fer servir la de la Nuria si prefereixes un cas concret: frontend/QA, vol moure's cap a lliurament i operació, treballa en un equip de tres). Després, tria una contribució concreta que podries fer en les properes dues setmanes a un projecte que ja facis servir, i descriu-ne el primer pas exacte.

Solució 1

Pregunta reescrita:

Assumpte: terraform apply falla amb «Error acquiring the state lock» a DynamoDB després de cancel·lar una execució a GitHub Actions

Context. Terraform 1.7.5, backend S3 amb bloqueig a DynamoDB. La infraestructura s'aplica des d'un workflow de GitHub Actions amb autenticació per OIDC. Ahir vaig cancel·lar manualment una execució del workflow que s'havia quedat penjada a l'apply.

Comportament real. Des de llavors, qualsevol terraform apply —tant des del workflow com des de la meva màquina— falla amb:

Error: Error acquiring the state lock
Lock Info:
  ID:        9f3c1a2e-...
  Operation: OperationTypeApply
  Who:       runner@fv-az512-393
  Created:   2026-07-30 09:14:22 UTC

Què he comprovat:

1. No hi ha cap altra execució del workflow en curs ni cap company aplicant.
2. L'entrada del lock continua a la taula de DynamoDB, amb l'ID que apareix a l'error.
3. Vaig esborrar el directori .terraform local i vaig executar terraform init de nou: no canvia res, cosa que té sentit perquè el lock és remot i no local.

Hipòtesi. La cancel·lació del job va matar el procés sense donar-li ocasió d'alliberar el bloqueig, i va quedar orfe.

Preguntes concretes: (a) És terraform force-unlock <ID> la manera correcta de resoldre-ho, i quin risc té si l'estat va quedar a mig escriure? (b) Com verifico abans de forçar que l'estat remot és consistent? (c) Hi ha alguna manera que el workflow alliberi el lock en cancel·lar-se?

Quina informació s'hi ha afegit i per què importa cada peça:

Les dues coses que li diria més enllà de les dades:

1. «Ja vaig provar de tot» i esborrar .terraform són el mateix senyal: estava provant accions sense model del problema. Esborrar el directori local davant d'un bloqueig remot no podia funcionar mai, i saber per què no podia funcionar és el que l'hauria portat directe a DynamoDB. Abans de provar, formular la hipòtesi: «si el lock és a DynamoDB, quina acció local el podria afectar?».
2. «Urgeix, tenim release avui» és contraproduent. No accelera ningú —qui respon ho fa gratis i en el seu temps— i sí que transmet que pot rebre consell d'emergència mal calibrat. I aquí hi ha un risc concret: la resposta ràpida és «fes force-unlock i ja», que en el pitjor cas —estat escrit a mitges— corromp l'estat remot i converteix vint minuts de problema en un dia sencer. La pressa és exactament la raó per preguntar bé, no per preguntar malament.

Solució 2

Què té de fonament. La preocupació és legítima i el curs la comparteix: la 04-03 i la 07-05 tracten les accions de tercers com una superfície d'atac real. Una acció és codi aliè executant-se al teu runner, amb accés al workspace, a les variables d'entorn i potencialment a les teves credencials. Un mantenidor compromès, o una etiqueta de versió moguda a un commit maliciós, executa codi al teu pipeline. Per això la pràctica del curs és fixar les accions per SHA complet, no per etiqueta.

Senyals d'alarma, segons la taula de l'apartat 8.1:

• «Mai»: absolut sense condició. La versió honesta té condicions.
• «És el que fan totes les empreses serioses»: apel·lació a autoritat no citada, més definició circular de «seriós». Moltíssimes organitzacions competents fan servir accions de tercers amb controls.
• Sense contrapartides: no esmenta el cost d'escriure-ho tot tu, que és enorme i continuat.
• Sense escala declarada: no diu de quina mida d'equip parla.

Quin context hi falta. El decisiu. En una organització amb equip de plataforma dedicat, mantenir accions internes és viable i probablement correcte: el cost s'amortitza entre desenes d'equips i hi ha qui les mantingui. En un equip de tres, escriure i mantenir la teva pròpia versió d'actions/checkout, setup-node o configure-aws-credentials significa mantenir codi d'infraestructura crític sense ningú que el revisi ni l'actualitzi davant de canvis de la plataforma. El resultat més probable no és més seguretat: és una acció pròpia sense mantenir i amb vulnerabilitats més antigues que les de l'ecosistema. El consell, aplicat sense context, empitjora just el que pretén millorar.

Hi falta a més una distinció crítica que el consell aplana: no totes les accions de tercers són iguals. Les oficials de GitHub (actions/*), les del proveïdor de núvol (aws-actions/*) i les de projectes amb governança sòlida no són a la mateixa categoria de risc que una acció d'un repositori personal amb dotze estrelles i sense commits en dos anys.

Reformulació útil:

«Cada acció de tercers és codi aliè amb accés al teu pipeline. Abans d'afegir-ne una, mira qui la manté, amb quina freqüència i quanta gent en depèn. Fixa sempre per SHA complet, mai per etiqueta, i automatitza l'actualització d'aquests SHA amb Dependabot o Renovate perquè fixar no signifiqui quedar-se enrere. Dóna a cada job els permisos mínims, perquè una acció compromesa no pugui fer gran cosa. Si tens equip de plataforma i molts repositoris, planteja't mantenir les teves pròpies accions internes per al que és crític; si sou pocs, escriure-les tu sol sortir pitjor perquè ningú no les mantindrà.»

Què faria a Mini-Reservalia. Continuar fent servir accions de tercers, amb els controls que ja estan implantats des de la 07-05: SHA complet a totes, permisos mínims per job, Dependabot vigilant les actualitzacions i preferència per accions oficials o amb governança clara. La restricció d'equip petit fa que escriure-ho tot sigui inviable, i el risc residual està mitigat per controls que sí que pot sostenir un equip de tres. Això, amb la seva data i la seva condició de revisió, va al PIPELINE.md: si algun dia hi ha equip de plataforma, es reavalua.

Solució 3

Dieta de la Nuria, tres hores setmanals:

Total: unes 2 h 45 min, amb marge. El que s'ha exclòs deliberadament: butlletins diaris, Twitter/X i LinkedIn com a font d'aprenentatge, i qualsevol cosa sobre eines que la Nuria no fa servir. Amb tres hores setmanals, cada minut en alguna cosa que no toca la seva feina és un minut que no dedica al que sí.

Primera contribució, amb primer pas exacte. Documentació de Playwright o d'una acció de GitHub Actions relacionada amb proves E2E.

Pas exacte per a les properes dues setmanes: la propera vegada que segueixi la documentació de Playwright per configurar alguna cosa —paral·lelització, reintents, informes a CI— i trobi un exemple que no funciona tal qual, un pas que falta o una frase ambigua, anotar-ho en el moment (això és el que es perd: l'endemà ja no ho recordes). Després, buscar el repositori de la documentació del projecte, llegir-ne el CONTRIBUTING.md sencer, comprovar si ja hi ha una issue oberta sobre això i, si no n'hi ha, obrir un PR amb la correcció mínima i una descripció de què li va passar a ella seguint el document.

Per què aquest i no un altre: és de risc baix —un canvi de documentació no pot trencar el producte de ningú—, aprofita la seva perspectiva de nouvinguda abans que se li passi, i li ensenya el flux complet de contribució (fork, branca, PR, revisió, canvis demanats, merge) sobre un canvi trivial. La segona contribució, ja amb el flux conegut, pot ser més ambiciosa.

La diferència entre qui es queda tres dies bloquejat i qui resol en dues hores gairebé mai no és el talent. És saber que el problema és de context, saber en quin espai viu aquest context i saber preguntar de manera que estalviï feina a qui respon.

L'essencial d'aquesta lliçó:

• Hi ha tres tipus de problema i només el de context exigeix comunitat. Els altres dos es resolen llegint i practicant, i confondre'ls fa perdre temps a tothom.
• Cada espai té el seu biaix declarat: els fòrums oficials són precisos sobre la seva eina i parcials sobre les altres; Stack Overflow és un arxiu excel·lent i envellit; Slack és ràpid i efímer; Reddit mesura frustració; HN mesura novetat; LinkedIn és màrqueting. Triangula sempre.
• La veritat definitiva és a les issues i els RFC dels projectes, que són la font pitjor indexada i més fiable que existeix.
• Preguntar bé és una tècnica amb parts identificables: assumpte cercable, esperat enfront de real, mínim reproduïble, versions, què has provat amb els seus resultats, hipòtesi pròpia i pregunta concreta. I sovint resol el problema abans de publicar-la.
• Contribuir des del primer dia és possible i és la via d'aprenentatge més ràpida: reproduir issues, documentació, exemples, traduccions, revisar PR. No cal ser expert; cal haver ensopegat.
• La higiene informativa es defensa amb preguntes: en quin cas no s'aplicaria?, què es perd?, de quina mida era el teu equip? Els absoluts, els arguments d'autoritat i els consells sense contrapartides són senyals d'alarma.
• I mai no es publica un log sense revisar-lo. Anonimitzar de manera consistent, rellegir buscant credencials i dades personals, i si alguna cosa s'escapa: rotar primer, esborrar després.

Els llibres de la 08-01 et donen fonament i les comunitats d'aquesta lliçó et donen context. Falta la tercera peça: les eines concretes que el curs va fregar o va deixar fora i que resolen problemes que ara saps reconèixer —gestionar secrets fora del repositori, automatitzar el canary que a la 03-04 vas configurar a mà, validar polítiques abans d'aplicar infraestructura, mesurar la cadena de subministrament amb un marc de nivells—.

Això és 08-03: Eines i Plugins Addicionals. I es presenta per problema, mai per moda: exactament la higiene que acabes d'aprendre a aplicar als consells aliens.