GitLab CI/CD

Ciao, sono Alex di DEV STORIES DOT EU. GitLab CI/CD, episodio 1 di 14. Molti team di sviluppo si affidano a processi di release disordinati e non documentati, che solo una persona comprende veramente. Il percorso effettivo verso la produzione rimane invisibile finché qualcosa non si rompe. Il paradigma dot gitlab dash c i dot yml cambia tutto questo, traducendo l'intero ciclo di vita di build e release in un grafico sequenziale trasparente. GitLab CI/CD è il sistema integrato di continuous integration e continuous deployment di GitLab. È interamente controllato da un singolo file di configurazione chiamato dot gitlab dash c i dot yml. Metti questo file nella root directory del repository del tuo progetto. Poiché viene committato insieme al codice della tua applicazione, il tuo processo di deploy è sotto version control, verificabile e accessibile a qualsiasi sviluppatore che guardi il repository. Quando fai il push di un commit che contiene questo file, GitLab lo rileva immediatamente e triggera una pipeline. Una pipeline è l'architettura di alto livello del tuo processo di CI/CD. È composta da due componenti principali: job e stage. I job dettano cosa accade effettivamente. Un job contiene gli specifici comandi shell o script necessari per eseguire un task, come compilare il codice sorgente, formattare il testo o spostare file su un server. Gli stage dettano quando quei job vengono eseguiti. Organizzi i job in stage per controllare il flusso cronologico di esecuzione. Considera una pipeline standard con tre stage. In cima al tuo file di configurazione YAML, dichiari i tuoi stage nell'ordine esatto in cui vuoi che vengano eseguiti: build, test e deploy. Sotto questo elenco, definisci i tuoi singoli job e li associ a quegli stage definiti. Inizi scrivendo un job chiamato build dash job e lo assegni allo stage di build. Il suo script dice al sistema di compilare la tua applicazione. Successivamente, scrivi un job chiamato test dash job, lo assegni allo stage di test e fornisci il comando per eseguire la tua test suite. Infine, scrivi un job deploy dash prod, lo colleghi allo stage di deploy e gli dai le istruzioni per fare il push dell'applicazione compilata nel tuo ambiente di produzione. Ecco il punto chiave. GitLab elabora questi stage rigorosamente in sequenza. La pipeline inizia con lo stage di build. Il sistema esegue il tuo job di build. Se quel job termina con successo, la pipeline passa automaticamente allo stage di test ed esegue il job di test. Se i test passano, va avanti allo stage di deploy. Questo ordine rigoroso funge da vero e proprio quality gate. Se un job fallisce in qualsiasi punto, ad esempio se un unit test fallisce durante lo stage di test, l'intera pipeline si ferma. Lo stage di deploy non verrà mai eseguito, il che significa che il codice rotto non può raggiungere la produzione. Poiché questa logica è dichiarata chiaramente nel file YAML, la user interface di GitLab la traduce in un grafico visivo della pipeline. Chiunque nel tuo team può visualizzare un commit, guardare il grafico e capire all'istante esattamente a che punto della pipeline si trova il codice, quale stage ha avuto successo e precisamente dove si è verificato un errore. Il punto di forza principale di questo paradigma è la centralizzazione. Definendo stage e job in un unico root file, la tua sequenza di deploy smette di essere un mistero e diventa un processo leggibile e ripetibile che vive esattamente nello stesso posto del tuo codice. Se ti va di supportare lo show, puoi cercare DevStoriesEU su Patreon. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. GitLab CI/CD, episodio 2 di 14. Passi ore a scrivere un file di configurazione della pipeline perfetto, fai il commit e aspetti. Ma non succede nulla. La tua pipeline è completamente inutile senza un motore computazionale pronto a prendere in carico quelle istruzioni. È qui che entrano in gioco i GitLab Runner e gli Executor. C'è un malinteso comune secondo cui è l'applicazione GitLab stessa a eseguire i tuoi script di build. Non è così. GitLab gestisce il repository e tiene traccia dello stato delle tue pipeline, ma delega rigorosamente l'esecuzione effettiva. Un GitLab Runner è un'applicazione separata che opera come agent. Fa un polling continuo sull'istanza di GitLab, chiedendo se ci sono job in sospeso che è autorizzato a gestire. Quando ne trova uno, fa il pull del payload del job, esegue i comandi e invia i log e i risultati a GitLab. Hai due opzioni principali per procurarti questi agent. La strada più semplice è usare i runner hosted da GitLab. Questi vengono gestiti per te su GitLab SaaS e coprono ambienti comuni come Linux, macOS e Windows. Spesso, però, hai bisogno di un setup personalizzato. Magari la tua build richiede hardware specializzato, come una GPU specifica, o ha bisogno di accedere a una rete interna privata. In quel caso, usi i runner self-managed. Installi l'applicazione runner sulla tua infrastruttura. Puoi definire lo scope di questi runner self-managed a livello globale su un'intera istanza GitLab, condividerli tra un gruppo di progetti correlati, o bloccarli su un singolo progetto specifico. Una volta che un runner prende in carico un job, deve sapere esattamente come e dove eseguire i comandi. Questo viene definito dall'executor. L'executor detta lo specifico ambiente di esecuzione per il job. Due dei tipi più comuni sono l'executor shell e l'executor Docker. L'executor shell è molto semplice. Esegue il job direttamente sul sistema operativo della macchina host usando una shell da terminale standard, come Bash o PowerShell. Per questo motivo, tutte le dipendenze devono essere preinstallate su quella macchina host. L'executor Docker funziona in modo diverso. Tira su un container nuovo e isolato per ogni singolo job, ci fa girare gli script all'interno e lo butta giù subito dopo. Questo garantisce un ambiente completamente pulito ogni volta. Vediamo uno scenario concreto registrando un runner di progetto self-managed in locale usando un executor shell. Per prima cosa, vai nelle impostazioni specifiche del tuo progetto su GitLab e crei un nuovo runner. GitLab genererà un token di autenticazione univoco. Dopodiché, installi l'applicazione GitLab Runner sulla tua macchina locale. Dal tuo terminale locale, esegui il comando register. Il prompt ti chiederà due informazioni principali. Ha bisogno dell'URL della tua istanza GitLab e del token di autenticazione che hai appena generato. Questo passaggio collega in modo sicuro la tua macchina locale a quello specifico progetto. Infine, il setup ti chiederà di scegliere un executor. Digiti shell. Da quel momento in poi, ogni volta che un job viene triggerato in quel progetto GitLab, la tua macchina locale ne farà il pull ed eseguirà i comandi direttamente nel suo ambiente terminale locale. Ecco il punto chiave. GitLab è l'orchestratore, ma il Runner e il suo Executor formano la vera e propria fabbrica. Disaccoppiando la gestione dei job dall'esecuzione dei job, ottieni la flessibilità di far girare le pipeline su qualsiasi cosa, da un container cloud condiviso a un server bare-metal in uno scantinato chiuso a chiave. Grazie per l'ascolto, buon coding a tutti!

