Rompì il build: cos’è, cause e come evitarlo nel progetto

Cos’è rompere il build nello sviluppo

Rompì il build è una situazione in cui, dopo aver introdotto modifiche, il progetto smette di essere costruito. Nel contesto del CI/CD, ciò significa che la pipeline di build fallisce e nessun artefatto viene creato.

Nel mondo dello sviluppo mobile e web, il build è il processo di traduzione del codice sorgente in un file eseguibile o pacchetto. Per Android, è la creazione di un APK o AAB tramite Gradle; per iOS, la compilazione tramite Xcode; per i progetti web, il raggruppamento tramite Webpack o Vite. Si può rompere il build in qualsiasi di queste fasi.

I moderni sistemi di controllo versione e gli strumenti CI/CD come Jenkins, GitHub Actions e GitLab CI rilevano automaticamente un build rotto e avvisano il team. Nella maggior parte dei progetti esiste una regola: se il build è rotto, la priorità di tutte le altre attività viene ridotta fino a quando il build non viene riparato.

fun main() {
    val message: String = "Build successful"
    println(message)
    
    // Questa riga rompe il build
    val number: Int = "not a number"
}

In questo esempio, assegnare una stringa a una variabile di tipo Int provoca un errore di compilazione. La mancata corrispondenza dei tipi è una delle cause più comuni di build rotto nei linguaggi tipizzati staticamente.

Cause principali del fallimento del build

Esistono diverse categorie di errori che portano a un build rotto. Secondo l’analisi di GitLab per il 2024, la distribuzione delle cause è la seguente.

La categoria più insidiosa sono i problemi di dipendenze. L’aggiornamento di una libreria in un modulo può rompere il build in un modulo vicino se l’API o il comportamento dei metodi cambia.

Gli errori di sintassi, invece, vengono rilevati rapidamente — il compilatore indica la riga esatta e il tipo di errore. Ecco perché i linguaggi tipizzati staticamente sono considerati più affidabili in termini di stabilità del build rispetto a quelli tipizzati dinamicamente.

Come un build rotto influisce sul team

Un build rotto influisce direttamente sulla produttività del team. Quando il build fallisce, gli sviluppatori non possono ottenere la versione più recente del progetto dal repository e la pipeline CI viene bloccata per tutte le modifiche successive.

Uno studio di Atlassian del 2023 ha mostrato che i progetti in cui il build rimane rotto per più di quattro ore perdono in media il 25% del tempo produttivo del team. Gli sviluppatori sono costretti a dirottare la loro attenzione per diagnosticare il problema invece di completare i propri compiti.

Oltre alla produttività, anche il clima morale ne risente. Lo sviluppatore che ha rotto il build subisce pressioni dai colleghi. Nei team sani, la regola è: non punire per un build rotto, ma richiedere una correzione immediata. La cultura senza colpa è un approccio in cui l’incidente viene analizzato come un problema sistemico, non come un errore di qualcuno.

Nei team distribuiti, un build rotto può bloccare il lavoro dei colleghi in un altro fuso orario. Se uno sviluppatore europeo rompe il build prima di andare via, il team asiatico può perdere un’intera giornata lavorativa in attesa della correzione.

Come prevenire un build rotto

La prevenzione del build rotto inizia con controlli locali prima del commit. Ogni sviluppatore dovrebbe eseguire test e il build prima di inviare le modifiche. I principali metodi di prevenzione sono suddivisi in diversi livelli.

• Hook pre-commit — controlli automatici prima di creare un commit, inclusi linter e formattatori
• Build locale — esecuzione della compilazione prima del push, specialmente per i linguaggi tipizzati staticamente
• Test unitari — copertura dei moduli chiave con test per la rilevazione precoce delle regressioni
• Revisione del codice — revisione delle modifiche da parte di un collega prima del merge nel ramo principale

Il secondo livello è la configurazione della pipeline CI/CD. Ogni Pull Request deve superare il build e i test automatici prima del merge. Se il build fallisce, la PR viene bloccata fino alla correzione. Questo approccio si chiama gated commit ed è utilizzato nella maggior parte dei progetti moderni.

Il terzo livello è il monitoraggio e le statistiche. I team tracciano la metrica MTTR (Mean Time To Repair). Più basso è questo indicatore, più velocemente il team risponde a un build rotto. Il valore obiettivo non supera i 30 minuti.

Cosa fare se il build è rotto

Quando il build è rotto, il primo passo è identificare quale sviluppatore ha apportato le ultime modifiche. Git fornisce lo strumento git bisect, che consente di trovare il commit che ha rotto il build tramite ricerca binaria.

# Avvia bisect con commit buono e cattivo noti
git bisect start
git bisect bad HEAD
git bisect good abc1234

# Git controlla un commit nel mezzo
# Compila e testa, poi segna:
git bisect good  # if build passes
git bisect bad   # if build fails

# Dopo ~log2(n) passaggi, git mostra il colpevole
git bisect reset

Dopo aver trovato il commit problematico, ci sono due possibili corsi d’azione. Il primo è annullare le modifiche usando git revert se la correzione richiede tempo. Questo è l’approccio più sicuro, specialmente quando il build blocca l’intero team.

La seconda opzione è una correzione immediata con un nuovo commit. Questo approccio è preferibile se il problema è locale e chiaro. Dopo la correzione, invia le modifiche e conferma che il build abbia successo. In ogni caso, il tempo di recupero del build non deve superare un’ora.