Hi ha aplicació, hi ha dades i hi ha models. I tot depèn que dues persones se'n recordin d'executar les coses. Aquest mòdul comença just aquí, i comença per la baula més fràgil de tota la cadena: com arriba el codi d'en Dani a producció.

La resposta actual és incòmoda d'escriure. En Dani obre un terminal al seu portàtil, executa docker build, espera uns minuts, executa docker push contra Artifact Registry i després llança a mà el kubectl set image sobre alpinashop-cluster. Si aquell dia té una dependència diferent instal·lada, la imatge surt diferent. Si oblida executar les proves, ningú no les executa. Si està de baixa, ningú no desplega. I si alguna cosa falla en producció, l'única manera de saber quina versió hi ha corrent és preguntar-l'hi a ell.

En aquesta lliçó això s'acaba. Construiràs un procés automàtic que, davant de cada canvi del codi, instal·la dependències, executa les proves, analitza el codi, construeix una imatge reproduïble, la publica etiquetada amb l'identificador exacte del commit i la desplega en desenvolupament sense que ningú toqui un terminal. I entendràs per què cada peça és on és, que és el que distingeix copiar un cloudbuild.yaml de saber-ne dissenyar un.

1. El problema real: com es desplega AlpinaShop avui
2. Integració contínua i lliurament continu: què signifiquen de debò
3. Què és Cloud Build i com executa les coses
4. El fitxer cloudbuild.yaml camp a camp
5. El pipeline del catàleg d'AlpinaShop, pas a pas
6. Memòria cau de compilació: per què el teu build triga vuit minuts
7. Activadors: què llança la compilació i quan
8. El compte de servei de Cloud Build i l'antipatró de l'Editor
9. Secrets durant la compilació amb Secret Manager
10. Promoció entre entorns i aprovacions manuals
11. Grups de treballadors privats dins de la VPC
12. Cloud Deploy: lliurament progressiu gestionat
13. Escaneig de vulnerabilitats i Binary Authorization
14. El pipeline d'ML del mòdul 5, portat al nivell 2
15. Cost de les compilacions

Val la pena escriure el procediment actual tal com ho faria en Dani si algú li demanés documentar-lo:

Són sis comandes. Semblen inofensives. Contenen cinc problemes greus:

El tercer és el més verinós i convé entendre'l bé. latest no és una versió: és un punter mòbil. Si demà la botiga falla i vols tornar a la imatge de la setmana passada, no existeix: la vas sobreescriure. Si vols saber quin commit va generar el contenidor que està servint peticions, no hi ha manera. Una etiqueta immutable derivada del commit converteix cada imatge en un punt exacte de la història del codi, i aquesta és la propietat que fa possible tota la resta: diagnòstic, auditoria i reversió.

Els dos termes s'utilitzen com si fossin un de sol, i no ho són.

Integració contínua (CI) és la pràctica d'integrar la feina de tothom a la branca principal amb freqüència —idealment diverses vegades al dia— i verificar automàticament cada integració. El seu producte no és un desplegament: és una resposta ràpida a la pregunta "aquest canvi trenca alguna cosa?". Si la resposta triga dos dies, deixa de ser útil, perquè aleshores ja hi ha deu canvis a sobre i ja no saps quin la va trencar.

Lliurament continu (CD, continuous delivery) és la pràctica de mantenir el programari sempre en un estat en què podria desplegar-se, amb el desplegament automatitzat fins al punt que llançar-lo sigui prémer un botó. La decisió de prémer-lo continua sent humana.

Desplegament continu (continuous deployment) va un pas més enllà: tot canvi que passa les verificacions va a producció tot sol, sense botó.

AlpinaShop implantarà CI completa i lliurament continu, amb desplegament automàtic a alpinashop-dev i aprovació manual abans d'alpinashop-prod. El desplegament continu a producció és un objectiu legítim, però requereix una xarxa de seguretat —cobertura de proves, alertes fiables, capacitat de reversió automàtica— que no existirà fins després de 06-04 i 06-06.

Hi ha un benefici de la CI que gairebé mai no s'esmenta i que és el més valuós: obliga que el projecte es pugui construir des de zero en una màquina neta. El primer intent d'escriure un pipeline de CI destapa sempre les mateixes coses: un fitxer de configuració que només existeix al portàtil d'algú, una dependència instal·lada a mà fa dos anys, una variable d'entorn que ningú no va documentar. Descobrir-les fa mal, però descobrir-les en una compilació és infinitament millor que descobrir-les el dia que s'incorpora una persona nova o que cal reconstruir l'entorn d'urgència.

Cloud Build és el servei gestionat de GCP per executar processos de compilació. El seu model mental és sorprenentment senzill i val la pena interioritzar-lo perquè explica tot el seu comportament:

Una compilació és una seqüència de passos. Cada pas és un contenidor que s'executa sobre un directori de treball compartit anomenat /workspace.

Això és tot. No hi ha un llenguatge de scripting propi, ni connectors, ni un model d'extensió: si necessites executar alguna cosa, executes un contenidor que sàpiga fer-ho.

Les tres conseqüències pràctiques d'aquest model:

• Tot el que persisteix entre passos viu a /workspace. Un pas que instal·la paquets a /usr/local del seu contenidor no deixa res al següent. Un pas que escriu a /workspace/venv sí. Aquest és el detall que més confusió causa a qui comença, i hi tornarem a l'apartat 5.
• Cada pas pot fer servir la imatge que vulgui. El pas de proves pot ser python:3.11, el d'anàlisi estàtica golangci-lint, el de desplegament gcr.io/google.com/cloudsdktool/cloud-sdk. No cal ficar-ho tot en una imatge monstruosa.
• La compilació s'executa en infraestructura efímera de Google, no al teu portàtil. Màquina neta, sempre igual, i amb una identitat pròpia (el seu compte de servei, apartat 8).

Google publica imatges de constructor (cloud builders) per a les eines habituals: gcr.io/cloud-builders/docker, gcr.io/cloud-builders/gcloud, gcr.io/cloud-builders/git, gcr.io/cloud-builders/npm. Però no estàs obligat a utilitzar-les: qualsevol imatge pública o del teu Artifact Registry serveix, i el 2026 la recomanació general és utilitzar imatges oficials de l'ecosistema (python:3.11-slim, node:22) en lloc de les de cloud-builders, que estan congelades en versions antigues.

El pipeline es declara en un fitxer YAML que viu al repositori, al costat del codi. Que hi visqui no és un detall organitzatiu: significa que el procés de compilació es versiona, es revisa en una pull request i evoluciona amb el codi al qual serveix.

Aquest és l'esquelet complet amb tots els camps que utilitzaràs:

Camp a camp, amb el que importa de cadascun:

Per defecte cada pas espera l'anterior. Amb waitFor declares de què depèn realment cada pas, i Cloud Build executa en paral·lel tot el que pot:

Hi ha un valor especial: waitFor: ['-'] significa "no esperis ningú, arrenca des del principi". És útil per a tasques independents com descarregar una memòria cau.

El paral·lelisme aquí no és una microoptimització. Si les proves triguen tres minuts i l'anàlisi estàtica dos més, executar-los alhora converteix una compilació de cinc minuts en una de tres. I la velocitat de la CI determina si l'equip la fa servir: un pipeline de vint minuts s'acaba saltant; un de quatre, no.

Cloud Build omple automàticament un conjunt de variables:

$COMMIT_SHA i $SHORT_SHA només tenen valor si la compilació ve d'un activador connectat a un repositori. Si llances gcloud builds submit des de la teva màquina, estan buides. És una causa de fallada molt habitual: la imatge es publica amb l'etiqueta catalogo: i ningú no entén per què.

Les teves pròpies substitucions porten _ al davant i es declaren a substitutions: amb un valor per defecte que l'activador pot sobreescriure. Aquest és el mecanisme amb què un mateix cloudbuild.yaml serveix per a diversos entorns.

Aquest és el fitxer real que va a l'arrel del repositori del catàleg. Llegeix-lo sencer i després el desmuntem:

Pas 1, dependències. El --target=/workspace/lib és la peça que fa que això funcioni. Sense ell, pip instal·laria al site-packages del contenidor python:3.11-slim, aquell contenidor acabaria, i el pas 2 arrencaria un contenidor nou i net sense les dependències. Amb ell, els paquets queden al directori compartit i el pas 2 els troba gràcies a PYTHONPATH.

Pas 2, proves. Dues coses importants. --junitxml genera un informe en format estàndard que després es puja com a artefacte —útil per revisar què ha fallat sense capbussar-se en els registres—. I --fail-under=70 fa que la compilació falli si la cobertura baixa del 70 %. Aquella línia és una decisió de política, no tècnica: converteix "hauríem d'escriure més proves" en una regla que el sistema aplica. Comença amb un llindar que ja compleixis i puja'l a poc a poc; posar un 90 % de cop en un projecte que està al 40 % només aconsegueix que algú esborri la línia.

Pas 3, anàlisi estàtica. ruff detecta problemes d'estil i errors evidents; bandit busca patrons insegurs en Python —credencials incrustades, ús de subprocess amb shell=True, algorismes criptogràfics febles—. El -ll limita l'avís a severitat mitjana o superior per evitar soroll. Fixa't que el seu waitFor apunta a instalar, no a pruebas: per això s'executa alhora.