Ciao, sono Alex di DEV STORIES DOT EU. GitLab CI/CD, episodio 3 di 14. Hai una pipeline con venti job, e ognuno di essi inizia eseguendo esattamente lo stesso comando di setup. Quando questo processo di setup cambia, ti ritrovi con venti punti diversi da aggiornare, e dimenticarne anche solo uno romperà la tua build. Risolvere questa ripetizione inizia dal capire l'anatomia di un job CI/CD. Un job è l'unità di esecuzione fondamentale in GitLab CI/CD. È definito da un nome e deve contenere almeno un comando da eseguire. Questo blocco di esecuzione principale viene definito usando la keyword script. Lo script rappresenta un array di comandi eseguiti in sequenza dal runner. Se un comando fallisce, il job si interrompe immediatamente e viene contrassegnato come fallito. I job raramente girano in un ambiente isolato. Spesso hanno bisogno che l'ambiente venga preparato prima dell'esecuzione, e a volte richiedono un cleanup successivo. È qui che entrano in gioco le keyword before script e after script. Prendi ad esempio un progetto Ruby. Prima di lanciare i tuoi test o eseguire un linter, devi installare le dipendenze. Metti il tuo comando bundle install all'interno del blocco before script. Il runner esegue prima questo before script. Se ha successo, parte lo script principale. Una volta finito lo script principale, viene eseguito l'after script. Ecco il punto chiave. L'after script gira anche se lo script principale fallisce. Questo lo rende il posto giusto per chiudere le connessioni di rete, cancellare le credenziali temporanee o fare il cleanup dei database di test. Scrivere lo stesso comando bundle install dentro ogni singolo job di test diventa ripetitivo in fretta. Per risolvere questo problema, usi la keyword default al livello principale del tuo file di configurazione. Qualsiasi configurazione definita sotto default viene ereditata automaticamente da tutti i job nella pipeline. Dichiari il tuo before script con bundle install una volta sola all'interno del blocco default. Ora, ogni job lo esegue automaticamente. Se un job specifico non ne ha bisogno, definisci un before script vuoto all'interno di quel job specifico. Quella definizione locale fa l'override del default globale. A volte hai bisogno della definizione di un job nel tuo file, ma non vuoi che venga effettivamente eseguito. Potresti star scrivendo un template di base da cui erediteranno altri job, oppure potresti voler disabilitare temporaneamente un flaky test senza eliminare completamente il codice. Puoi farlo nascondendo il job. Ti basta aggiungere un punto proprio all'inizio del nome del job. Quando GitLab fa il parsing della configurazione della pipeline, ignora completamente qualsiasi nome di job che inizia con un punto. Il job non apparirà nell'interfaccia utente e non verrà eseguito. Man mano che la tua pipeline cresce, l'interfaccia web può riempirsi di decine di job individuali. Se hai diversi job strettamente correlati, puoi raggrupparli visivamente nel grafico della pipeline. Puoi farlo dando ai job un prefisso condiviso, seguito da uno slash o da due punti. Ad esempio, se chiami tre job separati build slash ruby uno, build slash ruby due e build slash ruby tre, l'interfaccia li raggrupperà in un unico gruppo a tendina etichettato semplicemente build. Cliccando sul gruppo, questo si espande per mostrare i singoli job al suo interno. Questo non cambia nulla nel modo in cui i job vengono eseguiti sui runner, ma rende una pipeline enorme molto più facile da leggere a colpo d'occhio. Una pipeline ben strutturata separa il setup dall'esecuzione, usa i default per eliminare il codice duplicato, e si affida alle naming convention per mantenere l'interfaccia visiva focalizzata strettamente su ciò che conta. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. GitLab CI/CD, episodio 4 di 14. Hardcodare una API key direttamente nella configurazione della tua pipeline è il modo più rapido in assoluto per compromettere l'intero ambiente di produzione. Ti serve un modo per passare dinamicamente configurazione e credenziali ai tuoi job, senza esporle a chiunque possa leggere il tuo repository. Le variabili CI/CD e i secret sono i meccanismi che gestiscono questo aspetto. Ogni volta che un runner di GitLab prende in carico un job, non parte da uno stato vuoto. GitLab inietta automaticamente delle variabili predefinite nell'environment. Queste forniscono al tuo script un contesto immediato. Hai accesso a variabili come CI commit branch, il pipeline ID e il nome del progetto. Non sei tu a definirle. Sono semplicemente lì, pronte per essere usate nei tuoi script per instradare la logica o taggare gli artifact di build. Oltre al contesto predefinito, dovrai fornire le tue variabili custom. Puoi definirle in due posti: all'interno del tuo file di configurazione yaml, o nella UI di GitLab. La regola per scegliere dove metterle è semplice. Se il valore può essere letto in sicurezza, come un flag del compilatore o l'URL di un server di sviluppo, mettilo nel file yaml. La configurazione rimane con il codice. Se il valore è sensibile, come la password di un database, definiscilo nella UI del progetto GitLab. Quando inserisci un secret nella UI, devi configurare i suoi limiti di sicurezza. Spesso si fa confusione tra mascherare una variabile e proteggere una variabile. Sono concetti completamente diversi. Mascherare una variabile impedisce che il suo valore compaia nei log del job. Se mascheri la password di un database, e uno script scritto male cerca di stamparla in console, GitLab intercetta l'output stream. Sostituisce il testo effettivo della password con una string di asterischi prima ancora che il log venga salvato. Il masking controlla la visibilità nei log. Ecco il punto chiave. Il masking non impedisce in alcun modo a uno sviluppatore di scrivere uno script che invia la password a un server esterno. È qui che entra in gioco la protezione. Proteggere una variabile ne limita la disponibilità. Una variabile protetta viene iniettata solo nelle pipeline che girano su branch protetti o tag protetti. Se qualcuno apre una merge request da un normale feature branch, la pipeline che triggera semplicemente non conterrà quella variabile. Questo impedisce al codice non attendibile di accedere ai secret di produzione. Inoltre, puoi usare delle impostazioni nascoste nella UI per i casi di estrema sensibilità. Una volta salvata una variabile, il suo valore viene oscurato nell'interfaccia. Nemmeno i maintainer del progetto possono recuperare facilmente il raw text in un secondo momento, il che significa che chi ha accesso non può semplicemente fare scraping della pagina delle impostazioni per rubare tutti i tuoi token. Ora, considera come la variabile arriva alla tua applicazione. La maggior parte delle variabili viene iniettata come environment variable standard. Ma alcuni tool si rifiutano di leggere le environment variable e insistono per leggere da un file fisico. La command line interface di AWS, ad esempio, spesso si aspetta un file di credenziali formattato residente su disco. Invece di scrivere uno script per la pipeline che crea un file, ci butta dentro il testo della variabile e poi cerca di eliminarlo in modo sicuro in seguito, puoi usare una variabile di tipo File. Quando configuri una variabile come tipo File nella UI, il runner gestisce la logistica automaticamente. Quando il job parte, il runner prende il valore di testo, lo scrive in modo sicuro in un file temporaneo sul disco del runner, e imposta l'environment variable in modo che contenga il percorso del file, non il suo contenuto. Ti basta puntare il tuo tool AWS al percorso fornito dalla variabile. Quando il job finisce, il runner distrugge il file automaticamente. Mettere in sicurezza la tua pipeline significa ridurre al minimo l'esposizione in ogni fase. Non affidarti al log masking per proteggerti dal codice malevolo, e non scrivere tu stesso file di credenziali temporanei quando il runner può gestirne il lifecycle in modo sicuro. Questo è tutto per questo episodio. Grazie per aver ascoltato, e keep building!

