Dato che non possiamo costruire su ogni commit, finiamo per costruire da più commit. In genere si tratta di circa 30 commit a una build.
Alla fine, rompiamo la build. Come si fa a identificare e correggere le modifiche al codice che introducono regressioni? Esistono pratiche per rintracciare il commit errato?
Generalmente, il meglio che puoi fare è una semplice ricerca binaria . Si inizia costruendo il commit a metà strada tra l'ultima build valida e la build attuale rotta, quindi ripetere fino a trovare il commit non riuscito. Con 30 commit, dovrai eseguire ceil (log_2 (30)) = 5 build per trovare il commit fallito. git bisect può aiutarti con gli strumenti qui, ma non risolverà il problema per te. L'implementazione ingenua qui presuppone che vi sia una sola transizione di stato nell'insieme di commit oggetto di indagine; le cose si complicano ancora di più se il set di modifiche diventa buono-cattivo-buono-cattivo o se ci sono molti cambiamenti irrisori, ma una prima implementazione può ignorare quei casi e lanciarli a un umano - si spera che tu sia non rompere la build quella spesso. Se è possibile eseguire build parallele, è possibile eseguire la suddivisione a N anziché solo in binario.
potresti essere in grado di trovare delle euristiche per aiutarti; se il compilatore riporta un errore sulla riga X del file Y e git blame indica che la riga è stata modificata nell'insieme di commit in esame, allora potrebbe valere la pena provare solo quella build e quella immediatamente precedente (che puoi fare in parallelo). Dovresti ottenere le tue statistiche sul fatto che l'ottimizzazione valga la pena per il modo in cui rompi la build.
Leggi altre domande sui tag git continuous-integration