Quan algú comença en CI/CD, l'obstacle més gran no sol ser el concepte: és el soroll. Jenkins, GitHub Actions, GitLab CI, CircleCI, Travis CI, Azure DevOps, Argo CD, Tekton, Spinnaker, Drone, Buildkite... la llista sembla infinita i fa la impressió que cal triar bé o es perden mesos. Aquesta lliçó és un mapa, no un tutorial. El seu objectiu és que sàpigues col·locar cada eina a la seva casella, entendre quines categories existeixen i per què, i descobrir una cosa que tranquil·litza molt: el 80 % del que aprenguis en una eina es transfereix a les altres, perquè totes implementen els mateixos conceptes que vam veure a 01-01. Al final justificarem per què el curs fa servir GitHub Actions i veurem la mateixa feina trivial escrita en dues eines diferents, perquè comprovis de primera mà que el que canvia és la sintaxi, no la idea.

1. Com està organitzat l'ecosistema
2. Categoria 1: servidors de CI/CD (el cor del pipeline)
3. Categoria 2: orquestradors de contenidors
4. Categoria 3: registres d'artefactes
5. Categoria 4: infraestructura com a codi
6. Categoria 5: desplegament continu GitOps
7. Les eines, una a una
8. Taula comparativa d'alt nivell
9. Per què aquest curs fa servir GitHub Actions
10. La mateixa feina en dues eines
11. Errors comuns i consells
12. Exercicis
13. Conclusió

El primer error en mirar aquest panorama és ficar totes les eines al mateix sac i comparar-les entre si. Argo CD no competeix amb Jenkins, igual que un tornavís no competeix amb una caixa d'eines: fan coses diferents en moments diferents del procés.

La manera útil d'organitzar l'ecosistema és per quina part del recorregut d'un canvi cobreix cada eina:

Cinc categories, cinc funcions diferents:

Un projecte real fa servir una de cada categoria, no una sola eina. Reservalia, al final del curs, farà servir: GitHub Actions (servidor de CI/CD) + Amazon ECR (registre) + ECS Fargate (orquestrador) + Terraform (IaC). Res d'això no és redundant.

És la categoria que ocupa la major part d'aquest curs, i la que genera més confusió. Dins seu, la distinció estructural més important és allotjat (SaaS) davant d'autogestionat.

Hi ha un model intermedi molt utilitzat: plataforma allotjada amb runners propis. És a dir, GitHub Actions coordina i mostra la interfície, però els jobs s'executen en màquines teves dins de la teva xarxa privada. Combina la comoditat del SaaS amb l'accés a sistemes interns i sol ser l'elecció d'empreses mitjanes amb requisits de xarxa o de compliment.

Una altra distinció que marca molt l'experiència diària:

• Al repositori (pipeline as code). El pipeline és un fitxer YAML versionat al costat del codi: es revisa en pull requests, es pot tornar enrere, viatja amb les branques. És el model de GitHub Actions, GitLab CI, CircleCI, Travis CI, Tekton i Jenkins modern amb Jenkinsfile.
• A la interfície del servidor (configuració clicada). El pipeline es configura clicant en formularis web i viu a la base de dades del servidor. És el model clàssic de Jenkins amb freestyle jobs, i també és possible a Azure DevOps.

La segona opció és un antipatró ben documentat: la configuració no es versiona, ningú no sap qui va canviar què, no es pot reproduir i recuperar el servidor després d'un desastre és un malson. Regla pràctica: si el teu pipeline no és al repositori, no està sota control. Hi aprofundirem a la lliçó 04-05.

Un servidor de CI/CD construeix i llança el desplegament, però no manté viva la teva aplicació. D'això se n'encarrega l'orquestrador: decideix a quina màquina corre cada contenidor, el reinicia si mor, l'escala si hi ha càrrega, comprova la seva salut i substitueix versions sense tallar el servei.