Ciao, sono Alex di DEV STORIES DOT EU. GitLab CI/CD, episodio 5 di 14. Il tuo job di build si completa perfettamente, ma il tuo job di deployment fallisce misteriosamente con un errore di file not found. Controlli il runner, e i file sono stati sicuramente generati pochi minuti prima. Il problema di solito si riduce a un'incomprensione fondamentale tra due keyword: artifacts e cache. Questi due concetti vengono spesso confusi perché entrambi implicano il salvataggio di file su un runner, ma esistono per ragioni completamente diverse. La keyword cache definisce un elenco di file e directory pensati per velocizzare la tua pipeline. Memorizza le dipendenze scaricate tra diverse run della pipeline. Prendiamo come esempio un progetto Node standard. Il tuo job di build richiede migliaia di pacchetti nella cartella node modules. Invece di scaricarli dal registry pubblico ogni singola volta che uno sviluppatore fa un push del codice, configuri una cache. Le assegni una key basata sul tuo file package lock e la punti alla directory node modules. Nelle run successive, GitLab ripristina localmente quei file. Ecco il punto chiave. Il caching è strettamente un'ottimizzazione. Se la cache viene svuotata, scade o fallisce l'estrazione, il tuo job deve comunque poter girare e completarsi con successo scaricando i pacchetti da zero. Una cache mancante significa solo una pipeline più lenta, non una pipeline rotta. La logica del tuo job non dovrebbe mai dipendere dalla presenza di una cache. Gli artifacts servono a uno scopo architetturale completamente diverso. La keyword artifacts specifica i file e le directory generati da un job che devono essere passati ai job successivi all'interno della stessa run della pipeline. Non sono un'ottimizzazione. Sono un requisito strutturale per il tuo flusso di CI. Tornando al progetto Node, il tuo job di build compila il tuo codice sorgente in una directory di output finale chiamata dist. Il tuo job di deployment gira in uno stage successivo e ha bisogno esattamente di quella cartella dist per fare il push sul tuo server di produzione. Dato che i job girano in ambienti isolati, il job di deploy non può semplicemente accedere al workspace del job di build. Colmi questo divario usando gli artifacts. Definisci la cartella dist sotto la keyword artifacts nel tuo job di build. Al successo del job, GitLab prende quei file, li impacchetta e li allega alla pipeline. Quando il job di deployment downstream si avvia, GitLab scarica automaticamente quel pacchetto di artifacts e lo estrae nella working directory. Se manca un artifact, il job downstream fallirà perché i file richiesti letteralmente non esistono nel workspace. A differenza di una cache, non puoi semplicemente scaricare un artifact da internet se manca. Contiene lo stato intermedio e univoco della tua run corrente della pipeline. In un file YAML configurato correttamente, spesso li usi entrambi nello stesso job di build. Imposti la cache in modo che punti alla cartella delle tue dipendenze per risparmiare tempo. Imposti gli artifacts in modo che puntino alla tua cartella di output compilato per passare i dati in avanti. Il job di deployment più avanti nella pipeline non ha affatto bisogno della cache. Richiede solo il codice compilato, che riceve senza problemi perché gli artifacts vengono scaricati di default in tutti gli stage successivi. Quando configuri la tua prossima pipeline, ricorda questa regola. Usa la cache per le dipendenze esterne che scarichi per risparmiare tempo, e usa gli artifacts per i risultati interni della build che devi passare in avanti per completare il deployment. Questo è tutto per oggi. Grazie per l'ascolto: vai a creare qualcosa di fantastico.

