El Projecte | Sobre nosaltres | Contribuir | Donacions | Llicència

HOME

A la lliçó anterior vam definir què són la Integració Contínua, el Lliurament Continu i el Desplegament Continu. Ara toca la pregunta incòmoda: val la pena?. Muntar un pipeline costa temps, s'ha de mantenir, consumeix minuts de màquina que es facturen i, si es fa malament, genera més frustració que valor. Aquesta lliçó és deliberadament honesta: primer recorrerem els beneficis reals —amb el detall de com es mesura cadascun, perquè un benefici que no es mesura és una opinió—, i després posarem sobre la taula els costos i els escenaris on CI/CD aporta poc. Farem servir com a fil el cas de Reservalia, del qual coneixem el punt de partida: desplegaments manuals de 3 hores els divendres i dues incidències greus el darrer trimestre. En acabar, tindràs arguments concrets per defensar —o per descartar raonadament— una inversió en CI/CD.

Contingut

La balança: dues columnes, no una
Reducció del temps de lliurament
Detecció primerenca de defectes i el cost creixent per fase
Menys risc gràcies als lots petits
Repetibilitat i traçabilitat
Retroalimentació objectiva per a l'equip
Moral de l'equip i càrrega de l'on-call
Taula resum: benefici → com es mesura → risc si no es fa
Els costos, sense edulcorar
Quan CI/CD aporta poc
Errors comuns i consells
Exercicis
Conclusió

La balança: dues columnes, no una

La majoria de material sobre CI/CD presenta una llista de beneficis i s'hi queda. Això produeix equips que munten un pipeline per moda, l'abandonen al cap de tres mesos i conclouen que "CI/CD no funciona". La realitat és una balança:

graph LR
    subgraph BEN["✅ Beneficis"]
        B1["Lliurament mes rapid"]
        B2["Defectes detectats abans"]
        B3["Menys risc per desplegament"]
        B4["Repetibilitat i tracabilitat"]
        B5["Retroalimentacio objectiva"]
        B6["Millor moral i on-call"]
    end
    subgraph COST["💸 Costos"]
        C1["Muntatge inicial"]
        C2["Manteniment continu"]
        C3["Minuts de runner"]
        C4["Proves inestables flaky"]
        C5["Corba d aprenentatge"]
    end
    BEN --- BAL{{"Val la pena<br/>en EL TEU context?"}}
    COST --- BAL

La resposta sol ser "sí", però no sempre, i és clar que no en la mateixa mesura per a un equip de 3 persones amb un projecte intern que per a un de 40 amb un SaaS de pagament. La secció 10 aborda les excepcions.

Reducció del temps de lliurament

2.1. On se'n va el temps realment

El temps de lliurament no és el temps de programar. És el temps total des que el codi està escrit fins que l'usuari l'està fent servir. A Reservalia, avui, aquest recorregut és així:

gantt
    title Cicle actual de Reservalia: de commit a produccio
    dateFormat  YYYY-MM-DD
    axisFormat  %d/%m
    section Desenvolupament
    Diego programa la funcionalitat   :a1, 2026-03-02, 3d
    section Espera
    Espera al divendres de desplegament :crit, a2, after a1, 6d
    section Desplegament manual
    Compilar, SFTP, migracions (3 h)  :a3, after a2, 1d

Fixa't on hi ha el bloc més llarg: no és programar, és esperar. El canvi d'en Diego està acabat el dimarts i arriba als usuaris el divendres de la setmana següent. La finestra de desplegament imposa una espera de fins a 9 dies per a un canvi que triga 3 dies a escriure's.

I aquesta espera no és neutral: mentre el canvi espera, s'acumula amb altres canvis i forma el lot gran del qual parlarem a la secció 4.

2.2. Què canvia amb CI/CD

Un pipeline automatitzat ataca dues coses alhora:

Elimina la finestra d'espera. Si desplegar costa 8 minuts i no requereix que ningú es coordini, no cal agrupar desplegaments els divendres.
Elimina el temps d'execució manual. Les 3 hores d'en Diego passen a ser temps de màquina, i a més temps de màquina en paral·lel amb altra feina.

L'abans/després de Reservalia, amb les xifres del seu propi cas:

Concepte	Abans (manual)	Després (objectiu del curs)
Durada del desplegament	3 hores de feina d'una persona	~8 minuts de màquina, 0 minuts de persona
Freqüència de desplegament	1 per setmana (divendres)	Diverses al dia
Espera mitjana d'un canvi acabat	fins a 5 dies laborables	minuts
Persones bloquejades durant el desplegament	1 (en Diego), a vegades 2	0
Cost anual del desplegament en hores d'en Diego	~52 desplegaments × 3 h = 156 hores	~4 hores de supervisió ocasional

Aquestes 156 hores són gairebé un mes de feina a jornada completa dedicat exclusivament a copiar fitxers. És la xifra que la Marta portarà a la reunió de pressupost.