Pas 4, construir. S'utilitza kaniko en lloc de docker build, i el motiu és doble: kaniko construeix imatges sense necessitar un dimoni Docker amb privilegis, i porta memòria cau de capes remota integrada. L'apartat 6 hi entra en detall. L'etiqueta és $COMMIT_SHA i no apareix latest enlloc.

Pas 5, desplegar en desenvolupament. El desplegament va a alpinashop-dev, mai a alpinashop-prod des d'aquest pipeline. I el kubectl rollout status --timeout=180s és imprescindible: sense ell, el pas acabaria amb èxit tan bon punt Kubernetes accepta l'ordre, encara que els pods nous entrin en CrashLoopBackOff trenta segons després. Amb ell, la compilació falla si el desplegament no convergeix, que és el que vols saber.

Per llançar-lo a mà mentre el proves:

Fixa't en el projecte: alpinashop-cicd. Fins ara aquell projecte estava creat i buit. Aquí comença a tenir sentit: les compilacions s'executen en un projecte propi, separat dels entorns que despleguen. Això permet donar a Cloud Build permisos acotats sobre alpinashop-dev i alpinashop-prod sense que visqui dins d'ells, i manté l'historial de compilacions i els seus registres fora dels projectes de producció.

La primera compilació triga el que triga. Les següents no haurien de fer-ho, i si triguen el mateix és que no hi ha memòria cau.

Una imatge Docker és una pila de capes, i cada instrucció del Dockerfile en genera una. Si una capa no ha canviat i les anteriors tampoc, es pot reutilitzar. El problema és que Cloud Build executa cada compilació en una màquina neta: no hi ha memòria cau local per reutilitzar. Cal portar-la d'algun lloc.

Dos mecanismes, amb perfil diferent:

Amb --cache-from el patró és aquest, i té un parany:

El || true evita que la primera compilació falli, quan encara no existeix cap imatge de memòria cau per descarregar. És un detall petit que trenca molts pipelines nous.

Però la memòria cau només ajuda si el Dockerfile està ordenat per aprofitar-la. Compara:

La regla general: del que menys canvia al que més canvia. Les dependències canvien un cop al mes; el codi, vint vegades al dia. Si copies el codi abans d'instal·lar dependències, cada commit ho reinstal·la tot. Aquest canvi de tres línies acostuma a retallar més temps de compilació que qualsevol ajust de màquina.

L'altre factor és la mida de la màquina. El valor per defecte és modest; E2_HIGHCPU_8 costa més per minut però pot reduir el temps total prou per sortir més barat, a més de donar resposta més ràpida a l'equip. Mesura-ho abans de decidir: en compilacions dominades per descàrregues de xarxa, més CPU no aporta res.

Un activador (trigger) és la regla que connecta un esdeveniment d'un repositori amb un cloudbuild.yaml. Sense activadors tens un script; amb ells, integració contínua.

Crear l'activador de branca principal:

I el de pull request, que és el que realment protegeix la branca principal:

El cloudbuild-pr.yaml és el mateix pipeline sense el pas de desplegament: instal·la, prova i analitza. La seva funció és donar un veredicte verd o vermell a la sol·licitud d'incorporació (pull request) abans que ningú la fusioni. El --comment-control evita que un contribuïdor extern desconegut pugui executar codi arbitrari al teu projecte obrint una PR; en un repositori privat d'un equip petit importa menys, però és un bon hàbit.

Un filtre molt útil en repositoris amb diverses coses a dins és --included-files, que evita compilar el catàleg perquè algú ha corregit una errada al README:

La connexió amb el repositori es configura una sola vegada. AlpinaShop la farà amb GitHub a través de l'aplicació de Cloud Build, i tot el detall —inclosa l'alternativa de Cloud Source Repositories i per què està en desús— és exactament el tema de 06-02.

Aquest és l'apartat que més disgustos evita.

Tota compilació s'executa amb una identitat. Històricament Cloud Build utilitzava un compte de servei automàtic, <número-projecte>@cloudbuild.gserviceaccount.com, al qual Google concedia el rol Editor sobre el projecte. Còmode i catastròfic: significa que qualsevol que pugui modificar el cloudbuild.yaml pot fer gairebé qualsevol cosa al projecte. I modificar aquell fitxer és simplement obrir una pull request.

Imagina't l'atac, que no requereix cap coneixement especial:

Si el compte de Cloud Build té Editor, aquell pas funciona. Per això, des del 2024, els projectes nous ja no reben el rol Editor per defecte i es recomana especificar un compte de servei propi per activador. I per això l'activador de l'apartat 7 porta --service-account.