Ciao, sono Alex di DEV STORIES DOT EU. GitLab CI/CD, episodio 6 di 14. Hai appena committato la correzione di un typo in un file markdown, e improvvisamente la tua pipeline fa partire una test suite end-to-end di venti minuti. Questo è un enorme spreco sia di minuti di compute che della tua pazienza. Per evitare di eseguire job pesanti quando non sono necessari, puoi controllare l'esecuzione usando la keyword rules. La keyword rules determina esattamente quando un job viene aggiunto a una pipeline. Se usi GitLab da un po' di tempo, potresti ricordarti di aver usato only ed except per filtrare i job. Quelle sono keyword legacy. Rules è l'alternativa moderna e più potente. Dietro le quinte, rules accetta una lista di condizioni. GitLab valuta questa lista dall'alto verso il basso. Non appena trova un match, smette di cercare e aggiunge il job oppure lo salta, a seconda di come hai configurato quella specifica regola. Ci sono tre condizioni principali che puoi valutare. La prima è if. La condizione if valuta le variabili della pipeline usando una semplice espressione logica. Puoi dire a un job di deploy di girare solo se il branch del commit corrisponde al default branch. Se la valutazione della variabile restituisce true, la regola fa match. Ora, la seconda condizione verifica le modifiche ai file usando la keyword changes. Questa valuta se il push corrente ha modificato dei file che corrispondono a un path specifico o a una wildcard. È qui che risparmi soldi veri. Prendi ad esempio un job pesante di linter JavaScript. Non vuoi che questo linter consumi cicli di CPU se uno sviluppatore backend ha toccato solo i file di configurazione del database. Aggiungi una regola usando changes e specifichi la wildcard per i file punto js. Se il commit include modifiche a un file JavaScript, la regola fa match e il linter viene eseguito. Se non è stato toccato nessun file JavaScript, il job viene completamente escluso dalla pipeline. La terza condizione è exists. Invece di controllare variabili o modifiche recenti, exists verifica semplicemente se un file specifico è presente nel repository in quel momento. Potresti avere un template di pipeline generico usato da più progetti. Puoi definire un job di build di un container con una regola exists che punta a un Dockerfile. Se il progetto ha un Dockerfile nella sua root directory, il job gira. Se non ce l'ha, il job viene completamente saltato. Ecco il punto chiave. Trovare un match non significa automaticamente che il job venga eseguito. Quando una regola restituisce true, applica un'istruzione secondaria usando l'attributo when. Di default, una regola che fa match presuppone che il job debba essere aggiunto alla pipeline. Ma puoi definire esplicitamente una regola con when impostato su never. Questo è super efficace per il blocklisting. Puoi mettere una regola in cima alla tua lista che dice: se il messaggio di commit contiene la parola draft, imposta when su never. Dato che le regole vengono valutate dall'alto verso il basso, quel job viene terminato all'istante prima che vengano verificate altre condizioni. Se devi ricordare una sola cosa sul controllo dell'esecuzione, è che l'ordine determina il risultato. Metti le tue regole di esclusione in cima alla lista, perché nel momento in cui GitLab trova una condizione true, smette di leggere e blocca la decisione. Vorrei prendermi un momento per ringraziarti per l'ascolto: ci aiuta tantissimo. Buona giornata!

Ciao, sono Alex di DEV STORIES DOT EU. GitLab CI/CD, episodio 7 di 14. La tua pipeline non è effettivamente lenta. È semplicemente bloccata da un collo di bottiglia artificiale. Probabilmente hai job veloci in attesa di job lenti che non hanno assolutamente nulla a che fare con loro, semplicemente perché si trovano nella stessa colonna sullo schermo. Per risolvere questo problema, puoi eliminare le colonne rigide e costruire dei Directed Acyclic Graph con needs. Di default, le pipeline standard vengono eseguite in sequenza per stage. Definisci stage come build, test e deploy. Ogni job nello stage di test deve terminare completamente prima che possa iniziare qualsiasi job nello stage di deploy. Se il tuo stage di test ha cinque job, e quattro di questi terminano in due minuti mentre uno ne impiega dieci, l'intero stage di deploy resta bloccato fino al decimo minuto. La barriera di esecuzione tra gli stage è assoluta. La keyword needs abbatte questa barriera. Ti permette di definire relazioni esplicite tra i job, trasformando la tua pipeline da una sequenza rigida a un Directed Acyclic Graph. Quando usi la keyword needs nella definizione di un job, indichi al sistema esattamente quali job precedenti devono terminare prima che questo inizi. Nel momento in cui quelle specifiche dipendenze vengono soddisfatte, il tuo job si avvia. Smette di aspettare che il resto dello stage finisca. Considera un monorepo che contiene sia un frontend che un backend. I tuoi job di build e test del backend sono veloci e impiegano circa due minuti. Il tuo job di build del frontend è pesante e impiega dieci minuti. In una pipeline tradizionale, lo stage di deploy non può avviarsi finché non sono terminati i test sia del frontend che del backend. Il deploy del backend è di fatto tenuto in ostaggio dalla build del frontend. Ecco il punto chiave. Puoi aggiungere la keyword needs al tuo job di deploy del backend ed elencare come dipendenza solo il job di test del backend. A questo punto, la logica di esecuzione cambia. Il job di test del backend termina al minuto due. Il job di deploy del backend vede che la sua dipendenza esplicita è soddisfatta e si avvia immediatamente. Ignora completamente il fatto che la build del frontend sia ancora in esecuzione per altri otto minuti. Gli stage esistono ancora per un'organizzazione visiva nell'interfaccia utente, ma l'ordine di esecuzione effettivo è ora dettato dal grafo che hai costruito. Per configurarlo, aggiungi la keyword needs a un job e fornisci un array con i nomi esatti dei job. C'è un vantaggio secondario qui, che riguarda il trasferimento dei dati. Normalmente, un job scarica gli artifact da tutti i job completati con successo negli stage precedenti. Quando usi needs, il download degli artifact diventa mirato. Il tuo job scaricherà gli artifact solo dai job specifici elencati nell'array needs. Questo impedisce al tuo job di deploy del backend di scaricare asset frontend enormi e irrilevanti, facendoti risparmiare ancora più tempo durante l'inizializzazione del job. Se hai bisogno che un job inizi immediatamente alla creazione della pipeline, bypassando tutti i ritardi degli stage, puoi passare un array vuoto alla keyword needs. Questo indica al sistema che il job ha zero dipendenze, spingendolo in esecuzione al secondo zero. Il vero valore di un Directed Acyclic Graph è il disaccoppiamento di workflow indipendenti all'interno di un'unica pipeline. Smetti di organizzare i job in base a quando dovrebbero essere eseguiti, e inizi a organizzarli esclusivamente in base agli input che richiedono per l'esecuzione. Grazie per l'ascolto. Statemi bene, ciao a tutti.

