Ho appena visto un video sulla consegna continua e lì è stato suggerito di attivare un test unitario di build ed esecuzione su ogni commit. Per il nostro team di 10 sviluppatori e un tempo di costruzione di almeno 10 minuti mi chiedo come funzionerà come in 1 ora, tutti gli sviluppatori potrebbero fornire qualcosa == > potremmo finire per avere più build in corso contemporaneamente.
Sarebbe ok? È una buona pratica?
Attualmente la build viene attivata manualmente su richiesta.
La maggior parte, se non tutte le piattaforme CI limitano a una singola build per progetto / ramo.
Se i tuoi sviluppatori lavorano su rami separati, allora potresti effettivamente avere build concomitanti isolati. Ciò potrebbe causare un backup sul server CI, ma può essere risolto aggiungendo più macchine slave per eseguire le build.
Se stanno lavorando sullo stesso ramo, le build succederanno una dopo l'altra, una per commit. Se si commette troppo frequentemente per mantenere il server CI, questo potrebbe essere un problema, sebbene sia possibile sostituire l'attivazione basata sul commit con l'attivazione basata sul tempo.
BUT, se stai seguendo buone pratiche di sviluppo e gli sviluppatori uniscono le modifiche ed eseguono i test unitari prima del commit, allora il tempo impiegato dagli sviluppatori dovrebbe (a lungo termine) corrispondere a quello delle macchine di compilazione degli elementi della configurazione.
Se i tuoi sviluppatori stanno apportando modifiche in parti molto diverse della base di codice, allora un passo successivo è quello di rompere il progetto in più sotto-progetti (librerie) e modificarli / test / costruirli in modo indipendente.
Bene, il suggerimento di eseguire le verifiche di CI per ogni commit è semplicemente un tentativo di rendere l'integrazione più deterministica: la prima verifica fallita farebbe immediatamente riferimento al changeset difettoso, quindi rimarrebbe solo la riparazione da fare per il ramo per riprendersi dalle regressioni di qualità.
Se vengono commessi diversi changeset tra 2 verifiche consecutive, un errore indicherà solo il gruppo di changeset contenente il colpevole. Sarebbe necessario un ulteriore sforzo per identificare esattamente il colpevole prima che venga effettuato il ripristino. Che in genere non richiede una quantità di tempo fissa / deterministica. Quindi nel complesso i blocchi causati dalle regressioni sarebbero più lunghi.
Anche le verifiche dopo ogni commit non sono una pallottola d'argento - sono efficaci solo finchè più regimi di regressione che causano non sono commessi troppo vicini l'uno all'altro: se uno o più successivi changeset sono impegnati prima la verifica per il primo termina (con un risultato fallito) e quel 1 ° changeset viene annullato, quindi il backup del 1 ° changeset non porterà il ramo in condizioni di assenza di regressione - le altre regressioni saranno ancora presenti, ma potenzialmente senza una chiara indicazione del colpevole, che di nuovo si tradurrebbe in blocchi più lunghi.
Quanto sopra sono solo alcuni dei motivi per cui i sistemi CI basati su verifiche post-commit sono soggetti a congestione nei progetti ad alta velocità. Per ulteriori dettagli, consulta la mia post Congestione nei sistemi di CI tradizionali . Disclaimer: sono affiliato alla società menzionata in questo post.
potresti voler eventualmente considerare un sistema di CI basato su pre-commit , vedi C'è uno strumento CI che non garantisce regressioni nel livello di qualità del ramo?
Leggi altre domande sui tag version-control continuous-integration jenkins