Ciao, e benvenuto nella sesta puntata della quindicesima stagione. Nelle scorse puntate abbiamo capito l'integrazione continua e i test, la parte che risponde alla domanda il codice è buono. Ora cominciamo a seguire il codice buono nel suo viaggio verso gli utenti, e la prima tappa di questo viaggio è trasformarlo in qualcosa di pronto da spedire. Oggi parliamo della fase di costruzione, e di un concetto centrale che ne è il frutto: l'artefatto. È il momento in cui il tuo codice sorgente diventa un pacchetto concreto, pronto per essere consegnato.
Partiamo da una distinzione importante: il codice che scrivi non è, di solito, ciò che gira davvero in produzione. Il codice sorgente, quello che tu leggi e modifichi, è pensato per gli esseri umani: è testo, organizzato per essere comprensibile. Ma per essere eseguito e distribuito, questo codice spesso deve essere trasformato: compilato, tradotto in una forma eseguibile, messo insieme ai suoi pezzi, impacchettato in modo ordinato. Questa trasformazione, dal codice sorgente leggibile al pacchetto pronto da eseguire, è ciò che chiamiamo costruzione. È il passaggio dall'idea scritta all'oggetto concreto e funzionante.
Il risultato di questa costruzione ha un nome che vale la pena imparare: l'artefatto. Un artefatto è il prodotto finito della fase di costruzione, il pacchetto concreto, pronto da eseguire e da distribuire, che nasce dal tuo codice sorgente. Se il codice sorgente è la ricetta e gli ingredienti, l'artefatto è il piatto cucinato, pronto da servire. È l'oggetto tangibile che verrà effettivamente spedito e messo in funzione, ciò che gli utenti, indirettamente, useranno. Tutto il lavoro della pipeline, in fondo, ruota attorno alla produzione e alla consegna di questo artefatto: costruirlo, verificarlo, e portarlo agli utenti.
E qui riprendo, con piacere, un concetto che conosciamo bene dalla stagione su Docker, perché si incastra alla perfezione. Ricordi le immagini, quei pacchetti sigillati e immutabili che contengono il programma con tutto il suo ambiente? Ebbene, in moltissime pipeline moderne, l'artefatto è proprio un'immagine di container. La fase di costruzione prende il tuo codice sorgente e produce un'immagine, quel pacchetto autosufficiente di cui parlavamo, pronto per essere avviato ovunque allo stesso modo. Così i due mondi si uniscono: la costruzione della pipeline sfocia nella creazione dell'immagine di Docker, che diventa l'artefatto da distribuire. Le stagioni si intrecciano in un unico flusso.
Ora arriviamo a un principio profondo e prezioso, che riprende sia Docker sia la logica della pipeline: si costruisce una volta sola, e poi si distribuisce sempre lo stesso artefatto. Ti spiego perché è così importante. Una volta che la fase di costruzione ha prodotto l'artefatto, quell'artefatto è fisso, immutabile, congelato. Non viene ricostruito ogni volta per ogni ambiente: è sempre lo stesso identico pacchetto che viene poi promosso attraverso le varie fasi, dall'ambiente di prova fino alla produzione. Lo stesso artefatto che hai verificato è esattamente lo stesso che finisce dagli utenti, senza modifiche in mezzo. Costruisci una volta, e quel preciso pacchetto viaggia intatto fino in fondo.
Voglio farti apprezzare perché questo sia così cruciale, perché è una garanzia fondamentale. Se ricostruissi il pacchetto separatamente per ogni ambiente, correresti il rischio che le versioni siano leggermente diverse: quella che hai testato potrebbe non essere identica a quella che va in produzione, e potrebbero introdursi differenze sottili e insidiose. Ricordi il problema del sul mio computer funziona di cui parlavamo con Docker? Ricostruire ogni volta lo riporterebbe in vita. Invece, costruendo una volta sola e promuovendo sempre lo stesso identico artefatto, hai la certezza assoluta che ciò che finisce dagli utenti è esattamente ciò che hai verificato, bit per bit. Nessuna sorpresa, nessuna divergenza nascosta. L'artefatto immutabile è una promessa di coerenza.
C'è anche un vantaggio pratico bellissimo di avere artefatti immutabili e ben identificati, che voglio menzionare: puoi sempre sapere esattamente cosa sta girando e tornare indietro se serve. Siccome ogni artefatto è un pacchetto preciso, congelato e identificabile, sai sempre con esattezza quale versione è in produzione. E se una nuova versione dà problemi, puoi tornare a un artefatto precedente, che è ancora lì, intatto e pronto, esattamente com'era. È come avere in magazzino tutte le versioni passate del prodotto, sigillate e pronte all'uso, così da poter ripristinare in un attimo l'ultima che funzionava bene. Questa tracciabilità e reversibilità sono un dono prezioso, che nasce proprio dall'immutabilità degli artefatti.
Per oggi ci fermiamo qui. Il codice sorgente che scrivi non è ciò che gira in produzione: deve prima essere trasformato attraverso la fase di costruzione, che lo compila, lo mette insieme e lo impacchetta. Il prodotto di questa costruzione è l'artefatto, il pacchetto concreto e pronto da spedire, che in molte pipeline moderne è proprio un'immagine di container. Vale il principio fondamentale del costruire una volta e distribuire sempre lo stesso artefatto immutabile, che garantisce che ciò che va dagli utenti sia esattamente ciò che hai verificato, e permette di tornare indietro con facilità. Nella prossima puntata seguiamo l'artefatto nella tappa finale: il rilascio agli utenti. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.