Reservalia farà servir ECS Fargate. És una decisió deliberada i realista per a un equip de tres persones: Kubernetes per a tres serveis i una SRE a temps parcial és sobreenginyeria. Kubernetes es veu a la lliçó 06-05, i el cas de microserveis a 05-03.

Recorda la regla d'or de 01-01: construir una vegada, promocionar el mateix artefacte. Perquè això sigui possible, l'artefacte ha de viure en algun lloc del qual tots els entorns el puguin recuperar. Aquest lloc és el registre.

Una propietat crítica d'un registre ben utilitzat: els artefactes són immutables. L'etiqueta reservalia/api:a3f9c21 ha d'apuntar sempre als mateixos bytes. Reetiquetar o sobreescriure destrueix la traçabilitat i fa impossible saber què hi ha realment en producció. Per això etiquetem amb el SHA del commit i no amb latest.

La Nuria, la SRE de Reservalia, va crear a mà a la consola d'AWS la base de dades RDS, el balancejador i les regles de xarxa. És ràpid... una vegada. El problema apareix quan cal crear un entorn de staging idèntic, o quan algú canvia alguna cosa un dimarts i a l'octubre ningú no recorda per què.

La infraestructura com a codi defineix aquests recursos en fitxers versionats:

El que és rellevant per a aquesta lliçó és la categoria: aquestes eines no executen pipelines, defineixen infraestructura. El pipeline les invoca. Terraform, OpenTofu, Pulumi, CloudFormation i Ansible hi juguen. Ho desenvoluparem a la lliçó 03-03.

És la categoria més recent i la que pitjor s'entén, així que mereix una explicació del mecanisme.

Els servidors de CI/CD tradicionals fan servir un model push: el pipeline acaba i empeny el desplegament a l'entorn. Per fer-ho, el pipeline necessita credencials amb permís per modificar producció.

GitOps inverteix la direcció. És un model pull: un agent instal·lat dins del clúster vigila contínuament un repositori Git que descriu l'estat desitjat. Quan detecta una diferència entre el que diu el repositori i el que hi ha al clúster, la corregeix ell mateix.

Avantatges del model pull: el pipeline mai no necessita credencials de producció (millora de seguretat important), el repositori és la font de veritat auditable, i les desviacions manuals es reverteixen soles. Inconvenient: afegeix una peça més i avui està molt lligat a Kubernetes.

Eines: Argo CD (interfície web molt visual, molt adoptat) i Flux (més minimalista, sense interfície pròpia per defecte).

Ara sí, la presentació individual. Per a cadascuna: model d'execució, on es defineix el pipeline i SaaS o autoallotjat.

• Model d'execució: fluxos de treball disparats per esdeveniments del repositori (push, pull_request, etiquetes, cron, despatx manual). Cada flux de treball conté jobs; cada job corre en un runner efímer (màquina virtual neta que es destrueix en acabar).
• On es defineix: fitxers YAML a .github/workflows/ dins del mateix repositori.
• SaaS o autoallotjat: SaaS, amb opció de runners autoallotjats a la teva infraestructura.
• Tret distintiu: el Marketplace d'accions, un catàleg enorme de passos reutilitzables (actions/checkout, actions/setup-node, aws-actions/configure-aws-credentials...). Redueix moltíssim el codi que escrius, però introdueix dependències de tercers que cal fixar i auditar (lliçó 04-03).
• Punt fort: proximitat total al repositori. L'esdeveniment, el codi, la revisió i el resultat són al mateix lloc.
• Punt feble: el model de reutilització (fluxos de treball reutilitzables i accions compostes) és menys flexible que un llenguatge de programació real, i els pipelines molt complexos poden tornar-se verbosos.