Compte amb les xifres. Les d'aquesta taula surten del cas de Reservalia, que és fictici però coherent. Evita citar percentatges genèrics del tipus "CI/CD millora la productivitat un 40 %": són números que circulen sense font i que no resisteixen una pregunta. Mesura el teu procés. La lliçó 01-05 et donarà l'instrumental per fer-ho.

Detecció primerenca de defectes i el cost creixent per fase

3.1. El principi del cost creixent

Un defecte no costa el mateix segons quan es descobreix. La raó és purament pràctica: com més tard apareix, més context s'ha perdut i més persones hi ha implicades.

Moment de detecció	Qui l'arregla	Context que té	Cost típic	Efectes secundaris
En escriure el codi (IDE, linter, tipus)	L'autor	Total: acaba d'escriure'l	Segons	Cap
Al pipeline de CI (minuts després)	L'autor	Alt: recorda el canvi	Minuts	Cap; el canvi no ha arribat a `main`
En revisió de codi (hores després)	L'autor + revisor	Alt	Desenes de minuts	Ocupa dues persones
A staging (dies després)	L'autor, si continua disponible	Mitjà: ha canviat de tasca	Hores	Bloqueja la release
En producció (setmanes després)	Qui estigui de guàrdia	Baix o nul: pot no ser l'autor	Hores o dies	Incident, usuaris afectats, possible pèrdua de dades, comunicació de crisi, anàlisi post mortem

No cal cap estudi per entendre la corba: arreglar una fallada que descobreixes al cap de 4 minuts d'escriure-la és incomparablement més barat que arreglar la mateixa fallada tres setmanes després, de matinada, en una base de codi que ja ha canviat.

graph LR
    A["💡 IDE<br/>segons"] --> B["🔄 CI<br/>minuts"] --> C["👀 Revisio<br/>hores"] --> D["🧪 Staging<br/>dies"] --> E["🔥 Produccio<br/>setmanes"]
    style A fill:#d9f2d9
    style B fill:#e8f5c8
    style C fill:#fff2cc
    style D fill:#ffe0cc
    style E fill:#ffd6d6

La Integració Contínua actua desplaçant la detecció cap a l'esquerra d'aquesta línia. En anglès se'n diu shift left, i és la raó principal per la qual CI existeix.

3.2. El cas concret de Reservalia

Una de les dues incidències greus del trimestre va ser aquesta: en Diego va canviar el tipus de la columna duracio_minuts d'integer a numeric per admetre cites de 90,5 minuts. Hi havia un test que ho detectava... però ningú no va executar els tests aquell divendres. L'aplicació va estar retornant error 500 en crear qualsevol cita durant 40 minuts, fins que un client va trucar.

Amb CI, aquesta fallada s'hauria manifestat abans de fusionar el pull request, amb en Diego mirant la pantalla i el context fresc. Cost: cinc minuts. Sense CI: 40 minuts de caiguda, reserves perdudes, una trucada d'un client enfadat i una tarda de post mortem.

La diferència no està en la qualitat del test. El test ja existia. La diferència està en què un humà s'ha de recordar d'executar-lo, i un pipeline no.

Menys risc gràcies als lots petits

4.1. La mida del lot governa el risc

Quan en Diego desplega el divendres, no desplega un canvi: desplega tot el que s'ha acumulat durant la setmana. Suposem 14 commits de 3 persones.

Si alguna cosa es trenca, quin dels 14 canvis n'és el culpable? Ningú no ho sap. Comença la fase de bisecció manual, en producció, amb usuaris afectats i pressa.

Comparem les dues maneres de treballar:

Aspecte	Lot gran (1 desplegament/setmana, 14 commits)	Lot petit (diversos desplegaments/dia, 1-2 commits)
Canvis per desplegament	14	1-2
Superfície de risc	Alta: 14 coses poden fallar alhora	Baixa
Diagnòstic d'una fallada	Cal descartar 14 candidats	El culpable és evident
Rollback	Reverteix també 13 canvis bons	Reverteix exactament el que falla
Pressió sobre qui desplega	Molt alta: si falla, és la setmana sencera	Baixa
Probabilitat que el desplegament falli	Alta (risc acumulat)	Baixa

La paradoxa que a molta gent li costa acceptar és aquesta: desplegar més vegades redueix el risc total, encara que augmenti el nombre de desplegaments. Perquè el risc no està en l'acte de desplegar, sinó en la quantitat de canvi no verificat que aquest acte allibera de cop.

graph TD
    subgraph L["Lot gran"]
        L1["14 commits"] --> L2["1 desplegament"] --> L3{"Falla?"}
        L3 -->|"si"| L4["😱 quin dels 14?<br/>rollback total"]
    end
    subgraph P["Lot petit"]
        P1["1 commit"] --> P2["1 desplegament"] --> P3{"Falla?"}
        P3 -->|"si"| P4["😌 es AQUEST commit<br/>rollback quirurgic"]
    end
    style L4 fill:#ffd6d6
    style P4 fill:#d9f2d9