Ciao, sono Alex di DEV STORIES DOT EU. GitLab CI/CD, episodio 8 di 14. Gestisci un progetto open source. Uno sconosciuto ne fa un fork, nasconde uno script che esporta variabili d'ambiente all'interno di uno unit test e apre una contribution. Se il tuo sistema esegue automaticamente quel codice sui tuoi server privati, i tuoi secrets sono persi. Per evitare questo, ti serve un confine ben definito tra il semplice push del codice e la sua esecuzione in un ambiente privilegiato. Questo confine è gestito dalle Merge Request Pipeline. Normalmente, GitLab avvia una pipeline ogni volta che fai il push di un commit su qualsiasi branch. Una merge request pipeline si comporta in modo diverso. È un tipo specifico di pipeline configurata per girare sui contenuti del source branch, ma solo nel contesto di una merge request aperta. Questo contesto ti dà accesso a specifiche variabili d'ambiente relative alla merge stessa, come il nome del target branch o l'identificativo della merge request. Puoi dire a un job di girare come merge request pipeline usando la sezione rules nel tuo file di configurazione. Scrivi una rule che valuta la variabile pipeline source. Controlli se la CI pipeline source è uguale al testo esatto merge request event, scritto con gli underscore tra le parole. Quando applichi questa rule, il job girerà solo quando una merge request viene creata o aggiornata. È molto comune abbinarla a delle rules che impediscono al job di girare sui normali push sui branch. Se non le separi, fare il push di un commit su una merge request aperta farà partire due pipeline nello stesso identico momento, che faranno lo stesso identico lavoro. Questo ci porta alle implicazioni di sicurezza delle contribution esterne. Quando qualcuno fa un fork del tuo repository, crea una copia completamente isolata. Se apre una merge request dal suo fork verso il tuo parent project, qualsiasi pipeline automatica gira all'interno del suo fork. Usa i suoi runner e le sue variabili. Questo è by design. I secrets del tuo parent project sono al sicuro perché il codice del contributor non ha accesso alla tua infrastruttura. Ma prima o poi, devi verificare che il suo codice passi la tua test suite ufficiale usando le tue credenziali del database e i tuoi deployment target. GitLab ti permette di far girare le pipeline per queste merge request dai fork all'interno del parent project, ma richiede un'azione umana intenzionale. Un developer o un maintainer del parent project deve avviare manualmente l'esecuzione. In un workflow corretto, il maintainer legge prima il codice inviato dal fork. Deve cercare qualsiasi cosa di malevolo, distruttivo o scritto male. Solo quando il maintainer è assolutamente certo che il codice sia sicuro, clicca sul pulsante per avviare la pipeline. Una volta avviata, quel codice esterno gira sui runner del parent project e ha accesso ai secrets del parent project. Il trigger manuale funge da vero e proprio security gate fisico. Questa è la parte che conta. Le merge request pipeline non sono solo un modo per raggruppare i job nella user interface, sono un meccanismo di controllo fondamentale che ti permette di valutare il codice esterno senza esporre ciecamente la tua infrastruttura interna. Se vuoi darci una mano a tenere le luci accese qui, puoi supportare lo show cercando DevStoriesEU su Patreon. Per questo episodio è tutto. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. GitLab CI/CD, episodio 9 di 14. Hai un singolo file YAML con cinquecento job. Modificare una sola riga è come disinnescare una bomba, e l'esecuzione richiede un'ora perché tutto gira in un unico blocco enorme. Le pipeline downstream risolvono questo problema suddividendo quel monolite in workflow modulari e indipendenti. Una pipeline downstream è semplicemente qualsiasi pipeline di GitLab CI/CD triggerata da un'altra pipeline. La pipeline che fa da trigger è chiamata pipeline upstream. Invece di eseguire ogni job in un'unica sequenza, la pipeline upstream fa da coordinatore, delegando il lavoro a pipeline più piccole e mirate. GitLab divide le pipeline downstream in due tipi specifici in base a dove vengono eseguite. Il primo tipo è la pipeline parent-child. Questa avviene interamente all'interno dello stesso progetto. Se hai un monorepo, un setup parent-child è esattamente quello che ti serve. La pipeline parent rileva cos'è cambiato e triggera solo la configurazione child pertinente. Il secondo tipo è la pipeline multi-project. Questo succede quando una pipeline in un repository triggera una pipeline in un progetto GitLab completamente diverso. La usi per architetture distribuite su più repository, come ad esempio triggerare un progetto di integration testing solo dopo che la pipeline di un progetto API standalone ha avuto successo. Configuri entrambi i tipi usando una keyword specifica del job chiamata trigger. Un job trigger è fondamentalmente diverso da un job standard. Non contiene mai una sezione script. Non esegue comandi su un runner. Il suo unico scopo è avviare la pipeline downstream. Per una pipeline multi-project, passi alla keyword trigger il path del progetto di destinazione. Per una pipeline parent-child, usi la keyword trigger combinata con la keyword include, puntando a un file YAML diverso che si trova nello stesso repository. Pensa a una pipeline parent di routing che gestisce tre microservizi separati salvati in un monorepo. La pipeline parent valuta il commit e triggera tre pipeline child in parallelo. Una gestisce lo user service, una gestisce il payment service e una gestisce l'inventory service. Ogni pipeline child ha i propri stage, job e rule. Vengono eseguite in modo indipendente. Di default, un job trigger è fire and forget. Il job upstream avvia la pipeline downstream e ha subito successo. Se hai bisogno che la pipeline upstream aspetti e rifletta lo stato della pipeline downstream, aggiungi il parametro strategy depend al job trigger. Questo forza la pipeline parent ad aspettare, il che significa che un fallimento nella pipeline child risalirà e segnerà il job parent come failed. Ecco il punto chiave. Spesso gli ingegneri configurano le pipeline parent-child e danno subito per scontato che siano rotte perché le pipeline child non compaiono nella pagina index principale delle pipeline. Questa è una scelta di design intenzionale. L'index principale mostra solo le pipeline parent per evitare confusione. Per vedere le pipeline child, devi cliccare nella detail view della pipeline parent. Sono annidate sotto lo specifico job che le ha triggerate. Le pipeline multi-project, d'altra parte, compaiono nell'index delle pipeline dei rispettivi progetti di destinazione, perché sono pipeline top-level in quei repository. Passare alle pipeline downstream ti obbliga a trattare la tua configurazione CI/CD come una vera e propria architettura software, sostituendo un singolo script fragile con componenti distinti che hanno failure domain isolati. Questo è tutto per oggi. Alla prossima!

