Cos'è la CI/CD? Integrazione e distribuzione continue spiegate

La CI/CD è un modo di rilasciare software in cui ogni modifica al codice viene compilata, testata automaticamente e — se supera i controlli — preparata per il rilascio o rilasciata. CI (integrazione continua) significa che le modifiche vengono unite spesso e verificate da test automatici ogni volta. CD (delivery o deployment continuo) significa che le modifiche approvate vengono confezionate e spinte verso gli utenti con poco o nessun lavoro manuale.

Il punto è semplice: intercettare gli errori pochi minuti dopo che sono stati fatti, non settimane dopo, quando a trovarli è un cliente.

Perché la CI/CD conta quando costruisci con l'AI

Gli AI builder modificano il codice rapidamente. Un solo prompt può toccare dieci file. Questa velocità è ottima finché una modifica alla pagina di checkout non rompe silenziosamente la pagina di login, e nessuno se ne accorge finché un utente non ti scrive.

La CI/CD è la rete di sicurezza proprio per questo. Invece di fidarsi che ogni modifica sia a posto, una pipeline esegue ogni volta gli stessi controlli:

• L'app si compila ancora senza errori?
• I test automatici passano ancora?
• Il codice rispetta le regole del progetto (tipi, formattazione, controlli di sicurezza)?

Se un controllo fallisce, la modifica viene fermata prima di raggiungere gli utenti. Più velocemente cambia il tuo codice, più vale un controllo che non si stanca mai e non salta alcun passaggio.

Un'analogia quotidiana

Pensa a un forno che ogni mattina vende pane ai negozi.

• Senza CI/CD, ogni fornaio lavora per una settimana sulle proprie modifiche alla ricetta, poi il venerdì sera le unisce tutte e spera che il pane lieviti ancora. Quando non lievita, nessuno sa quale modifica ne sia la causa.
• Con la CI, ogni piccola modifica alla ricetta viene subito cotta in una pagnotta di prova e controllata — gusto, peso, forma. Una modifica sbagliata viene scoperta lo stesso giorno, e sai esattamente qual è.
• Con la CD, le pagnotte che superano il controllo finiscono direttamente sul furgone delle consegne, confezionate ed etichettate sempre allo stesso modo, invece di qualcuno che impacchetta le scatole a mano alle cinque del mattino.

Il controllo non rende i fornai più bravi. Rende economici i loro errori.

Come funziona una pipeline CI/CD

Una pipeline è una sequenza di passaggi che un servizio CI/CD esegue automaticamente quando succede qualcosa — di solito quando qualcuno invia codice a un repository come GitHub. Una pipeline tipica è così:

Ogni passaggio viene eseguito su una macchina pulita, non sul portatile di qualcuno, quindi «funziona sul mio computer» non è più una scusa. Se un passaggio fallisce, la pipeline si ferma e avvisa chi ha fatto la modifica.

I passaggi sono definiti in un file di configurazione che vive insieme al codice. Su GitHub Actions, per esempio, è un file YAML nella cartella .github/workflows del repository.

Delivery continua vs deployment continuo

La parte «CD» è ambigua, e la gente la usa in entrambi i modi:

Il deployment continuo funziona bene solo se i test sono buoni. Se i test non coprono il checkout, il deployment continuo pubblicherà felicemente un checkout rotto.

Un esempio pratico: un'app di prenotazioni con una pipeline

Immagina di avere un'app di prenotazioni per un salone, con il codice in un repository GitHub. Chiedi a un AI builder di «aggiungere uno sconto del 10% per i clienti alla prima prenotazione».

1. La modifica viene inviata a un nuovo branch e si apre una pull request.
2. La pipeline parte. Installa i pacchetti e compila l'app — questo passaggio riesce.
3. Esegue i test. Un test, «un cliente abituale paga il prezzo pieno», fallisce: lo sconto viene applicato a tutti.
4. La pull request mostra una croce rossa. La modifica non può essere unita.
5. Chiedi all'AI di correggerla. Invia una correzione; la pipeline riparte e tutto passa.
6. La modifica viene unita. La pipeline la distribuisce in un ambiente di staging, dove provi una prenotazione di test.
7. Approvi, e va in produzione.

Senza la pipeline, il passaggio 3 sarebbe successo sul portafoglio dei tuoi clienti.

Termini chiave

Idee sbagliate comuni

• «CI/CD significa che la mia app è testata.» Una pipeline esegue solo i test che hai. Se non ci sono test, la CI dimostra solo che l'app si compila — nient'altro. Chiedi all'AI di scrivere test per i flussi più importanti.
• «La CI/CD è solo per le grandi aziende.» Strumenti ospitati come GitHub Actions richiedono un breve file di configurazione, e i piccoli team li usano continuamente. Lo sforzo sta nei test, non negli strumenti.
• «Il deploy automatico significa che nessuno controlla nulla.» Le buone pipeline aggiungono controlli, non li tolgono. Molti team mantengono un passaggio di approvazione umana prima della produzione.
• «Se la pipeline è verde, l'app funziona.» Significa che i controlli automatici sono passati. Dovresti comunque provare tu stesso la modifica, idealmente in un'anteprima o in staging.
• «La CI/CD sostituisce i backup.» No. Una cattiva migrazione del database che supera i test può comunque danneggiare dati reali. Conserva i backup e un modo per tornare indietro.

Cosa chiedere al tuo AI builder

• «Scrivi test automatici per registrazione, login e checkout, e mostrami come eseguirli.»
• «Configura un workflow di GitHub Actions che installi le dipendenze, compili l'app ed esegua i test a ogni pull request.»
• «Aggiungi un controllo dei tipi e un linter alla pipeline, e fallo fallire in caso di errori.»
• «Spiegami in parole semplici cosa fa ogni passaggio della pipeline.»
• «Cosa succede se un deploy fallisce a metà? Come torno indietro?»
• «Verifica che nessun segreto sia scritto nel codice del repository o stampato nei log della pipeline.»

Se la tua app usa chiavi API, anche la pipeline ne ha bisogno — memorizzate come segreti cifrati nello strumento CI, mai nel file di configurazione. Vedi variabili d'ambiente e segreti.

CI/CD e Mythex

Mythex non esegue una pipeline CI per te, ma copre alcune delle stesse esigenze a modo suo:

• Checkpoint. Dopo ogni turno riuscito dell'agente, Mythex salva un checkpoint git, e Torna a questo punto riporta indietro il progetto se una modifica è andata storta. Vedi Chat.
• Test dell'app. Digita /test e l'agente naviga la tua anteprima dal vivo come un utente e segnala i flussi rotti — utile prima di ogni pubblicazione. Vedi Test dell'app.
• La pubblicazione è un passaggio deliberato. Le modifiche compaiono prima nell'anteprima privata; la tua app pubblica si aggiorna solo quando pubblichi di nuovo — più vicino alla delivery continua che al deployment continuo.
• Sincronizzazione con GitHub (Pro). Sincronizza il progetto con un repository GitHub e puoi aggiungere i tuoi workflow di GitHub Actions per eseguire i test a ogni push. Vedi GitHub ed esportazione.

Per una checklist di ciò che va testato a mano prima di andare online, vedi come testare la tua app prima del lancio, e per lavorare con il controllo di versione, come usare Git con un'app costruita con l'AI.

Domande