4.2. El corol·lari per a Reservalia

Les dues incidències greus del trimestre van passar totes dues en un desplegament de divendres. No és casualitat estadística: els únics desplegaments que fan són de divendres, i cadascun d'ells allibera una setmana de canvis sense verificar. Reduir la mida del lot és la palanca més directa que té l'equip per reduir el seu change failure rate (el mesurarem a 01-05).

Repetibilitat i traçabilitat

5.1. Repetibilitat: el procés no depèn de qui l'executa

Avui a Reservalia, si en Diego està de vacances, ningú no sap desplegar. El coneixement viu al seu cap i en un document de Notion desactualitzat. Això és un risc de negoci, no només tècnic: se'n diu bus factor d'1.

Un pipeline converteix aquest coneixement tàcit en codi versionat i executable:

És al repositori, qualsevol el llegeix.
Es revisa en pull requests, com qualsevol altre canvi.
S'executa igual el llanci qui el llanci.
Si alguna cosa canvia al procés, queda registrada a l'historial amb autor i motiu.

5.2. Traçabilitat: respondre preguntes que avui no tenen resposta

Aquestes són preguntes que la Nuria, la SRE, no pot respondre avui i que amb un pipeline es contesten en segons:

Pregunta	Avui a Reservalia	Amb un pipeline
Quina versió exacta hi ha en producció?	"La del darrer divendres, em sembla"	El SHA `a3f9c21`, etiquetat a l'artefacte
Qui va desplegar i quan?	En Diego, en algun moment de la tarda	Registre del pipeline amb usuari, data i hora exacta
Quins canvis inclou aquest desplegament?	Caldria reconstruir-ho a mà	El diff entre el SHA anterior i l'actual
Va passar les proves aquesta versió?	Depèn de si algú se'n va recordar	Sí o no, amb l'informe adjunt
Podem tornar a la versió anterior?	Recompilar i tornar a pujar per SFTP (~1 h)	Redesplegar l'artefacte anterior (minuts)
Es va aplicar la migració `0042`?	Mirar la consola de psql i confiar	Registrat a la taula de migracions

Un exemple de la informació que un pipeline deixa registrada per cada desplegament —farem servir aquesta estructura a la lliçó 01-05 per calcular mètriques:

{
  "desplegament_id": "dep_2026_0314_1042",
  "servei": "reservalia-api",
  "entorn": "prod",
  "commit_sha": "a3f9c21e4b7d8f012345678901234567890abcde",
  "commit_data": "2026-03-14T10:22:41+01:00",
  "artefacte": "123456789.dkr.ecr.eu-west-1.amazonaws.com/reservalia/api:a3f9c21",
  "desplegat_per": "github-actions[bot]",
  "desplegat_el": "2026-03-14T10:42:03+01:00",
  "resultat": "exit",
  "pipeline_url": "https://github.com/reservalia/reservalia/actions/runs/8421",
  "commits_inclosos": 2
}

Només amb aquest registre, repetit a cada desplegament, ja pots respondre a totes les preguntes de la taula anterior. I a més, com veurem, calcular tres de les quatre mètriques DORA.

Retroalimentació objectiva per a l'equip

Un dels beneficis menys citats i més transformadors: el pipeline substitueix opinions per fets.

Sense CI, les converses d'un equip sonen així:

— "Jo crec que això està a punt."
— "A mi ahir em funcionava."
— "Caldria provar-ho més a fons, no?"

Amb CI, sonen així:

— "El PR és verd: build, 340 tests, cobertura i lint."
— "Falla crearCita › rebutja solapaments, línia 88."

La diferència és que la segona conversa no té ego. El pipeline no critica ningú: informa. Això té tres efectes concrets:

Despersonalitza la crítica. No és "la Marta diu que el teu codi està malament": és "el pas de tipus ha fallat". La revisió humana queda lliure per al que de debò aporta —disseny, llegibilitat, decisions de producte— en comptes de gastar-se en format i errades.
Dona un criteri de "fet" compartit. Definir fet com "el pipeline és verd i el PR aprovat" elimina discussions interminables.
Fa visible l'estat real del projecte. Qualsevol pot mirar l'historial d'execucions i veure si el projecte està sa o si fa tres dies que està en vermell.

Moral de l'equip i càrrega de l'on-call

Aquest benefici és difícil de quantificar i, tanmateix, sol ser el que decideix si un equip persevera amb CI/CD o l'abandona.

7.1. La factura oculta del desplegament manual

Torna al divendres a la tarda d'en Diego. El que el full de càlcul no recull:

Ansietat anticipatòria. Des de dijous, en Diego sap que l'espera el divendres. Treballa pitjor el dijous.
Cap de setmana condicionat. Si alguna cosa es trenca el divendres a les 19:00, es trenca el cap de setmana d'algú.
Por de canviar coses. Quan desplegar fa por, la gent evita refactoritzar, evita actualitzar dependències i acumula deute tècnic. La por del desplegament es converteix en un impost sobre la qualitat del codi.
Concentració de coneixement. En Diego és l'únic que sap desplegar i això, que sembla poder, a la pràctica és una cadena: no pot desconnectar de debò a les vacances.
Rotació. L'esgotament per incidents evitables és una de les raons habituals per les quals la gent canvia de feina. Substituir un desenvolupador costa mesos de productivitat.

7.2. Què canvia per a l'on-call

La Nuria, que porta les guàrdies, obté millores molt concretes:

Situació	Sense CI/CD	Amb CI/CD
Detecció del problema	Trucada d'un client	Alerta automàtica (ho veurem a 03-06)
Identificar el canvi culpable	Revisar 14 commits del lot	1-2 commits, evident
Revertir	Recompilar i pujar per SFTP, ~1 h	Redesplegar l'artefacte anterior, minuts
Necessitat de despertar l'autor	Alta: només ell sap què va tocar	Baixa: el rollback és mecànic
Sensació durant la guàrdia	"Tant de bo no passi res"	"Si passa, hi ha un procediment"

La frase que resumeix el canvi cultural: un bon sistema de CI/CD converteix una emergència en un procediment.

7.3. Un advertiment important

CI/CD no arregla una cultura d'equip trencada. Si a la teva organització es culpa les persones pels incidents, automatitzar el desplegament només farà que les culpes arribin més de pressa. L'automatització amplifica la cultura existent: si és sana, la reforça; si és tòxica, l'accelera.

Taula resum: benefici → com es mesura → risc si no es fa

Aquesta taula és el resum executiu de la lliçó. És exactament el material que la Marta necessita per justificar la inversió:

Benefici	Com es mesura	Risc si no es fa
Lliurament més ràpid	Temps des del commit fins a producció (lead time); freqüència de desplegament	Les funcionalitats triguen setmanes a arribar; la competència es mou abans; la retroalimentació dels usuaris arriba tard per corregir el rumb
Detecció primerenca de defectes	% de fallades detectades en CI davant de les detectades en producció; temps mitjà des que s'introdueix una fallada fins que es detecta	Els defectes arriben als usuaris; el cost d'arreglar-los es multiplica; s'erosiona la confiança en el producte
Menys risc per lot petit	Nre. de commits per desplegament; % de desplegaments que provoquen incident (change failure rate)	Cada desplegament és un esdeveniment d'alt risc; els diagnòstics són lents; els rollbacks arrosseguen canvis bons
Repetibilitat	% de passos del desplegament automatitzats; nre. de persones capaces de desplegar (bus factor)	El procés depèn d'una persona; impossible desplegar en vacances o baixes; el coneixement es perd amb la rotació
Traçabilitat	Es pot respondre en <1 min quin SHA hi ha en producció i què conté? (sí/no)	Auditories impossibles; diagnòstics a cegues; incompliment de requisits normatius en sectors regulats
Retroalimentació objectiva	Temps mitjà de resposta del pipeline en un PR; % de PR amb pipeline verd abans de fusionar	Les revisions es gasten en errades; els desacords es resolen per jerarquia i no per evidència
Moral i on-call	Nre. d'incidents fora d'horari; temps de restauració del servei; enquestes internes de confiança en el desplegament	Esgotament, rotació, por de canviar codi, deute tècnic creixent

La manera estàndard i reconeguda al sector de mesurar diversos d'aquests beneficis són les mètriques DORA (freqüència de desplegament, lead time for changes, change failure rate i time to restore service). Les desenvoluparem en detall a la lliçó 01-05, juntament amb la manera pràctica d'instrumentar-les a Reservalia. De moment queda't amb què existeixen i amb què donen un llenguatge comú per parlar d'això amb direcció.

Els costos, sense edulcorar

Tot l'anterior té una factura. Ignorar-la és la via ràpida a l'abandonament del pipeline al cap de tres mesos.

9.1. Cost de muntatge inicial

Escriure el primer pipeline útil no són dues tardes. Per a un projecte de la mida de Reservalia, un càlcul realista:

Tasca	Esforç orientatiu
Primer flux de treball de build + tests	1-2 dies
Contenidoritzar l'aplicació (Dockerfile funcional i lleuger)	2-4 dies
Gestió de secrets i credencials d'AWS	1-2 dies
Desplegament automatitzat a un entorn (staging)	3-5 dies
Migracions de base de dades automatitzades i segures	3-5 dies
Desplegament a producció amb rollback	3-5 dies
Total orientatiu	3-5 setmanes d'una persona, repartides

I hi ha un cost afegit difícil d'empassar: durant aquestes setmanes, conviuen els dos processos. Continues desplegant a mà mentre construeixes l'automàtic. És feina doble temporal, i és la fase en què més projectes s'abandonen.

9.2. Cost de manteniment

El pipeline és programari i, com tot programari, es podreix si no se'n té cura:

Les accions i plugins de tercers publiquen versions noves i abandonen les antigues.
Les imatges base dels runners canvien (una actualització del sistema operatiu del runner pot trencar una build).
Les versions de Node, Python o Java arriben a final de vida.
Les credencials caduquen i cal rotar-les.
Cada nova funcionalitat del producte pot requerir un pas nou al pipeline.

Compta amb mig dia al mes de manteniment per a un projecte petit, més els pics quan canvia alguna cosa grossa. Ho tractarem a fons al mòdul 4.

9.3. Cost d'execució: els minuts de runner

Això són diners comptants. Els proveïdors de CI/CD allotjats facturen per minut d'execució, i les quotes gratuïtes s'esgoten abans del que sembla.

Fem el càlcul per a Reservalia:

# Supostos de Reservalia (equip de 3 persones):
#   - 6 pull requests al dia
#   - cada PR s actualitza 2 vegades de mitjana → 12 execucions/dia per PR
#   - 4 fusions a main al dia → 4 execucions del pipeline complet
#   - 20 dies laborables al mes

# Durada de cada tipus d execucio:
#   pipeline de PR (build + tests + lint)      → 8 min
#   pipeline de main (tot + build d imatge)    → 14 min

# Minuts de PR al mes:
#   12 execucions/dia × 8 min × 20 dies = 1.920 min
# Minuts de main al mes:
#   4 execucions/dia × 14 min × 20 dies = 1.120 min
# TOTAL ≈ 3.040 minuts/mes

Tres mil minuts al mes en un projecte petit. Amb runners de mida més gran (més CPU i RAM), el preu per minut es multiplica. I hi ha un multiplicador que sorprèn molta gent: en una matriu de builds (per exemple, provar en Node 18, 20 i 22 × Linux i macOS), els minuts es multipliquen pel nombre de combinacions, i els runners de macOS se solen facturar a un múltiple del preu de Linux.

Les palanques per controlar-ho —memòria cau de dependències, execució condicional per carpetes modificades, cancel·lar execucions obsoletes, paral·lelitzar bé— són matèria del mòdul 4, lliçó 04-04.

9.4. Cost de les proves inestables (flaky)

Una prova flaky és la que a vegades passa i a vegades falla sense que el codi hagi canviat. Causes típiques: dependències del rellotge, esperes fixes en proves d'interfície, ordre d'execució, estat compartit a la base de dades, condicions de carrera, crides a serveis externs.

Són el verí més eficaç contra un pipeline, i el mecanisme és psicològic:

graph TD
    A["Un test falla<br/>intermitentment"] --> B["L equip apren:<br/>reintenta i ja passa"]
    B --> C["Es normalitza<br/>ignorar el vermell"]
    C --> D["Una fallada REAL<br/>s ignora tambe"]
    D --> E["🔥 La fallada arriba<br/>a produccio"]
    E --> F["El CI no serveix<br/>per a res"]
    F --> G["Es desactiven tests<br/>o s ignora el pipeline"]
    style E fill:#ffd6d6
    style G fill:#ffd6d6

El dany no és el temps perdut en reintents: és que destrueixen el senyal. Un pipeline en què no es confia és pitjor que no tenir pipeline, perquè costa diners i dona falsa seguretat. L'única política sostenible és tractar un test flaky com una fallada de prioritat alta: s'arregla o es posa en quarantena explícita amb un termini, mai no es "reintenta i a una altra cosa". Ho abordarem a la lliçó 02-04.

9.5. Corba d'aprenentatge i cost cognitiu

Afegir CI/CD afegeix un sistema més que l'equip ha d'entendre: YAML amb la seva sintaxi i els seus paranys, el model d'execució de l'eina, contenidors, gestió de secrets, permisos al núvol. Per a un equip júnior, això és real i cal pressupostar-ho. La bona notícia és que és coneixement transferible: els conceptes del mòdul 1 valen per a qualsevol eina, com veurem a 01-03.

Quan CI/CD aporta poc

Amb honestedat, hi ha contextos on la inversió no compensa —o compensa només en part:

Context	Per què aporta poc	Què fer al seu lloc
Prototip o prova de concepte que es llençarà en dues setmanes	El pipeline sobreviurà al projecte	Executar els tests a mà; com a molt, un flux de treball de 10 línies que executi `npm test`
Projecte d'una sola persona sense usuaris reals	No hi ha integració a fer: no hi ha amb qui integrar	Un CI mínim aporta igualment xarxa de seguretat; el CD, poc
Programari amb cicles de release molt llargs per regulació (dispositius mèdics, aviònica, banca crítica)	El desplegament continu a producció és directament il·legal o impracticable	CI completa i Lliurament Continu fins a l'entorn previ; la porta manual és un requisit, no una fallada
Sistemes encastats o distribució física	El "desplegament" implica maquinari o distribució física	CI i construcció automatitzada de microprogramari sí que aporten; el CD no aplica igual
Aplicacions mòbils a botigues	La revisió de la botiga imposa dies de latència	CI i lliurament automatitzat a canals de prova interns; desplegament continu pur, no. Ho veurem a 05-02
Base de codi sense cap prova automatitzada	Un pipeline verd que no prova res dona falsa confiança, que és pitjor que cap	Invertir primer en tests de les rutes crítiques; després automatitzar-los
Equip en crisi, amb la casa cremant	No hi ha capacitat per a un projecte paral·lel de 4 setmanes	Començar pel mínim: un flux de treball que executi els tests a cada PR. Això sol ja canvia molt