La configuració correcta per a AlpinaShop, amb el principi de mínim privilegi de 03-04 aplicat de debò:

Tres rols. Ni un més. Fixa't en el que no té: cap permís sobre alpinashop-prod llevat d'escriure al repositori d'imatges, cap accés a Secret Manager que no se li concedeixi secret a secret, cap capacitat de tocar IAM, cap capacitat d'esborrar res.

Hi ha un detall operatiu associat: quan utilitzes un compte de servei propi, has d'especificar logging: CLOUD_LOGGING_ONLY a options (o donar-li un bucket de Cloud Storage on escriure), perquè el comportament per defecte exigeix permisos que aquell compte no té. És el primer error que apareix en migrar, i el missatge no és especialment clar.

La regla mental que convé gravar-se: el pipeline de CI/CD és el sistema amb més privilegis de la teva infraestructura, perquè per definició pot desplegar codi a tot arreu. Tracta'l com a tal. Si un atacant ha de triar un objectiu a AlpinaShop, no triarà el web: triarà això.

Algunes compilacions necessiten credencials: un testimoni per publicar en un registre privat, una clau d'API per a un servei d'anàlisi. El que mai no ha de passar és que aquella credencial estigui escrita al cloudbuild.yaml, perquè aquell fitxer és a Git i allà es queda per sempre, encara que després l'esborris.

Cloud Build s'integra amb Secret Manager (03-06) mitjançant availableSecrets:

Tres detalls que cal entendre:

• $$TOKEN_REGISTRO porta dos dòlars. Un sol $ faria que Cloud Build intentés substituir-lo com si fos una variable seva, trobés que no existeix i deixés la cadena buida. Amb $$ el valor arriba literal al shell, que és qui resol la variable d'entorn.
• secretEnv va per pas. Només els passos que el declaren veuen el secret. Un pas de proves no té per què tenir accés al testimoni de publicació.
• El compte de servei de la compilació necessita roles/secretmanager.secretAccessor sobre aquell secret concret, concedit a la política del propi secret, no a nivell de projecte.

I un advertiment que sembla obvi i tanmateix passa: si el teu script imprimeix el secret, apareix als registres. Cloud Build no censura la sortida. Un set -x en un script bash o un echo de depuració oblidat basten per filtrar una credencial a Cloud Logging, on la pot llegir qualsevol amb permís de lectura de registres. Si sospites que ha passat, la resposta correcta no és esborrar el registre: és rotar el secret.

El pipeline construït desplega a alpinashop-dev. Producció necessita una altra cosa, i aquella altra cosa es diu promoció.

El principi és senzill i és la raó de ser de l'etiqueta immutable:

La imatge que va a producció és exactament la mateixa que es va provar en desenvolupament. No es reconstrueix. Es promociona.

Si en producció es reconstruís la imatge des del codi, seria una imatge diferent —una altra data, potser una altra versió d'una dependència transitiva— i tot el que s'ha verificat en desenvolupament deixaria de valer. El que canvia entre entorns és la configuració (variables, secrets, mida), no l'artefacte.

L'activador de producció es crea amb --require-approval:

Quan aquell activador s'activa, la compilació queda en estat pendent fins que algú amb el rol roles/cloudbuild.builds.approver l'aprova des de la consola. La Marta el té; en Dani no. I aquella separació no és desconfiança: és l'aplicació al desplegament del mateix principi de 03-04 segons el qual ningú no és owner de producció.

Fixa't també que el desplegament a producció utilitza un altre compte de servei, sa-deploy-prod, que sí que té permisos sobre alpinashop-prod. El compte que executa les proves i construeix la imatge no els té mai. Si algú compromet el pipeline de CI, no arriba a producció sense passar per una aprovació humana executada amb una altra identitat.

El cloudbuild-prod.yaml rep l'etiqueta a desplegar com a substitució i no construeix res:

La comprovació test -n de la primera línia existeix perquè una substitució buida produiria l'etiqueta catalogo:, que falla de manera confusa. És una guarda de tres paraules que estalvia mitja hora de desconcert.

Per defecte les compilacions s'executen en un grup de treballadors compartit de Google, amb sortida a internet i sense accés a la teva VPC. Per a AlpinaShop això funciona fins al dia que una prova d'integració necessita connectar-se a alpinashop-pedidos per IP privada, o el pas de desplegament ha d'arribar a un endpoint intern.

Un grup de treballadors privat (private pool) és un conjunt de màquines de compilació connectades a la teva VPC:

I s'utilitza des del cloudbuild.yaml:

El --no-public-egress mereix una nota: elimina la sortida a internet, cosa que és excel·lent per a la seguretat i trenca qualsevol pas que descarregui dependències de PyPI o imatges de Docker Hub. Si l'actives, necessites rèpliques internes d'aquells repositoris a Artifact Registry. És una decisió seriosa; per a AlpinaShop avui, el grup compartit és suficient i el privat es reserva per quan hi hagi proves d'integració contra Cloud SQL.

Cloud Build és excel·lent construint i acceptable desplegant. Quan el desplegament es complica —tres entorns, desplegament canari, reversió amb una comanda, historial de quina versió va estar a cada lloc— hi ha una eina específica: Cloud Deploy.

Cloud Deploy modela un pipeline de lliurament amb destinacions ordenades i gestiona la promoció entre elles:

El que aporta sobre un kubectl set image a Cloud Build:

• Desplegament canari real: el 10 % del trànsit va a la versió nova, es verifica, es passa al 50 %, es verifica, i només llavors al 100 %.
• Reversió amb una comanda, sense reconstruir res, perquè coneix l'historial del que s'ha desplegat.
• Registre de quina versió és a quina destinació, que respon a la pregunta "què hi ha en producció?" sense preguntar-ho a ningú.
• Aprovacions per destinació integrades.

Per a AlpinaShop avui, amb un servei i dos entorns, Cloud Build en té prou i afegir Cloud Deploy seria complexitat sense benefici. S'anota com el pas natural per quan el catàleg es mogui a Cloud Run a 07-02, on Cloud Deploy encaixa especialment bé perquè el repartiment de trànsit per percentatge és natiu del servei.

Construir la imatge no és el mateix que construir una imatge segura. El Dockerfile del catàleg no fa servir root —bé, decisió del mòdul 2— però arrossega desenes de paquets del sistema base i de PyPI, i qualsevol d'ells pot tenir una vulnerabilitat coneguda.

Artifact Registry analitza automàticament les imatges contra bases de dades públiques de vulnerabilitats, si l'API està activada:

Es pot afegir un pas al pipeline que falli si apareixen vulnerabilitats crítiques, i aquí cal prendre una decisió amb el cap fred: bloquejar per qualsevol vulnerabilitat de qualsevol severitat genera tants falsos positius que l'equip acabarà desactivant la comprovació. Un criteri raonable per començar és bloquejar només les crítiques amb correcció disponible i revisar la resta periòdicament.

Binary Authorization va un pas més enllà i respon a una altra pregunta: com impedeixo que es desplegui en producció una imatge que no ha passat pel pipeline? Perquè avui, si algú amb permisos fa kubectl set image apuntant a una imatge construïda al seu portàtil, el clúster l'accepta encantat.

El mecanisme són les atestacions: el pipeline signa criptogràficament les imatges que ha verificat, i una política al clúster exigeix aquella signatura per admetre un desplegament.

És una peça de maduresa alta i no cal implantar-la el primer dia. Però convé entendre què resol, perquè és l'única manera que la frase "a producció només arriba el que ha passat pel pipeline" sigui una garantia tècnica i no una norma de bona voluntat. La seguretat de la cadena de subministrament de programari es reprèn a 07-04.

A 05-07 va quedar una punta solta explícita. El pipeline de recomanació d'AlpinaShop és al nivell 1 de maduresa: s'executa sol, valida sol i decideix sol. Però el codi del pipeline —els components KFP, la lògica d'entrenament— es continua pujant a mà: la Lucía edita el component, executa el compilador de KFP al seu portàtil i puja el YAML resultant a Cloud Storage.

El nivell 2 consisteix en el fet que un canvi al codi d'entrenament dispari automàticament la compilació del pipeline, la seva execució a Vertex AI i, si supera les portes, el desplegament del model. És exactament el mateix que acabes de fer amb el catàleg, aplicat al codi d'ML:

L'important no és el YAML, és el canvi de comportament que produeix:

I fixa't en la connexió que tanca el cercle: l'etiqueta $COMMIT_SHA de la imatge d'entrenament acaba registrada a les metadades de Vertex AI Pipelines. Això significa que, davant de la pregunta d'auditoria "amb quin codi exacte es va entrenar el model que va fer aquesta recomanació?", la resposta ja no és una conjectura: és un commit concret que es pot consultar a Git.

El model de preus de Cloud Build és simple: es paga per minut de compilació, i el preu per minut depèn de la mida de màquina. Hi ha una quota gratuïta mensual generosa per a la màquina per defecte.

Ordres de magnitud —verifica sempre els preus vigents a la documentació oficial, perquè canvien—:

Un càlcul orientatiu per a AlpinaShop: unes 15 compilacions al dia entre pull requests i fusions, a 4 minuts de mitjana en E2_HIGHCPU_8, són uns 60 minuts-màquina diaris, al voltant de 1.800 al mes. Amb la màquina per defecte una part estaria coberta pel nivell gratuït; amb E2_HIGHCPU_8 el cost mensual és de l'ordre de desenes d'euros. Comparat amb el temps d'enginyeria que estalvia, és de les inversions més rendibles de tota la plataforma.

