Si has arribat fins aquí és perquè en algun moment has viscut —o t'han explicat— una escena semblant a aquesta: divendres a la tarda, algú compila el projecte al seu portàtil, puja els fitxers a un servidor i creua els dits. Aquesta lliçó és el punt de partida per deixar enrere aquesta escena. Definirem amb precisió què signifiquen les sigles CI/CD, distingirem les tres pràctiques que s'hi amaguen al darrere (perquè són tres, no dues) i fixarem el vocabulari que farem servir durant tot el curs. No és una lliçó d'eines ni de configuració: és la lliçó que fa que tota la resta tingui sentit. Si confons Lliurament Continu amb Desplegament Continu —l'error més habitual del sector—, la resta del curs et sonarà a soroll. Quan acabis, sabràs anomenar cada peça del procés i entendràs per què l'equip del nostre projecte d'exemple, Reservalia, té un problema seriós.

1. El problema que CI/CD ve a resoldre
2. Què és la Integració Contínua (CI)
3. Què és el Lliurament Continu (Continuous Delivery)
4. Què és el Desplegament Continu (Continuous Deployment)
5. Les dues "CD" cara a cara
6. El flux complet: de commit a producció
7. Vocabulari base del curs
8. Errors comuns i consells
9. Exercicis
10. Conclusió

Durant tot el curs treballarem sobre un projecte fictici anomenat Reservalia, una plataforma SaaS de reserva de cites per a petits negocis: perruqueries, clíniques dentals, tallers mecànics. L'equip és petit: la Marta (tech lead), en Diego (desenvolupador backend) i la Nuria (SRE). A la lliçó 01-04 el veurem en detall; de moment només ens interessa com treballen avui:

• En Diego compila al seu portàtil. La versió de Node que té instal·lada no és exactament la del servidor.
• Puja els fitxers resultants per SFTP a un únic servidor de producció.
• Executa les migracions de base de dades a mà, enganxant SQL en una consola de psql.
• Les proves s'executen "quan algú se'n recorda".
• Tot això passa els divendres a la tarda i dura unes 3 hores.
• Resultat: dues incidències greus en producció el darrer trimestre.

Aquest procés no és "dolent" per descuit: és dolent per disseny. Cadascun d'aquests passos depèn que una persona concreta, en un moment concret, no s'equivoqui. I les persones ens equivoquem.

Hi ha un segon problema, menys visible però igual de car. Imagina't que la Marta i en Diego treballen cadascun a la seva branca durant dues setmanes:

• La Marta reescriu el sistema de notificacions per correu.
• En Diego canvia el model de dades de les cites per admetre reserves recurrents.

Cap dels dos no toca la feina de l'altre aparentment. Però el dia que intenten fusionar totes dues branques, apareixen conflictes en 40 fitxers, la signatura d'una funció que tots dos fan servir ha canviat, i les proves de la Marta fallen per un canvi d'esquema d'en Diego. El que hauria d'haver estat una tarda es converteix en tres dies de "resoldre la integració".

Això és l'integration hell (infern de la integració): el cost de fusionar augmenta de manera no lineal amb el temps que les branques viuen separades.

La intuïció clau, que es repetirà en tot el curs: si una cosa fa mal, fes-la més sovint. Fusionar fa mal perquè ho fas poc. Desplegar fa mal perquè ho fas poc. La resposta contraintuïtiva de CI/CD és augmentar la freqüència fins que cada operació individual sigui trivial.

Definició. La Integració Contínua és la pràctica que cada membre de l'equip integri la seva feina a la línia principal de desenvolupament almenys un cop al dia, i que cada integració sigui verificada automàticament per un procés de construcció i proves que s'executa en un entorn net i compartit.

Hi ha tres idees dins d'aquesta definició, i totes tres són igual d'importants:

1. Integrar sovint. El codi de cada persona torna a la branca principal en hores, no en setmanes. Si la teva branca viu tres setmanes, no estàs fent CI encara que tinguis un servidor de CI configurat.
2. Verificar automàticament. No n'hi ha prou amb fusionar: un sistema automàtic compila, executa les proves i comprova la qualitat. Sense verificació automàtica, integrar sovint només vol dir trencar la branca principal més sovint.
3. En un entorn net i compartit. No al portàtil d'en Diego. En una màquina que parteix de zero cada vegada, perquè "a la meva màquina funciona" deixi de ser una frase vàlida.

Convé desactivar tres malentesos molt estesos:

Quan un equip adopta CI de debò, signa un contracte tàcit:

• La branca principal sempre està sana. Si la build és vermella, arreglar-la és la prioritat número u de l'equip, per damunt de qualsevol funcionalitat.
• Ningú no se'n va a casa amb la build trencada. Es reverteix el canvi i s'investiga amb calma l'endemà.
• Cada canvi es verifica abans d'integrar-se, no després.

Sense aquest contracte, l'automatització es converteix en un semàfor que tothom ignora. Hi tornarem al mòdul 2.

Definició. El Lliurament Continu és la pràctica de mantenir el programari sempre en un estat desplegable, de manera que qualsevol versió que hagi superat el pipeline es pugui portar a producció prement un botó, en qualsevol moment, amb un risc conegut.

El Lliurament Continu dona per suposada la Integració Contínua i hi afegeix una capa per damunt: no n'hi ha prou que el codi compili i passi els tests; cal que existeixi un artefacte construït, versionat, provat en entorns semblants a producció i llest per desplegar-se.

La frase clau és "prement un botó". En Lliurament Continu:

• El procés tècnic de desplegar està completament automatitzat.
• La decisió de desplegar continua sent humana.

Aquesta decisió humana no és una fallada del sistema: és una tria deliberada. Hi pot haver raons perfectament legítimes per no desplegar automàticament:

• Una campanya de màrqueting que arrenca dimarts i la funcionalitat no s'ha de veure abans.
• Un requisit de compliment normatiu que exigeix aprovació registrada.
• Un equip que encara no confia prou en el seu conjunt de proves.

L'important és que, quan algú decideix desplegar, no hi ha feina manual a fer: només autoritzar.

Definició. El Desplegament Continu és la pràctica que tot canvi que supera el pipeline automatitzat es desplegui en producció automàticament, sense intervenció humana.

És el Lliurament Continu sense el botó. S'elimina la porta manual: si el pipeline és verd, el canvi arriba als usuaris. Sense reunions, sense finestres de desplegament, sense divendres a la tarda.

Això sona temerari i, sense una base sòlida, ho és. El Desplegament Continu només funciona si es recolza en:

• Un conjunt de proves en què l'equip confia de debò (mòdul 2).
• Estratègies de desplegament progressiu —canari, blue-green— per limitar el radi d'impacte (mòdul 3).
• Feature flags per separar "desplegar codi" d'"activar funcionalitat" (mòdul 3).
• Rollback automàtic quan les mètriques es degraden (mòdul 3).
• Monitoratge que detecti el problema abans que el client (mòdul 3).

Fixa't en una cosa important: el Desplegament Continu no és l'objectiu obligatori de tot equip. És una opció. Moltíssimes organitzacions excel·lents es queden deliberadament en Lliurament Continu. El que sí que és innegociable és la capacitat de desplegar en qualsevol moment; fer-la servir automàticament o no és una decisió de context.

Aquí hi ha el nucli de la lliçó. Les sigles CI/CD són ambigües expressament i això genera confusió constant en entrevistes, documentació i converses d'equip.

Una manera de recordar-ho que funciona molt bé:

• Delivery = "podem desplegar quan vulguem" → la capacitat està automatitzada, la decisió és humana.
• Deployment = "despleguem sempre que el pipeline ho permet" → també la decisió està automatitzada.

I una relació d'inclusió que convé tenir gravada:

Es llegeix de baix a dalt: no hi pot haver Desplegament Continu sense Lliurament Continu, ni Lliurament Continu sense Integració Contínua. Qualsevol intent de saltar-se un esglaó produeix un sistema fràgil. Si Reservalia intentés demà desplegar automàticament a producció sense proves fiables, no tindria dues incidències per trimestre: en tindria dues per setmana.

Vegem el recorregut que farà un canvi d'en Diego al llarg de tot el curs. Aquest diagrama és el mapa mental del curs sencer:

Llegeix el diagrama identificant on encaixa cada pràctica:

• De A a E (commit → build → test): això és Integració Contínua. Ho construirem al mòdul 2.
• De F a I (artefacte → registre → dev → staging): això és Lliurament Continu. Mòduls 2 i 3.
• El pas J → L sense intervenció humana: això és Desplegament Continu. Mòdul 3.
• M i N (monitoratge i rollback): la xarxa de seguretat que fa possible tot l'anterior. Mòdul 3.

Fixem ara els termes. Els farem servir sense tornar-los a definir, així que val la pena llegir aquesta secció amb calma. Els agrupo per famílies.