Fixa't en un matís que apareix diverses vegades: fins i tot on el Desplegament Continu no aplica, la Integració Contínua gairebé sempre sí. L'esglaó de baix de la piràmide de 01-01 és rendible pràcticament en qualsevol context amb més d'una persona i més d'un mes de vida.

Errors Comuns i Consells

Error 1: vendre CI/CD amb xifres genèriques d'internet. "Els equips que fan CI/CD despleguen 200 vegades més" és un titular sense context. Si el portes a una reunió, la primera pregunta serà "d'on surt?" i no tindràs resposta. Porta els teus números: 156 hores l'any d'en Diego copiant fitxers és un argument que ningú no discuteix.

Error 2: presentar només la columna de beneficis. Si promets que tot serà més ràpid i omets les 4 setmanes de muntatge i els 3.000 minuts al mes, la primera factura destruirà la teva credibilitat. Presenta la balança completa; dona molta més confiança.

Error 3: mesurar l'èxit per "tenim pipeline". Tenir un ci.yml no és un resultat. Els resultats són: el lead time va baixar de 9 dies a 2 hores, o el nombre de desplegaments fallits va caure de 2 per trimestre a 0. Defineix la mètrica abans de començar.

Error 4: automatitzar el desplegament abans de tenir proves. És l'ordre equivocat i el més freqüent. Automatitzar un desplegament sense proves fiables només aconsegueix portar els errors a producció més de pressa i més sovint. Primer proves, després automatització del desplegament.

Error 5: tolerar tests flaky "temporalment". Aquest "temporalment" es converteix en permanent al cap de tres setmanes i arrossega la credibilitat del pipeline sencer. Tracta'ls com a bugs de prioritat alta des del primer dia.

Consell 1: mesura la teva línia base aquesta mateixa setmana. Cronometra el proper desplegament manual. Compta quants dies passen entre commit i producció en els últims 10 canvis. Sense línia base, d'aquí a sis mesos no podràs demostrar res.

Consell 2: comença pel pas més dolorós. No intentis muntar el pipeline complet. Si el que més fa mal és que ningú no executa els tests, comença per un flux de treball que executi els tests a cada PR. Un benefici visible la primera setmana compra el suport de l'equip per a la resta.

Consell 3: pressuposta el manteniment des del principi. Reserva mig dia al mes a la planificació. Si el manteniment del pipeline és sempre feina "que es fa als forats", no es farà mai i el pipeline es degradarà fins que algú el desactivi.

Consell 4: compta també els beneficis no tècnics. Que en Diego pugui anar-se'n de vacances sense ser l'únic que sap desplegar és un benefici de continuïtat de negoci. Sol convèncer la direcció més que qualsevol argument tècnic.

Exercicis

Exercici 1: construir el cas de negoci de Reservalia

La Marta té 15 minuts amb la direcció per demanar 4 setmanes de feina d'en Diego dedicades a muntar el pipeline. Amb les dades del cas —desplegaments setmanals de 3 hores, dues incidències greus el darrer trimestre, equip de 3 persones—, prepara:

El cost anual actual en hores del procés manual de desplegament.
Una estimació del cost de la inversió (muntatge + manteniment del primer any), en hores.
El punt d'equilibri: a partir de quants mesos la inversió s'ha pagat sola, comptant només el temps de desplegament?
Dos beneficis que no apareixen en aquest càlcul però que hauries de mencionar igualment.

Suposa una jornada de 8 hores i 20 dies laborables al mes.

Exercici 2: decidir en quatre escenaris

Per a cada escenari, decideix què recomanaries —CI completa, CI + Lliurament Continu, Desplegament Continu o res de moment— i justifica-ho en dues o tres frases:

Una desenvolupadora freelance manté un blog personal generat estàticament. Publica un article al mes. No té tests.
Una startup de 12 persones amb un SaaS B2B de pagament. Tenen 400 tests i una cobertura raonable. Despleguen cada dues setmanes, amb estrès.
Un equip de 8 persones que desenvolupa el programari de dosificació d'una bomba d'infusió hospitalària. Cada versió requereix certificació d'un organisme regulador.
Un equip de 5 persones que ha heretat un monòlit PHP de 12 anys sense cap prova automatitzada. Despleguen per FTP i volen "posar CI/CD ja".

Exercici 3: diagnosticar un pipeline que ha deixat d'aportar