Ciao, sono Alex di DEV STORIES DOT EU. GitLab CI/CD, episodio 10 di 14. Se il tuo team si affida a Slack per sapere chi ha appena fatto un push sul server di staging, hai un problema di visibilità nel tuo workflow. Hai bisogno di un modo definitivo e automatizzato per tracciare esattamente quale codice è in esecuzione e dove in qualsiasi momento, ed è proprio questo il problema risolto da GitLab Environments e Deployments. In GitLab, un environment è un'entità logica di tracciamento. GitLab non fa automaticamente il provisioning dei tuoi server o l'avvio della tua infrastruttura cloud solo perché hai creato un environment. L'environment è semplicemente una label. Dice a GitLab che uno specifico job nella tua pipeline è responsabile del push del codice in una destinazione specifica, come staging o production. Lo configuri aggiungendo la keyword environment direttamente all'interno del tuo job di deploy. Fornisci un nome statico per la destinazione. Per esempio, potresti creare un job chiamato deploy to staging, e all'interno di quel job, imposti il nome dell'environment a staging. La sezione script del tuo job gestisce comunque il lavoro vero e proprio. Esegue i comandi che copiano i file, applicano le configurazioni o riavviano i servizi remoti. Considera lo scenario in cui stai facendo il deploy di una nuova release candidate. Fai il merge del tuo codice e la pipeline parte. Fa la build dell'applicazione, esegue la tua test suite e arriva al job di deploy in staging. Dato che hai associato la keyword environment a questo job, GitLab cambia il modo in cui gestisce l'esecuzione. Monitora attentamente l'output del job. Quando il tuo script di deploy finisce e il job termina con successo, GitLab registra un evento formale di deploy per l'environment di staging. Ecco il punto chiave. Usare quella singola keyword attiva un'intera suite di funzionalità per il tracciamento dei deploy all'interno dell'interfaccia di GitLab. Se vai al menu Operate nella barra laterale e selezioni Environments, ti trovi davanti una dashboard che mostra lo stato in tempo reale dei tuoi target di deploy. Per il tuo environment di staging, non devi più indovinare cosa è in esecuzione. La dashboard mostra l'esatto commit hash attualmente attivo, il branch da cui proviene quel commit, l'autore del codice e da quanto tempo è finito il deploy. Crea un registro immutabile e condiviso dello stato del server. Tutti nel progetto hanno l'esatta stessa visibilità senza bisogno di controllare i log del server o chiedere ai colleghi. Cliccando sull'environment di staging puoi vedere l'intera history dei deploy. Questo storico è ciò che permette di fare rollback manuali direttamente dall'interfaccia utente. Se una nuova release candidate rompe completamente il server di staging, per sistemarlo non serve scrivere un revert commit o ricostruire manualmente una vecchia pipeline. Apri la lista della history, identifichi l'ultimo deploy andato a buon fine e clicchi sul pulsante di rollback lì di fianco. GitLab fa ripartire immediatamente il job di deploy da quel vecchio commit stabile. Sostituisce il codice rotto e ripristina velocemente il tuo environment di staging a uno stato funzionante. Usando la keyword environment, colmi il divario tra l'esecuzione degli script e il tracciamento dei deploy effettivi. Trasforma un job isolato della pipeline in un registro chiaro e visibile di quale versione del software si trova attualmente sulla tua infrastruttura. Vorrei prendermi un momento per ringraziarti per averci ascoltato: ci aiuta tantissimo. Buona giornata!