• Model d'execució: un fitxer de pipeline amb stages que agrupen jobs; cada job el recull un runner (amb executors diferents: Docker, shell, Kubernetes).
• On es defineix: .gitlab-ci.yml a l'arrel del repositori.
• SaaS o autoallotjat: tots dos. GitLab.com és SaaS; GitLab autogestionat és una de les opcions autoallotjades més completes del mercat.
• Tret distintiu: és una plataforma DevOps integrada: repositori, CI/CD, registre de contenidors, gestió d'incidències, escaneig de seguretat i entorns, tot al mateix producte i amb la mateixa autenticació.
• Punt fort: integració vertical i un model de plantilles (include, extends) molt potent per reutilitzar configuració entre projectes.
• Punt feble: si t'autogestiones GitLab, et fas càrrec d'una peça d'infraestructura grossa.

• Model d'execució: un servidor controlador que orquestra i uns agents que executen els jobs. Model clàssic de servidor persistent.
• On es defineix: idealment en un Jenkinsfile al repositori, escrit en un DSL basat en Groovy (declaratiu o scripted). Històricament també mitjançant formularis a la interfície web, cosa que produeix el deute tècnic que esmentàvem.
• SaaS o autoallotjat: autoallotjat, sempre. És programari lliure que instal·les tu.
• Tret distintiu: un ecosistema de més de mil plugins. Es pot integrar literalment amb qualsevol cosa. Aquesta és també la seva maledicció: els plugins tenen qualitats i ritmes de manteniment molt dispars, i les incompatibilitats entre versions són un clàssic.
• Punt fort: control absolut, maduresa de més de dues dècades, i el Jenkinsfile, en ser codi real, permet lògica complexa que en YAML seria impossible.
• Punt feble: cost d'administració alt (actualitzacions, seguretat, gestió d'agents) i una interfície que mostra la seva edat. Tot i així, continua sent dominant en grans empreses i en entorns amb sistemes interns que mai no sortiran al núvol.
• Lliçó 06-01.

• Model d'execució: jobs que s'executen en contenidors Docker o màquines virtuals, amb suport natiu per a paral·lelització i divisió automàtica del conjunt de tests.
• On es defineix: .circleci/config.yml al repositori.
• SaaS o autoallotjat: principalment SaaS; ofereix runners propis i una edició per a servidor.
• Tret distintiu: els orbs, paquets reutilitzables de configuració (equivalent conceptual a les accions de GitHub), i una atenció molt marcada al rendiment i al temps d'execució del pipeline.
• Punt fort: rapidesa, bones eines de memòria cau i paral·lelisme, agnòstic respecte al proveïdor de repositori.
• Punt feble: una peça més fora de la teva plataforma de repositori, amb la seva pròpia facturació i la seva pròpia gestió d'accessos.
• Lliçó 06-03.

• Model d'execució: builds disparades per esdeveniments del repositori, executades en màquines virtuals o contenidors.
• On es defineix: .travis.yml a l'arrel del repositori.
• SaaS o autoallotjat: SaaS (amb una edició empresarial).
• Tret distintiu: és històricament important: va ser el primer a popularitzar el model d'"un YAML al teu repositori dispara el teu CI" i a oferir-ho gratis a projectes de codi obert. Pràcticament tot el que avui donem per fet va començar allà.
• Situació actual: després del canvi del seu model gratuït per a codi obert, gran part de l'ecosistema va migrar a GitHub Actions i la seva quota es va reduir molt. L'estudiarem a 06-04 per dues raons: continua havent-hi projectes que el fan servir i cal saber llegir-lo, i la seva configuració és la més senzilla de totes, cosa que la fa excel·lent per entendre l'essència d'un pipeline.