L'equip d'una altra empresa, Citalia, va muntar CI/CD fa 8 mesos. Aquestes són les seves dades actuals:

El pipeline triga 47 minuts en un pull request.
De les últimes 100 execucions, 31 van fallar; en reintentar-les sense canviar res, 26 van passar.
La política de l'equip és "si falla, dona-li a Re-run jobs".
La factura de minuts de runner ha pujat un 80 % en 4 mesos.
La setmana passada va arribar a producció un bug que tenia un test que el cobria.

Respon:

Quin és el problema arrel i quines en són conseqüències?
Quin benefici dels d'aquesta lliçó han perdut, encara que el pipeline "funcioni"?
Proposa tres accions ordenades per prioritat.

Solucions

Solució a l'Exercici 1

1. Cost anual actual del desplegament manual

# Desplegaments: 1 per setmana × 52 setmanes = 52 desplegaments/any
# Durada: 3 hores cadascun
52 × 3 = 156 hores/any d en Diego

# Incidencies: 2 greus per trimestre = 8 a l any
# Cost realista per incidencia greu (diagnostic + arranjament + desplegament
# d urgencia + post mortem), repartit entre les persones implicades: ~6 h
8 × 6 = 48 hores/any

# COST ANUAL TOTAL ≈ 204 hores ≈ 25,5 jornades ≈ 1,3 mesos de feina

2. Cost de la inversió (primer any)

# Muntatge: 4 setmanes × 5 dies × 8 h
4 × 5 × 8 = 160 hores

# Manteniment: 0,5 dies/mes × 12 mesos × 8 h
0,5 × 12 × 8 = 48 hores

# Minuts de runner: cost monetari, no d hores.
# S estima a part (≈ 3.000 min/mes) i es declara explicitament.

# INVERSIO PRIMER ANY ≈ 208 hores

3. Punt d'equilibri

# Estalvi mensual estimat (nomes temps de desplegament):
#   abans: 4,3 desplegaments/mes × 3 h = 13 h/mes
#   despres: ~0,3 h/mes de supervisio
#   estalvi ≈ 12,7 h/mes

# Si hi afegim la reduccio d incidencies (suposem que passen de 8 a 3
# a l any, es a dir de 4 h/mes a 1,5 h/mes de cost): +2,5 h/mes
# Estalvi total ≈ 15 h/mes

# Punt d equilibri: 208 h d inversio ÷ 15 h/mes estalviades
208 / 15 ≈ 14 mesos (comptant el manteniment del primer any)

# Si nomes es compta el muntatge (160 h), l equilibri arriba abans:
160 / 15 ≈ 11 mesos

Interpretació honesta: el retorn purament comptable arriba al voltant del primer any. Això és important i cal dir-ho: si véns "es paga en dos mesos", quedes retratat. El que fa que la inversió valgui clarament la pena són els beneficis que no són en aquest compte.

4. Beneficis fora del càlcul

Reducció del risc de negoci: les incidències en producció d'una plataforma de reserves no costen només hores d'enginyeria; costen cites perdudes per als clients de Reservalia i reputació. Una caiguda de 40 minuts en horari comercial afecta reserves reals.
Eliminació del bus factor: avui, si en Diego es posa malalt, Reservalia no pot desplegar ni tan sols una correcció crítica. Això és un risc de continuïtat de negoci, no un inconvenient.
Velocitat de reacció: amb desplegament automatitzat, corregir un bug detectat a les 10:00 és qüestió de minuts, no d'esperar al divendres.
Capacitat de créixer: el procés actual no escala a 6 persones. Si Reservalia contracta, el coll d'ampolla és estructural.

Solució a l'Exercici 2

Blog personal estàtic: res de moment, o un CI mínim. Un article al mes, sense tests, sense usuaris que en depenguin. El màxim justificable és un flux de treball trivial que construeixi el lloc i desplegui l'HTML —que, de fet, molts allotjaments estàtics ja ofereixen sense configuració. Muntar un pipeline elaborat aquí és un exercici d'aprenentatge, no una necessitat.
Startup SaaS B2B: CI completa + Lliurament Continu, amb vista al Desplegament Continu. És l'escenari on CI/CD rendeix més. Tenen tests i cobertura raonable —la base necessària— i l'estrès de les releases quinzenals indica lots massa grans. Recomanació: CI a cada PR des d'ara, i automatitzar el desplegament fins a staging i fins a producció amb porta manual. Quan el change failure rate baixi de manera sostinguda, es poden plantejar treure la porta.
Bomba d'infusió hospitalària: CI completa, Lliurament Continu fins a l'entorn de validació, i Desplegament Continu descartat. El marc regulador exigeix evidència documentada i certificació per versió; desplegar automàticament és inviable. Però CI aporta moltíssim aquí: proves exhaustives automatitzades, traçabilitat completa de què es va construir i amb què (justament el que un auditor demana), i builds reproduïbles. La porta manual no és una mancança del pipeline: és un requisit del domini.
Monòlit PHP sense tests: CI mínima, però l'ordre importa. L'error seria automatitzar el desplegament primer: aconseguirien portar errors a producció més de pressa. Ordre recomanat: (a) muntar el pipeline de build i execució de tests, encara que al principi gairebé no hi hagi tests; (b) afegir tests de les 5-10 rutes crítiques de negoci —allò que un usuari no pot deixar de poder fer—; (c) afegir anàlisi estàtica, que dona valor immediat sense escriure tests; (d) només llavors, automatitzar el desplegament, començant per un entorn que no sigui producció. Aquest cas concret el desenvoluparem a la lliçó 05-04.