Ciao, sono Alex di DEV STORIES DOT EU. GitLab CI/CD, episodio 11 di 14. Passare al tuo product manager un URL live e cliccabile per ogni singolo feature branch elimina completamente la scusa che sulla tua macchina funziona. Questo workflow si basa interamente sugli ambienti dinamici e sulle Review Apps. Gli ambienti standard come lo staging o la produzione sono statici. Li definisci una volta e persistono. Gli ambienti dinamici vengono creati al volo. Li tiri su per testare uno specifico branch, li usi e poi li butti via. Quando usi un ambiente dinamico appositamente per fare la preview delle modifiche al codice all'interno di una merge request, GitLab lo chiama Review App. Per creare un ambiente dinamico, non puoi hardcodare il suo nome nel tuo file di configurazione. Invece, usi le variabili di pipeline. La variabile più critica per questo è il CI commit ref slug. Questa variabile prende il nome del tuo branch, lo converte in minuscolo, rimuove i caratteri speciali e lo accorcia. Ti garantisce di avere una stringa DNS-safe da usare per dare un nome sia al tuo ambiente in GitLab, sia alle tue risorse infrastrutturali vere e proprie. Definendo il nome del tuo ambiente con la parola review seguita da uno slash e da questa variabile slug, GitLab genera automaticamente un ambiente separato e tracciato per ogni singolo branch su cui fai push. Ecco il punto chiave. Creare il record dell'ambiente in GitLab è solo metà dell'opera. Devi anche indirizzare i reviewer al codice effettivamente deployato. Mettiamo caso che tu stia tirando su un'istanza AWS Lambda temporanea per il tuo feature branch. Quando gira il tuo script di deploy, AWS genera un URL casuale per quella nuova funzione Lambda. Non conosci questo URL in anticipo. Ti serve un modo per passare questo indirizzo generato dinamicamente alla user interface di GitLab, così i reviewer possono cliccarlo. Risolvi questo problema usando un tipo specifico di artifact chiamato dotenv report. All'interno del tuo job di deploy, dopo che AWS ha fatto il provisioning della funzione Lambda e ha restituito l'endpoint, il tuo script scrive quell'URL in un semplice file di testo formattato come coppia chiave-valore. Configuri il tuo job per mandare in output questo file come artifact dotenv report. GitLab legge questo file alla fine del job ed espone la variabile. A quel punto configuri il parametro environment URL nella definizione della tua pipeline per leggere esattamente quella variabile. Grazie a questa connessione, la tua merge request mostrerà ora un pulsante View App che indirizza gli utenti direttamente a quello specifico endpoint AWS Lambda. L'infrastruttura temporanea costa. Lasciare centinaia di funzioni Lambda stale in esecuzione prosciugherà rapidamente il tuo budget. Ti serve un modo automatizzato per fare clean up. Gestisci questa cosa usando la keyword on stop. Nel tuo job di deploy, aggiungi la property on stop e le assegni il nome esatto di un altro job nella tua pipeline. Questo secondo job contiene il tuo script di teardown dell'infrastruttura. Collegandoli in questo modo, GitLab prende in carico il lifecycle management. Quando uno sviluppatore fa il merge del feature branch, o elimina il branch, GitLab esegue automaticamente quel job di teardown. L'infrastruttura viene distrutta immediatamente. Il vero valore delle Review Apps non è solo fare la preview del codice, ma automatizzare l'intero lifecycle dell'infrastruttura. Fai provisioning in modo dinamico, colleghi senza problemi e distruggi in modo affidabile gli ambienti temporanei senza che un singolo sviluppatore debba mai toccare una console di hosting. Questo è tutto per questo episodio. Grazie per aver ascoltato, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. GitLab CI/CD, episodio 12 di 14. Copiare e incollare lo stesso identico script di deployment in cinquanta repository diversi garantisce una cosa: quando inevitabilmente quello script dovrà cambiare, ti dimenticherai di aggiornare almeno un repository. La soluzione è scrivere configurazioni DRY usando la parola chiave include. In GitLab CI, la parola chiave include ti permette di suddividere la configurazione della pipeline in più file più piccoli e riutilizzabili. Invece di gestire un unico file YAML enorme, crei un sistema modulare. Quando una pipeline viene triggerata, GitLab si mette in pausa, recupera tutti i file inclusi, fa il merge e quindi valuta la configurazione combinata nel suo complesso. Esistono tre subkey principali che usi per importare questi file esterni. La più semplice è local. Usi include local per includere un file che si trova nell'esatto stesso repository del file della pipeline principale. Questo serve strettamente per organizzare un singolo progetto di grandi dimensioni. Puoi separare tutta la tua logica di testing in un file chiamato test pipeline dot yml, inserire la logica di deployment in deploy pipeline dot yml e mantenere pulito il file di configurazione root semplicemente facendo riferimento a quei percorsi locali. La seconda subkey è project, ed è qui che la modularità della pipeline scala a livello di organizzazione. Include project recupera un file YAML da un repository completamente diverso ospitato sulla stessa istanza di GitLab. Specifichi il percorso del progetto esterno, insieme al percorso del file e, facoltativamente, il branch o il riferimento al commit specifico che vuoi recuperare. Considera un platform team che gestisce una pipeline di security scanning centralizzata. Invece di cinquanta team di microservizi diversi che scrivono e gestiscono i propri job di sicurezza, il platform team mantiene un singolo template YAML autorevole in un progetto platform dedicato. I cinquanta progetti di microservizi aggiungono semplicemente un blocco include project che punta a quel repository centrale. Quando il platform team aggiorna la versione dello scanner o modifica le regole di sicurezza nel proprio template, tutti e cinquanta i microservizi eseguono automaticamente i controlli aggiornati alla successiva esecuzione della pipeline. Non è richiesto alcun copia e incolla ripetitivo. La terza subkey è remote. Include remote accetta un URL HTTPS completo e recupera un file di configurazione da qualsiasi web server pubblico. Potresti usarla per importare definizioni di pipeline fornite dai vendor o standard della community open source. L'unico requisito stringente è che l'URL deve essere accessibile pubblicamente tramite una normale web request senza autenticazione. Ora, presta attenzione a questa parte. Spesso ti imbatterai in una situazione in cui un file incluso definisce un job, ma il progetto locale deve modificarlo leggermente. GitLab gestisce questa situazione tramite il suo comportamento di merge. Quando vengono inclusi dei file, GitLab esegue un deep merge delle configurazioni. Se un file incluso definisce un job chiamato run security scan e anche il tuo file principale definisce un job chiamato run security scan, la configurazione nel tuo file principale ha la precedenza. Questo significa che non devi scartare un template centralizzato solo perché il tuo progetto specifico necessita di una piccola modifica. Puoi includere il template del platform team e poi definire localmente solo il job run security scan con una variabile aggiornata o l'aggiunta di uno script custom. I tuoi override locali vengono applicati, mentre il resto della definizione del job rimane esattamente come l'ha scritto il platform team. Il vero potere della modularità delle pipeline non è solo centralizzare il codice, ma progettare template come sensible default che i progetti a valle possono overridare localmente senza spezzare la inheritance chain. Questo è tutto per questo episodio. Grazie per aver ascoltato e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. GitLab CI/CD, episodio 13 di 14. La tua pipeline è appena fallita perché qualcuno ha aggiornato uno snippet YAML condiviso tre repository più in là. Non hai avuto alcun preavviso, e ora stai perdendo un'ora a sistemare un job che non hai nemmeno scritto. I giorni in cui ti affidavi a snippet YAML fragili e non versionati sono finiti. I Component CI/CD e il CI/CD Catalog risolvono questo problema portando l'affidabilità dei package manager direttamente nelle tue pipeline. I Component sono configurazioni di pipeline riutilizzabili e single-purpose. Rappresentano l'evoluzione moderna del vecchio metodo include template. Con i template legacy, in pratica importavi YAML grezzo via rete. Se il file upstream cambiava, la tua pipeline cambiava all'istante, spesso con risultati disastrosi. I Component risolvono questo problema imponendo un versionamento rigoroso. Il CI/CD Catalog funge da registry centralizzato dove la tua organizzazione può pubblicare, scoprire e condividere questi Component versionati. Per creare un Component, ti serve un repository con una struttura di file ben precisa. La logica principale deve trovarsi all'interno di una directory chiamata esplicitamente templates. Puoi inserire più file YAML all'interno di questa directory, dove ogni file rappresenta un Component distinto. Nella root del repository, devi anche fornire un file readme dot md. Questo file markdown non è solo un gentile suggerimento. Funge da documentazione ufficiale mostrata nel Catalog, e descrive in dettaglio cosa fa il Component e quali parametri richiede. Ecco il punto chiave. I Component sono troppo rigidi per essere utili senza input. Gli input funzionano esattamente come gli argomenti di una funzione per la configurazione della tua pipeline. Quando scrivi lo YAML del Component, dichiari un blocco in cima che definisce gli input accettati. Specifichi i loro nomi, i loro valori di default e se sono required. Considera un team di platform engineering che sta implementando delle security scan obbligatorie. Creano un progetto Component chiamato corporate-security. All'interno della directory templates, scrivono un file specifico per la secret detection. Per mantenerlo flessibile, definiscono un singolo input required chiamato stage. Gli sviluppatori di applicazioni in tutta l'azienda non devono più scrivere o mantenere i job di secret detection da soli. Per utilizzare esattamente quel Component di secret detection, uno sviluppatore usa la sintassi include component nella configurazione della sua pipeline. Specifica il path del Component sul server. Poi, aggiunge un simbolo chiocciola seguito da una semantic version, come uno punto zero punto zero. Questo è il passaggio cruciale. Pinnare la semantic version garantisce che la pipeline non si rompa mai inaspettatamente, anche se il platform team rilascia una versione pesantemente modificata due punto zero punto zero più tardi quella settimana. Se uno sviluppatore vuole intenzionalmente la bleeding edge, può aggiungere lo special tag tilde latest invece di un numero di versione, ma il semantic versioning è il default più sicuro. Subito sotto la dichiarazione include, lo sviluppatore passa le sue variabili, mappando l'input stage a qualsiasi stage della pipeline si adatti al suo progetto specifico, come test o pre-build. Trattare la logica della pipeline come software versionato cambia il modo in cui i team scalano l'infrastructure. Il vero potere dei Component non è solo il riutilizzo del codice, è la garanzia assoluta che una pipeline che gira con successo oggi girerà esattamente allo stesso modo tra sei mesi. Grazie per l'ascolto. Statemi bene, ciao a tutti.