• Model d'execució: pipelines amb stages, jobs i steps, executats en agents allotjats per Microsoft o propis.
• On es defineix: azure-pipelines.yml al repositori (o mitjançant l'editor clàssic visual, que és el model antic).
• SaaS o autoallotjat: SaaS (Azure DevOps Services) o autoallotjat (Azure DevOps Server, abans TFS).
• Tret distintiu: forma part d'una suite completa (Boards, Repos, Artifacts, Test Plans) molt implantada en organitzacions amb inversió en l'ecosistema Microsoft, i amb suport excel·lent per a .NET i Windows.
• Punt fort: entorns d'aprovació i controls de governança molt elaborats, útils en empreses amb processos formals de release.
• Punt feble: conviuen dos models (clàssic visual i YAML) i la documentació històrica els barreja tots dos, cosa que confon qui comença.

• Model d'execució: no és un servidor de CI. És un controlador que viu dins d'un clúster de Kubernetes i reconcilia contínuament l'estat del clúster amb el declarat en un repositori Git.
• On es defineix: manifestos de Kubernetes (o Helm/Kustomize) en un repositori Git.
• SaaS o autoallotjat: autoallotjat al teu clúster (hi ha ofertes gestionades de tercers).
• Tret distintiu: és la referència de GitOps. Es combina, no es substitueix: GitHub Actions construeix i publica l'artefacte, actualitza el manifest, i Argo CD s'encarrega de portar-lo al clúster.
• Quan té sentit: quan ja fas servir Kubernetes. Sense Kubernetes, ara com ara, no aplica.

• Model d'execució: un framework de CI/CD natiu de Kubernetes: cada pas del pipeline és un contenidor i cada execució és un recurs de Kubernetes (Task, Pipeline, PipelineRun).
• On es defineix: manifestos YAML de Kubernetes, versionats al repositori.
• SaaS o autoallotjat: autoallotjat sobre Kubernetes; és la base de diversos productes comercials.
• Tret distintiu: no és una eina "d'utilitzar", és una base per construir la teva pròpia plataforma de CI/CD. Molt potent i molt de baix nivell.
• Quan té sentit: organitzacions grans que construeixen una plataforma interna per a molts equips. Per a un equip de tres persones és clarament excessiu.

Un advertiment sobre aquesta taula: no triïs pel nombre de caselles verdes. A la pràctica, el criteri que més pesa és on viu el teu codi i què sap mantenir el teu equip. Els criteris formals d'elecció els sistematitzarem a la lliçó 06-07.

L'elecció d'aquest curs és GitHub Actions, i convé explicar-ne els motius perquè sàpigues quins són transferibles al teu cas i quins no:

1. Proximitat al repositori. El pipeline viu al mateix lloc que el codi. L'esdeveniment que el dispara (un pull request), la revisió, el resultat i l'històric són a la mateixa pantalla. Per aprendre, això elimina una barrera enorme: no hi ha un segon sistema per configurar ni credencials creuades.
2. Model declaratiu i llegible. Un flux de treball de GitHub Actions es llegeix de dalt a baix gairebé com prosa. En ser declaratiu, descrius què vols, no com orquestrar-ho. Això fa que els exemples del curs siguin fàcils d'entendre encara que no hagis vist mai l'eina.
3. Cost zero per començar. Els repositoris públics tenen execució gratuïta, i els privats una quota mensual generosa. Pots reproduir tots els exemples del curs sense pagar res.
4. Adopció molt àmplia. És avui l'eina més probable que et trobis en un projecte nou, i apareix constantment en ofertes de feina.
5. Els conceptes són universals. Tot el que aprendràs —triggers, jobs, matrius, artefactes, memòria cau, secrets, entorns amb aprovació, promoció— existeix amb un altre nom a totes les altres. La secció següent ho demostra.

I per honestedat, els motius pels quals podries triar-ne una altra:

• El teu codi no és a GitHub → GitLab CI o CircleCI encaixen millor.
• Necessites accedir a sistemes interns que no surten de la teva xarxa → Jenkins o runners autoallotjats.
• La teva organització ja té una plataforma establerta → aprèn aquesta; el coneixement es transfereix igual.

El mòdul 6 aprofundeix en cada eina per separat (Jenkins a 06-01, GitLab CI a 06-02, CircleCI a 06-03, Travis CI a 06-04, Docker i Kubernetes a 06-05, GitHub Actions a fons a 06-06) i a la lliçó 06-07 veurem els criteris formals per triar. A més, en aquest mòdul reexpressarem el mateix pipeline de Reservalia en cada eina, que és la millor manera de comprovar que el que s'ha après es transfereix.

Vegem-ho ja, en petit. La feina és deliberadament trivial: instal·lar les dependències i executar els tests d'apps/api quan algú empeny codi.

Important: no cal que entenguis cada línia. Aquí només volem que comparis les dues columnes i vegis que diuen el mateix. La construcció real del pipeline de Reservalia comença a la lliçó 02-02.

Posa les dues al costat i veuràs que els conceptes són idèntics; només canvia on s'escriu cadascun:

Les dues diferències filosòfiques que expliquen gairebé tota la resta:

• GitHub Actions aposta per accions reutilitzables del Marketplace (setup-node, checkout), que encapsulen feina. Escrius menys, però depens de tercers.
• GitLab CI aposta per imatges Docker com a unitat d'entorn. Més explícit i amb menys màgia, però tries tu la imatge correcta.

I el que no canvia en cap eina del món:

1. Un esdeveniment del repositori dispara l'execució.
2. Es prepara una màquina neta amb el codi.
3. S'instal·len dependències de manera reproduïble.
4. S'executen ordres.
5. Si una ordre retorna un codi de sortida diferent de zero, el pipeline falla.

Aquest darrer punt és especialment alliberador: la unitat universal d'èxit o fracàs en CI/CD és el codi de sortida d'un procés. Totes les eines, sense excepció, s'hi recolzen.

Error 1: comparar eines de categories diferents. "Què és millor, Jenkins o Argo CD?" és una pregunta mal plantejada: l'un executa pipelines i l'altre sincronitza clústers. Abans de comparar, situa cada eina a la seva casella del mapa de la secció 1.

Error 2: triar per popularitat. Que Kubernetes sigui l'estàndard no vol dir que el teu equip de tres persones el necessiti. La millor eina és la que el teu equip pot mantenir sense dedicar-li un terç del seu temps. Reservalia tria ECS Fargate justament per això.

Error 3: creure que l'elecció és irreversible. Com acabes de veure, migrar un pipeline entre eines és sobretot una feina de traducció de sintaxi. El que sí que costa migrar és el que està mal fet: pipelines configurats des d'una interfície web, scripts immensos i impossibles de llegir o secrets incrustats al YAML. Inverteix en què el teu pipeline estigui ben fet, no en triar l'eina perfecta.

Error 4: configurar el pipeline des de la interfície gràfica. És temptador perquè és ràpid. Sis mesos després ningú no sap qui va canviar què, no es pot revertir i recuperar el servidor és impossible. Tot pipeline ha de viure al repositori.

Error 5: acumular eines sense necessitat. Afegir Argo CD "perquè és GitOps" a un projecte que ni tan sols fa servir Kubernetes afegeix complexitat sense benefici. Cada eina nova és un sistema més per aprendre, mantenir, actualitzar i depurar a les tres de la matinada.

Consell 1: aprèn-ne una a fons abans que cinc per sobre. El coneixement profund d'una eina es transfereix; el coneixement superficial de cinc, no. Per això aquest curs construeix tot en GitHub Actions i només al final, al mòdul 6, tradueix.

Consell 2: fes servir el criteri "on viu el meu codi". És el filtre més eficaç. GitHub → GitHub Actions. GitLab → GitLab CI. Servidor Git intern → Jenkins o GitLab autoallotjat. Aquest criteri simple encerta en la gran majoria de casos.

Consell 3: fixa les versions de les accions i plugins que facis servir. actions/checkout@v4 en comptes d'actions/checkout@main. Una acció de tercers és codi aliè executant-se amb accés al teu repositori. És una superfície d'atac real i li dedicarem atenció a la lliçó 04-03.

Consell 4: en llegir documentació, tradueix-la mentalment als conceptes de 01-01. Quan trobis un terme nou, pregunta't: això és un trigger, un job, una etapa, un runner o un artefacte? Gairebé sempre és una d'aquestes cinc coses amb un altre nom, i aquesta traducció converteix la documentació de qualsevol eina en una cosa familiar.

Col·loca cada eina a la seva categoria del mapa de la secció 1 (servidor de CI/CD, orquestrador de contenidors, registre d'artefactes, IaC o desplegament GitOps) i indica en una frase quin problema resol:

1. Terraform
2. Amazon ECR
3. Flux
4. Amazon ECS Fargate
5. CircleCI
6. Nexus
7. Kubernetes
8. Tekton

Tradueix el flux de treball següent de GitHub Actions a .gitlab-ci.yml. Afegeix després una taula d'equivalències concepte a concepte.

Per a cada equip, recomana una combinació d'eines (servidor de CI/CD + registre + destinació d'execució, i GitOps o IaC si escau) i justifica cada elecció en una o dues frases. No hi ha una única resposta correcta; es valora la justificació.

1. Reservalia. Tres persones. Codi a GitHub. Despleguen a AWS amb ECS Fargate. Cap experiència prèvia en CI/CD. Pressupost molt ajustat.
2. Banc Meridiano. Equip de plataforma de 40 persones. El codi és en un servidor Git intern que no pot sortir de la xarxa corporativa per normativa. Despleguen a un Kubernetes local. Necessiten aprovacions registrades i auditables per cada desplegament a producció.
3. Ludika. Estudi de videojocs de 15 persones. Codi a GitLab.com. Compilen builds per a Windows, macOS i Linux a cada release. Els artefactes pesen diversos gigabytes.

Solució a l'Exercici 1

Dues observacions que convé haver notat:

• Flux i Tekton són tots dos "a Kubernetes" però no són la mateixa categoria. Tekton executa pipelines (construeix i prova); Flux sincronitza l'estat desplegat. Es fan servir junts, no l'un en lloc de l'altre.
• ECR i Nexus són a la mateixa categoria encara que l'un sigui un servei gestionat d'AWS i l'altre un producte instal·lable: la categoria la defineix la funció, no el model de distribució.

Solució a l'Exercici 2

Taula d'equivalències:

Un matís subtil que val la pena entendre: a GitHub Actions cada run és un shell independent, per això cal repetir working-directory a cada pas —un cd en un pas no afecta el següent. A GitLab, totes les ordres de script comparteixen el mateix shell, així que un sol cd n'hi ha prou. Aquesta diferència sorprèn molta gent en migrar en qualsevol dels dos sentits.

Solució a l'Exercici 3

1. Reservalia

• Servidor de CI/CD: GitHub Actions. El codi ja és a GitHub: sense sistemes addicionals, sense credencials creuades i amb quota gratuïta suficient per a un equip de tres. Cost d'arrencada pràcticament nul, que és determinant sense experiència prèvia ni pressupost.
• Registre: Amazon ECR. És al mateix núvol que l'execució, l'autenticació es resol amb IAM i les descàrregues dins de la mateixa regió no generen trànsit sortint facturable.
• Execució: ECS Fargate. Ja és la seva destinació. És la decisió correcta per a tres persones: contenidors sense administrar un clúster. Kubernetes aquí seria sobreenginyeria i consumiria el temps de la Nuria.
• IaC: Terraform, a partir del mòdul 3, perquè staging i prod siguin reproduïbles i no depenguin del que la Nuria recordi haver clicat.
• GitOps: no. No fan servir Kubernetes; Argo CD no hi aporta res i sí complexitat.

2. Banc Meridiano

• Servidor de CI/CD: Jenkins autoallotjat (o GitLab autogestionat). És el criteri decisiu: el codi no pot sortir de la xarxa. Qualsevol SaaS queda descartat per normativa, no per preferència. La mida de l'equip (40 persones) justifica el cost d'administració, que a Reservalia seria prohibitiu.
• Registre: Artifactory o Nexus a la xarxa interna, amb funció afegida de proxy de dependències externes: útil quan la sortida a internet està restringida.
• Execució: el seu Kubernetes local, ja existent.
• GitOps: Argo CD, molt recomanable. Aquí encaixa perfectament per dues raons: ja tenen Kubernetes, i el model pull elimina la necessitat que el sistema de CI tingui credencials de producció, cosa que és un argument de pes davant d'un auditor. A més, el repositori Git de manifestos es converteix en el registre auditable de què es va desplegar, quan i aprovat per qui.
• Aprovacions: portes manuals obligatòries abans de producció. És un cas clar de Lliurament Continu i no de Desplegament Continu, i aquesta porta és un requisit regulador, no una mancança.

3. Ludika

• Servidor de CI/CD: GitLab CI/CD. El codi és a GitLab.com: aplica el criteri "on viu el meu codi". A més, el registre de paquets i contenidors ve integrat al mateix producte.
• Registre: GitLab Package Registry, amb una excepció important: builds de diversos gigabytes per plataforma i per release consumeixen emmagatzematge molt de pressa. Cal definir una política de retenció des del primer dia (per exemple, conservar totes les builds de release i només les últimes N de desenvolupament) o la factura es descontrola.
• Execució multiplataforma: runners propis. Aquí hi ha una restricció que molta gent descobreix tard: compilar per a macOS requereix maquinari Apple, per llicència. Caldrà fer servir runners macOS propis o allotjats d'un proveïdor especialitzat, i sabent que el seu cost per minut és sensiblement més alt.
• Consideració addicional: amb artefactes tan pesants, el temps i el cost de pujada i baixada dominen el pipeline. Val la pena invertir en memòria cau de dependències i en compilació incremental abans que en qualsevol altra optimització (matèria de la lliçó 04-04).
• GitOps: no aplica. El producte no es desplega en un clúster; es distribueix a usuaris finals.

Aquesta lliçó ha ordenat el soroll de l'ecosistema:

• Les eines s'organitzen en cinc categories complementàries: servidors de CI/CD, orquestradors de contenidors, registres d'artefactes, infraestructura com a codi i desplegament GitOps. No competeixen entre categories: es combinen.
• Dins dels servidors de CI/CD, les dues preguntes que més defineixen l'experiència són SaaS o autoallotjat i on es defineix el pipeline. I hi ha una resposta que no admet matisos: el pipeline ha de viure al repositori, mai en formularis d'una interfície web.
• Hem situat GitHub Actions, GitLab CI/CD, Jenkins, CircleCI, Travis CI, Azure DevOps Pipelines, Argo CD i Tekton, cadascuna amb el seu model d'execució i el seu terreny natural.
• El curs farà servir GitHub Actions per la seva proximitat al repositori, el seu model declaratiu llegible i el seu cost nul per començar; el mòdul 6 aprofundeix en cada eina i reexpressa el pipeline de Reservalia en unes quantes.
• I el més important: en comparar la mateixa feina en GitHub Actions i en GitLab CI hem comprovat que el que canvia és la sintaxi, no els conceptes. Trigger, job, etapa, runner, passos i codi de sortida hi són a totes. El que aprenguis aquí es transfereix.

Ja sabem què és CI/CD, per què val la pena i amb què es construeix. Falta el més concret: què automatitzarem exactament. A la lliçó següent, El Projecte del Curs: l'Aplicació que Automatitzarem, coneixerem Reservalia a fons: el seu producte, el seu equip, l'estructura real del repositori, els scripts que el pipeline invocarà, els seus tres entorns i la infraestructura AWS de destinació. També veurem el full de ruta de què haurem automatitzat al final de cada mòdul i què necessites instal·lat per seguir els exemples, facis servir Node.js o no.