Solució a l'Exercici 3

1. Problema arrel i conseqüències

El problema arrel són les proves inestables (flaky): de 31 fallades, 26 van passar en reintentar sense tocar res. Això significa que aproximadament el 84 % de les fallades són soroll. Tota la resta és conseqüència:

La política de "dona-li a Re-run" és una adaptació de l'equip al soroll, no una causa.
La factura de runners va pujar un 80 % en part pels reintents d'execucions de 47 minuts.
El bug que va arribar a producció tenint un test que el cobria és la conseqüència final i previsible: el test va fallar de debò, algú va reintentar per costum, va colar al segon intent o es va ignorar el vermell.

Hi ha un problema secundari i independent: 47 minuts de pipeline en un PR és massa. Trenca el bucle de retroalimentació ràpida —la gent canvia de tasca mentre espera— i multiplica el cost de cada reintent.

2. Benefici perdut

Han perdut la retroalimentació objectiva (secció 6) i, amb ella, la detecció primerenca de defectes (secció 3). El pipeline continua executant-se, però ha deixat de ser un senyal fiable: un vermell ja no significa "hi ha un problema", significa "torna-ho a intentar". En el moment en què l'equip deixa de creure's el resultat, el pipeline passa d'actiu a passiu: costa diners i dona falsa seguretat. Estan pagant la columna de costos íntegra sense cobrar la de beneficis.

3. Accions per prioritat

Prohibir el reintent cec i posar els flaky en quarantena. Instrumentar la detecció de tests inestables (marcar els que fallen i passen sense canvi de codi), treure'ls del conjunt bloquejant i posar-los en una llista explícita amb responsable i data límit. Objectiu immediat: que un vermell torni a significar alguna cosa. Sense això, res més no importa.
Arreglar els flaky de debò, començant pels més freqüents. Se solen concentrar en uns quants: esperes fixes, dependències del rellotge, estat compartit entre tests. Atacar el top 5 elimina normalment la major part del soroll.
Reduir el temps del pipeline per sota de 10-15 minuts en PR. Paral·lelitzar jobs, posar en memòria cau les dependències, executar només allò afectat pels fitxers modificats, i moure els conjunts lents (end-to-end completes) a una execució posterior al merge o nocturna. Això redueix alhora la factura i la temptació de saltar-se el procés.

Una quarta acció de reforç: publicar un quadre de comandament amb el percentatge d'execucions verdes a la primera. És la mètrica que fa visible si el problema està millorant o no.

Conclusió

En aquesta lliçó hem posat la balança completa sobre la taula:

Els beneficis són reals i mesurables: lliurament més ràpid (Reservalia recupera ~156 hores l'any només en temps de desplegament), detecció primerenca de defectes —el cost dels quals creix dràsticament amb cada fase que travessen—, menys risc per lots petits, repetibilitat que elimina el bus factor, traçabilitat que respon preguntes avui impossibles, retroalimentació objectiva que despersonalitza la crítica, i un impacte directe en la moral de l'equip i en la càrrega de les guàrdies.
Cada benefici té la seva manera de mesurar-se. Un benefici que no es mesura és una opinió, i les opinions no sobreviuen a una revisió de pressupost.
Els costos també són reals: setmanes de muntatge, manteniment continu, milers de minuts de runner al mes fins i tot en projectes petits, i sobretot el verí de les proves inestables, que destrueixen el senyal i amb ell tot el valor del sistema.
CI/CD no és universalment rendible. En prototips, projectes individuals o programari fortament regulat, la part de desplegament continu aporta poc. La Integració Contínua, en canvi, és rendible en gairebé qualsevol context amb més d'una persona implicada.

Hem mencionat diverses vegades que existeix una manera estàndard de mesurar tot això: les mètriques DORA. Hi dedicarem la lliçó 01-05 sencera.

Però abans de mesurar res cal decidir amb quina eina construirem el pipeline, i el panorama és ampli i confús: GitHub Actions, GitLab CI, Jenkins, CircleCI, Argo CD, Tekton... A la lliçó següent, Eines Populars de CI/CD, dibuixarem el mapa complet de l'ecosistema, veurem quines categories existeixen i en què es diferencien realment, i justificarem per què aquest curs farà servir GitHub Actions com a eina principal.

Beneficis del CI/CD