Ciao, sono Alex di DEV STORIES DOT EU. GitLab CI/CD, episodio 14 di 14. Provi a definire il nome dello stage di un job usando una variabile CI standard, fai il push del tuo codice e ricevi subito un errore di sintassi. La pipeline si rifiuta di partire. Il problema è il timing. Il runner non può definire la struttura della pipeline usando variabili che riceve solo dopo che la pipeline è già iniziata. È proprio qui che entrano in gioco le Compile-Time CI Expressions. Ecco il punto chiave. Le variabili di runtime standard, scritte con un singolo simbolo del dollaro, vengono valutate dalla shell quando il job viene effettivamente eseguito. Nel momento in cui il runner le vede, l'intera architettura della pipeline è già bloccata. Non puoi cambiare dinamicamente il nome di uno stage, un service o la versione di un'image durante l'esecuzione, perché GitLab ha bisogno di quelle informazioni in anticipo per costruire il graph della pipeline. Le compile-time expression risolvono questo problema valutando la logica nel momento esatto in cui GitLab fa il parsing della tua configurazione YAML, molto prima che venga assegnato un runner. La sintassi usa un simbolo del dollaro seguito da doppie parentesi quadre. All'interno di queste parentesi, scrivi un'espressione che viene valutata in un valore prima che la pipeline venga creata. Queste espressioni prendono i loro dati da context specifici. Un context è essenzialmente un set limitato di dati disponibili durante il parsing dello YAML. Il context più importante è il context inputs, che è ampiamente usato quando si creano component CI/CD. Prendi lo scenario di un component di deploy dinamico. Vuoi che il progetto che consuma questo component passi un nome di environment come input. Vuoi quindi usare quell'input per impostare il nome dello stage del job e dettare la versione specifica dell'image Docker di cui fare il pull. All'interno della configurazione del tuo component, scrivi il campo stage e lo assegni a una compile-time expression che contiene inputs punto environment. Quando un progetto include il tuo component, GitLab legge l'input environment fornito. Valuta immediatamente l'espressione. Il graph della pipeline risultante vede un nome di stage statico e hardcoded, e un tag dell'image hardcoded. Il runner non incontra mai le doppie parentesi quadre. Riceve semplicemente la configurazione standard. Oltre agli inputs, le compile-time expression supportano anche un context matrix, che è attualmente in beta. Quando generi job paralleli usando una keyword come parallel matrix, puoi usare le compile-time expression per regolare dinamicamente le proprietà del job in base alle variabili specifiche assegnate a ciascuna istanza parallela. Questo ti evita di dover duplicare le definizioni del job solo per cambiare uno o due campi per ogni esecuzione della matrix. Queste espressioni sono più potenti della semplice sostituzione di testo. Puoi scrivere la logica direttamente all'interno delle parentesi usando operatori di uguaglianza, così come operatori logici AND e OR. Puoi valutare se un input corrisponde a una string specifica, e cambiare condizionalmente un valore in base al risultato. Hai anche accesso a funzioni built-in. La funzione expand vars, per esempio, ti permette di iniettare in modo sicuro valori compile-time in una string, preservando esplicitamente la sintassi standard delle variabili di runtime. Questo garantisce che il runner riceva comunque le variabili di runtime che si aspetta, senza causare conflitti di parsing nelle fasi iniziali. Il punto fondamentale è che le compile-time expression ti offrono un meccanismo nativo per creare un template del graph della tua pipeline, separando nettamente la logica di generazione strutturale dall'effettiva esecuzione dello script. Prenditi un po' di tempo per leggere la documentazione ufficiale di GitLab, dai un'occhiata alle funzioni supportate e prova a fare il deploy di un component in modo pratico. Se hai argomenti che vorresti vedere trattati in una serie futura, visita devstories dot eu e faccelo sapere. Grazie per aver passato qualche minuto con me. Alla prossima, stammi bene.