Un detall que farem servir molt: el SHA del commit és la identitat canònica d'un canvi. Quan al mòdul 3 ens preguntem "quina versió exacta hi ha en producció?", la resposta correcta mai no serà "l'última", sinó un SHA concret.

La jerarquia, visualment:

Sobre els runners hi ha una distinció que importarà molt més endavant:

• Efímer: es crea net per a cada job i es destrueix en acabar. Garanteix reproduïbilitat. És el model per defecte de GitHub Actions.
• Persistent: una màquina que es reutilitza entre execucions. És més ràpid (conserva memòries cau) però acumula estat, i aquest estat és una font clàssica de builds que "funcionen només la segona vegada". Típic d'instal·lacions antigues de Jenkins.

Els dos últims mereixen desenvolupament, perquè són els que més es malinterpreten.

Promoció: construir una vegada, desplegar moltes. És una de les regles d'or de CI/CD. L'artefacte que es prova a staging ha de ser exactament el mateix binari que arriba a producció, byte a byte. Si reconstrueixes per a producció, estàs desplegant una cosa que ningú no ha provat mai.

I el que no s'ha de fer:

Si l'artefacte és el mateix als tres entorns, com canvia llavors la configuració? Per fora: variables d'entorn i secrets injectats en el moment del desplegament. L'artefacte no sap en quin entorn viu.

Build reproduïble. Que dues construccions del mateix commit donin el mateix resultat no és automàtic: cal guanyar-s'ho. Els enemics habituals són:

• Versions d'eines no fixades (node a seques en comptes de [email protected]).
• Dependències sense fitxer de bloqueig, que resolen a l'última versió disponible.
• Instal·lar amb npm install (que pot modificar el lock) en comptes de npm ci (que el respecta estrictament).
• Marques de temps o rutes absolutes incrustades a l'artefacte.

Aquest és exactament el problema d'en Diego: compila al seu portàtil, amb la seva versió de Node i els seus node_modules acumulats durant mesos. La seva build no és reproduïble, i per això ningú no pot reconstruir el que hi ha en producció.

Error 1: creure que "CD" sempre vol dir el mateix. Quan algú diu "tenim CI/CD", pregunta sempre: "el desplegament a producció el llança una persona o el pipeline?". És l'única pregunta que desambigua. En una entrevista de feina, distingir Delivery de Deployment i explicar per què es tria l'un o l'altre et col·loca per davant de la majoria de candidats.

Error 2: pensar que CI/CD és una eina que s'instal·la. GitHub Actions no et dona Integració Contínua, igual que comprar unes sabatilles no et dona forma física. L'eina executa; la pràctica la sosté l'equip. Un equip amb branques de tres setmanes i un servidor de CI caríssim no fa CI.

Error 3: reconstruir l'artefacte a cada entorn. Si el deploy a producció torna a compilar, el que arriba als usuaris no és el que es va validar a staging. Construeix una vegada, promociona el mateix artefacte. Ho formalitzarem a la lliçó 02-06.

Error 4: confondre desplegament amb release. Desplegar és posar el codi en producció; fer release és activar la funcionalitat per als usuaris. Amb feature flags pots desplegar dilluns i activar dijous. Són dues operacions diferents i separar-les redueix moltíssim el risc. Ho veurem a 03-05.

Error 5: fer servir branques de llarga durada i dir-ne CI. Si la teva branca té 60 commits i dues setmanes de vida, integraràs malament encara que tinguis mil tests verds. La freqüència d'integració és la pràctica; els tests són el mecanisme.

Consell 1: comença mesurant, no automatitzant. Abans d'escriure el teu primer flux de treball, apunta quant triga avui el teu desplegament i quantes vegades al mes falla. Sense línia base no podràs demostrar que la inversió ha valgut la pena. La lliçó 01-05 va justament d'això.

Consell 2: el pipeline és codi de producció. Viu al repositori, es revisa en pull requests i es versiona igual que la resta. Un .github/workflows/ci.yml editat a mà des d'una interfície web és deute tècnic des del primer minut.

Consell 3: si fa mal, fes-ho més sovint. És el principi que resumeix el curs sencer. Els merges fan mal perquè són rars; els desplegaments fan por perquè són excepcionals. Augmentar la freqüència obliga a automatitzar, i automatitzar elimina el dolor.

Per a cada situació, indica si descriu Integració Contínua, Lliurament Continu, Desplegament Continu o cap de les tres, i justifica-ho en una frase.