Les quatre palanques per controlar-lo:

1. Memòria cau ben configurada. És la que més estalvia, i a més fa feliços els desenvolupadors.
2. --included-files als activadors. No compilis perquè ha canviat un fitxer de documentació.
3. La mida de màquina adequada. Més gran no sempre és millor: si el coll d'ampolla és la xarxa, pagues 8× pel mateix temps.
4. Un timeout sensat. Sense ell, una compilació penjada consumeix fins a 60 minuts abans de rendir-se.

Esperar que un pas vegi el que ha instal·lat l'anterior fora de /workspace. És l'error número u. Cada pas és un contenidor nou: l'únic que persisteix és el directori compartit. Si instal·les dependències, instal·la-les amb --target=/workspace/... i propaga PYTHONPATH.

Etiquetar amb latest. Ja s'ha dit tres vegades i es diu una quarta perquè és l'error amb pitjors conseqüències: sense etiqueta immutable no hi ha diagnòstic ni reversió. Fes servir $COMMIT_SHA sempre. Si a més vols una etiqueta llegible, afegeix $SHORT_SHA o una versió semàntica al costat del SHA, mai al seu lloc.

Deixar el compte de servei amb permisos amplis "fins que funcioni". Aquell "fins que funcioni" es converteix en permanent. Comença restrictiu i afegeix permisos concrets segons vagin fallant els passos: cada fallada et diu exactament quin permís falta, i així acabes amb la llista mínima real en lloc d'amb Editor.

No comprovar que el desplegament convergeix. kubectl set image retorna èxit tan bon punt Kubernetes accepta l'ordre. Si els pods nous fallen en arrencar, el teu pipeline es posa verd mentre l'aplicació està trencada. kubectl rollout status --timeout=... és obligatori.

Utilitzar un sol dòlar a secretEnv. $EL_MEU_SECRET el prova de substituir Cloud Build i el deixa buit; $$EL_MEU_SECRET arriba al shell. I no imprimeixis mai el valor: els registres no es censuren.

Copiar el codi abans d'instal·lar dependències al Dockerfile. Invalida la memòria cau a cada commit. Ordena les instruccions del que és estable al que és volàtil.

Oblidar logging: CLOUD_LOGGING_ONLY en utilitzar compte de servei propi. Fallada immediata amb un missatge poc descriptiu. És dels primers que apareixen en fer bé les coses.

Pipelines lents. Si la CI triga vint minuts, l'equip deixarà d'esperar-la i fusionarà sense mirar. Tracta la durada del pipeline com una mètrica de producte: paral·lelitza amb waitFor, fes servir memòria cau, i si cal separa les proves ràpides —a cada PR— de les lentes —nocturnes—.

Consell final: comença petit. Un pipeline que només executa les proves a cada pull request ja aporta la major part del valor. Afegeix construcció, després desplegament a desenvolupament, després promoció a producció. Un pipeline perfecte que triga tres mesos a estar llest perd davant d'un de modest que funciona el divendres.

El pipeline del catàleg triga 9 minuts: instal·lar 2, proves 3, lint 2, construir 2. La Marta es queixa que les pull requests triguen massa a donar veredicte. Reescriu la secció steps per minimitzar el temps total, calcula la durada teòrica resultant i explica quines altres dues mesures —una al cloudbuild.yaml i una altra al Dockerfile— reduirien més el temps.

AlpinaShop vol un pipeline que, en crear una etiqueta Git v*, construeixi la imatge, la publiqui a Artifact Registry, executi les migracions de base de dades sobre alpinashop-pedidos a alpinashop-prod i desplegui en producció després d'aprovació. Enumera els comptes de servei que crearies, els rols exactes de cadascun i justifica per què no en faries servir un de sol. Assenyala a més el risc de seguretat més gran de l'enunciat.

El pipeline porta dues setmanes en verd. Un client informa que el cercador del catàleg falla des de fa deu dies. En investigar descobreixes tres coses: la cobertura de proves és del 71 % i el cercador no està cobert; el pas de desplegament acaba amb èxit però la versió desplegada a alpinashop-dev és de fa tres setmanes; i en producció hi ha una imatge que ningú no sap d'on ha sortit. Explica la causa més probable de cada troballa i quin canvi concret al pipeline hauria impedit cadascuna.

Solució 1

Pipeline reescrit. L'observació clau és que pruebas i lint només depenen d'instalar, no entre si:

Durada teòrica: 2 + max(3, 2) + 2 = 7 minuts, davant de 9. S'estalvien 2 minuts, el temps del lint, que ara és gratis perquè cap dins del de les proves.

Es pot fer força millor. El pas de construcció també depèn només del codi, no que les proves hagin passat. Si el llances en paral·lel amb waitFor: ['-'] des del principi, el temps total baixa a 2 + 3 = 5 minuts. La contrapartida és que construeixes una imatge que potser llençaràs si les proves fallen, cosa que costa 2 minuts de màquina. En una pull request, on la imatge no es publica, és un intercanvi raonable: pagues una mica de còmput per donar veredicte abans.

Mesura al cloudbuild.yaml: pujar el machineType a E2_HIGHCPU_8. Els 3 minuts de pytest acostumen a ser CPU pura i baixen sensiblement amb més nuclis, sobretot si a més afegeixes pytest -n auto amb pytest-xdist per paral·lelitzar les proves dins del pas.

Mesura al Dockerfile: reordenar perquè COPY requirements.txt i la instal·lació vagin abans de COPY . /app. Amb kaniko i --cache=true, la capa de dependències es reutilitza en totes les compilacions on no canviïn les dependències, que són la immensa majoria, i els 2 minuts de construcció es converteixen en segons.

I el consell que embolcalla tot l'exercici: mesura abans d'optimitzar. La consola de Cloud Build mostra la durada de cada pas; els 9 minuts podrien ser 7 de descàrrega d'una dependència gegant, i en aquell cas ni el paral·lelisme ni la màquina gran canviarien res.

Solució 2

Quatre comptes de servei, un per responsabilitat:

Per què no un de sol: perquè un compte únic seria la unió de tots els permisos, i qualsevol pas del pipeline podria fer qualsevol cosa. Amb la separació, el pas que executa les proves no pot tocar la base de dades de producció encara que algú hi injecti codi maliciós; el pas de migracions no pot desplegar; el de desplegament no pot llegir secrets. És el mateix principi de segregació de funcions de 03-04, aplicat dins d'un procés automàtic. I hi ha un benefici operatiu afegit: quan apareix als registres d'auditoria una operació estranya, la identitat et diu immediatament quina part del pipeline la va fer.

El risc més gran de l'enunciat són les migracions de base de dades, i no és un problema de permisos. Una migració és l'operació menys reversible de tot el pipeline: si kubectl set image surt malament, es torna enrere en trenta segons; si un ALTER TABLE esborra una columna, les dades no tornen. Quatre mesures concretes:

• Còpia de seguretat automàtica i verificada immediatament abans de la migració, com a pas del pipeline que falla si no es completa.
• Migracions compatibles cap enrere: afegir columnes abans d'utilitzar-les, no esborrar mai al mateix desplegament que deixa d'usar-les. Així la versió anterior de l'aplicació continua funcionant amb l'esquema nou, i la reversió és possible.
• Executar primer a alpinashop-dev amb una còpia recent de dades de producció, i que la compilació falli si allà no funciona.
• Aprovació manual abans del pas de migració, no només abans del desplegament.

I un advertiment sobre l'activador per etiqueta: qualsevol que pugui crear una etiqueta v* al repositori dispara aquest pipeline. La protecció d'etiquetes a Git és tan important com la de branques, i és un tema de 06-02.

Solució 3

Troballa 1: cobertura del 71 % amb el cercador sense cobrir. La causa és que el llindar --fail-under=70 està mesurant el que no importa: mesura el percentatge global de línies, i un percentatge global alt és perfectament compatible amb que les parts crítiques estiguin al 0 %. El pipeline estava en verd dient la veritat sobre una mètrica irrellevant.

Canvi concret: llindars per mòdul a més del global, exigint cobertura alta als paquets crítics:

I, més important que el llindar, una prova de fum posterior al desplegament que exerciti els camins principals de l'aplicació contra l'entorn acabat de desplegar. Que el codi estigui cobert no garanteix que el sistema funcioni; una petició real al cercador, sí.

Troballa 2: el desplegament "amb èxit" té tres setmanes. Gairebé segur que hi falta el kubectl rollout status. Els pods nous arrenquen, fallen, Kubernetes manté el ReplicaSet anterior servint trànsit, i el pas del pipeline va acabar amb èxit tan bon punt es va acceptar l'ordre. Tot verd, res desplegat. És la fallada més traïdora d'aquest apartat perquè el sistema t'està mentint activament.

Canvi concret: afegir kubectl rollout status deployment/catalogo-web -n tienda --timeout=180s com a part del mateix pas, més una verificació posterior que comprovi que la imatge realment en execució coincideix amb l'esperada:

Troballa 3: una imatge en producció que ningú no sap d'on ha sortit. Algú va desplegar a mà, saltant-se el pipeline. És el que passa sempre quan el pipeline no és el camí més còmode: si el desplegament automàtic està trencat —troballa 2— i hi ha una urgència, algú obrirà un terminal.

Canvi concret: Binary Authorization amb atestació emesa pel pipeline, que fa tècnicament impossible desplegar una imatge no verificada. Com a mesura intermèdia mentre s'implanta, retirar roles/container.developer sobre alpinashop-prod a les persones i deixar-lo només a sa-deploy-prod, amb accés d'emergència mitjançant impersonació registrada, tal com es va plantejar a 03-04.

La lliçó que unifica les tres troballes: un pipeline en verd no vol dir que el sistema funcioni. Vol dir que les comprovacions que vas escriure han passat. Si aquelles comprovacions mesuren el que no importa, si no verifiquen el resultat real del desplegament i si el pipeline es pot esquivar, el color verd és pitjor que no tenir pipeline, perquè genera una confiança que ningú no ha guanyat. Les tres troballes, a més, comparteixen un origen comú: ningú no estava mirant. Ni les mètriques, ni els registres, ni l'estat real de producció. Aquella és la mancança que s'ataca a 06-04 i 06-06.

AlpinaShop ha deixat de desplegar des del portàtil d'en Dani.

Saps distingir integració contínua —integrar sovint i verificar cada integració—, lliurament continu —estar sempre llest per desplegar, amb un botó— i desplegament continu —sense botó—, i saps per què AlpinaShop implanta els dos primers i ajorna el tercer fins a tenir la xarxa de seguretat que donen les proves i l'observabilitat.

Coneixes el model de Cloud Build: una seqüència de passos, cadascun un contenidor, sobre un /workspace compartit, amb la conseqüència pràctica que només persisteix el que s'escriu en aquell directori. Saps llegir i escriure un cloudbuild.yaml camp a camp —steps, name, args, env, id, waitFor, substitutions, images, artifacts, options, timeout—, paral·lelitzar amb waitFor perquè la velocitat del pipeline decideix si l'equip el fa servir, i aprofitar $PROJECT_ID i $COMMIT_SHA, amb l'advertiment que només tenen valor quan la compilació ve d'un activador.

Tens el pipeline real del catàleg: instal·lar a /workspace/lib, provar amb pytest i un llindar de cobertura que fa fallar la compilació, analitzar amb ruff i bandit en paral·lel, construir amb kaniko i memòria cau, publicar a Artifact Registry etiquetat amb el SHA i mai amb latest, i desplegar a alpinashop-dev comprovant que el desplegament convergeix de debò. Executant-se a alpinashop-cicd, el projecte que per fi té sentit.

Saps per què el teu build triga vuit minuts i com baixar-ho: memòria cau de kaniko, --cache-from amb el seu || true, i sobretot un Dockerfile ordenat del que és estable al que és volàtil. Coneixes els activadors per branca, per pull request, per etiqueta i manuals, i el filtre --included-files que evita compilar per una errada al README.

I tens el que més disgustos evita: el compte de servei de Cloud Build amb permisos mínims, tres rols i ni un més, perquè el pipeline és el sistema amb més privilegis de tota la infraestructura i l'antipatró de donar-li Editor converteix qualsevol pull request en un vector d'atac. Saps injectar secrets amb availableSecrets i $$, sense que acabin a Git ni als registres. Saps promocionar en lloc de reconstruir, amb aprovació manual i un compte de servei diferent per a producció. Coneixes els grups privats per compilar dins de la VPC, Cloud Deploy per quan el desplegament es compliqui amb canaris i diversos entorns, l'escaneig de vulnerabilitats d'Artifact Registry i Binary Authorization com a única manera que "a producció només arriba el del pipeline" sigui una garantia i no un desig.

I has tancat la primera punta solta del mòdul 5: el pipeline d'ML és al nivell 2 de maduresa, amb els components provats, la imatge d'entrenament etiquetada amb el commit i el llinatge responent amb un SHA concret a la pregunta d'amb quin codi es va entrenar cada model.

Queda, tanmateix, una pregunta incòmoda que hem anat esquivant durant tota la lliçó. Tot això es dispara des d'un repositori. Quin repositori? Perquè el codi del catàleg continua vivint al portàtil d'en Dani, i hi ha fitxers de configuració en una carpeta de Drive que algú va compartir fa any i mig. Un pipeline d'integració contínua sense un control de versions seriós és una casa construïda sobre sorra.

A 06-02 hi posem el fonament: repositoris, estratègia de branques, què ha d'estar versionat i què no, i la conversa honesta sobre Cloud Source Repositories davant de GitHub i GitLab.