1. L'equip té un servidor que executa les proves cada nit a les 3:00 sobre la branca main. Les branques de funcionalitat es fusionen cada tres setmanes.
2. Cada pull request dispara build i tests en 6 minuts. Si són verds, es pot fusionar. Els desplegaments continuen sent manuals per SFTP.
3. En fusionar a main, el pipeline construeix una imatge Docker, la desplega a staging i executa proves de fum. La Marta prem "Deploy to production" quan ho considera oportú.
4. En fusionar a main, el pipeline desplega a producció en un 5 % del trànsit, vigila els errors 10 minuts i, si tot va bé, completa el desplegament. Ningú no hi intervé.
5. En Diego compila al seu portàtil i puja per SFTP els divendres.

El pseudo-script següent és el procés manual d'en Diego. Identifica almenys quatre motius pels quals l'artefacte resultant no és reproduïble, i proposa una correcció per a cadascun.

Escriu un diagrama mermaid del pipeline objectiu de Reservalia amb aquestes condicions, fent servir correctament els termes trigger, etapa, job, artefacte, entorn i promoció:

• Es dispara en fusionar a main.
• Etapa de verificació amb dos jobs en paral·lel: test-api i test-web.
• Si tots dos passen, es construeix un artefacte etiquetat amb el SHA del commit.
• L'artefacte es desplega a staging automàticament.
• Es promociona a prod només després d'aprovació manual de la Marta.

Solució a l'Exercici 1

1. Cap de les tres. És una nightly build. Hi ha automatització de proves, però les branques viuen tres setmanes: no hi ha integració contínua, sinó integració tardana verificada de nit. La verificació arriba fins a 21 dies després del canvi que la va trencar.
2. Integració Contínua. Cada canvi es verifica automàticament abans d'integrar-se i el cicle de retroalimentació és de minuts. No hi ha Lliurament Continu perquè no existeix cap artefacte desplegable ni desplegament automatitzat: el desplegament continua sent un procés manual.
3. Lliurament Continu. Tot el camí tècnic fins a producció està automatitzat (build, artefacte, staging, proves de fum) i només queda una porta manual: la decisió de la Marta. És l'exemple canònic de Delivery.
4. Desplegament Continu. No hi ha intervenció humana entre el merge i producció. A més apareix la xarxa de seguretat imprescindible: desplegament progressiu (canari al 5 %) i verificació automàtica abans de completar.
5. Cap de les tres. És desplegament manual amb integració tardana. És el punt de partida de Reservalia.

Solució a l'Exercici 2

Amb quatre n'hi hauria hagut prou; si n'has trobat més, encara millor senyal.

Solució a l'Exercici 3

Punts que havien d'aparèixer i convé comprovar a la teva versió:

• El trigger és un esdeveniment del repositori, no una acció manual.
• test-api i test-web són jobs paral·lels dins d'una mateixa etapa, no etapes diferents.
• Es construeix un únic artefacte, etiquetat amb el SHA (no amb la data ni amb "latest").
• A producció hi va el mateix artefacte que es va validar a staging: això és promoció, no una reconstrucció.
• La porta manual situa aquest pipeline en Lliurament Continu. Traient aquesta porta, seria Desplegament Continu.

En aquesta lliçó hem posat els fonaments del curs:

• L'enemic té dues cares: l'integration hell (fusionar tard i de cop) i el desplegament manual (processos que depenen que una persona no s'equivoqui). Reservalia pateix totes dues.
• La Integració Contínua és integrar sovint i verificar automàticament en un entorn net. És una pràctica d'equip abans que una eina.
• El Lliurament Continu manté el programari sempre desplegable: el procés està automatitzat i la decisió és humana.
• El Desplegament Continu elimina aquesta última porta manual, i només és assenyat amb proves fiables, desplegament progressiu, monitoratge i rollback.
• Els tres s'apilen: no hi ha Deployment sense Delivery, ni Delivery sense CI.
• I tenim un vocabulari comú: repositori, commit, branca, trigger, pipeline, etapa, job, runner, artefacte, entorn, promoció i build reproduïble. Dues regles d'or que repetirem fins al final: construir una vegada i promocionar el mateix artefacte, i fixar versions perquè la build sigui reproduïble.

Ara ja saps què és CI/CD. La pregunta lògica de la Marta quan presenti això al seu equip serà una altra: "i això què ens aporta, i què ens costarà?". Perquè muntar un pipeline no és gratis: consumeix temps de configuració, manteniment i minuts d'execució. A la lliçó següent, Beneficis del CI/CD, veurem amb honestedat les dues columnes de la balança: què hi guanya un equip com el de Reservalia, com es mesura cada benefici i en quines situacions CI/CD aporta menys del que costa.