Quali sono i vantaggi che le build quotidiane offrono in concreto per le build continue?

Question

Quali sono i vantaggi che le build quotidiane offrono in concreto per le build continue?

#1 da (5 voti)
#2 da (1 voti)
#3 da (0 voti)

2

Ho visto questa domanda e non credo che questo sia un duplicato Quali modelli software sono appropriati per build giornaliere e integrazione continua? .

Non capisco appieno quale vantaggio possano avere le build automatiche quotidiane complete nel costruire su ogni commit in pratica (integrazione continua essendo il termine in cui credo). Sento spesso che le aziende menzionano che si basano su ogni commit quando viene chiesto informazioni sulle build giornaliere.

Il secondo articolo di Joel in basso menziona "È allettante fare continue build, ma probabilmente non puoi, a causa di problemi di controllo del codice sorgente di cui parlerò tra un minuto." ma non è ancora chiaro per me, nonostante la ricerca.

link

In questi 2 articoli si accenna al fatto che una build giornaliera è più pratica / vantaggiosa rispetto all'integrazione continua (che a mio avviso si baserebbe su ogni commit).

Tuttavia non è ancora chiaro per me. Al momento ho pensato solo a 2 esempi specifici, forse

1) Con molti (git) push / merges che arrivano costantemente, con un tempo di compilazione sufficientemente lungo per eseguire una compilazione completa.

La descrizione di Joel di una build completa è la seguente: "Completa - è probabile che il tuo codice abbia più versioni: versioni in più lingue, più sistemi operativi o una versione high-end / di fascia bassa. tutti loro. E ha bisogno di costruire ogni file da zero, non basandosi sulle funzionalità di ricostruzione incrementale forse imperfetta del compilatore. "

Forse potresti risparmiare risorse, ma solo fare 1 build completa nel bel mezzo della giornata lavorativa, e accontentarti di eseguire tutti i test di unità / integrazione più veloci su ogni spinta.

La coda costante forse di build complete non-stop potrebbe creare una coda abbastanza grande da sconfiggere la pertinenza e lo scopo delle tue build, forse perché sarebbero sempre dietro.

Ciò si traduce in una build completa su ogni spinta che è forse l'ideale, ma in pratica non si avrà l'hardware in grado di gestire il vostro push thoroughput.

2) Potrebbe essere più conveniente passare attraverso le build giornaliere piuttosto che costruirle ad ogni push (la ragione 5 nelle sue build giornaliere è l'articolo di un amico).

builds continuous-integration automation

posta user1821961 29.05.2018 - 20:46

fonte

3 risposte

Leggi altre domande sui tag builds continuous-integration automation

Un modo semplice per servire mercurial? [chiuso] Quale sito deve essere considerato una WebApp?

score 5 · Answer 1

Lavoro su un progetto molto ampio con dozzine di ingegneri del software, dozzine di ingegneri del controllo qualità, ecc. Il nostro codebase è composto da diverse milioni di righe di codice. Abbiamo build notturne e abbiamo build continue. Servono a scopi diversi:

Le build notturne sono costruite da zero. Il build server controlla il codice e lo costruisce. Ciò garantisce che possiamo costruire da zero e non fare affidamento su artefatti di build da build precedenti che giacciono nella directory di build o altro. Diamo queste build al QA ogni mattina e loro eseguono test su di loro.
Durante il giorno, mentre stiamo scrivendo il software, il primo commit della giornata prende il via da una build. Successivamente, i commit vengono messi in coda e al termine della build precedente, la build successiva inizia con tutti i commit avvenuti in mezzo. Realmente realizziamo 2 build continui. Una build rapida e incrementale che costruisce solo cose che sono cambiate nei nuovi commit e un'altra build completa da zero. Le build complete durano circa 90 minuti con i test completi dell'unità. Le build incrementali richiedono solo pochi minuti per essere compilate e credo che eseguiremo una serie più piccola di unit test per un rapido turnaround. Se una build o un test falliscono, sappiamo che è stato causato da uno dei commit tra la build precedente e quella attuale. Ciò limita il commit che ha causato abbastanza bene il problema. Potremmo dover fare un piccolo lavoro di investigazione per capire quale dei 5-8 si impegna, ma di solito è abbastanza ovvio visto che gli sviluppatori di solito non lavorano nelle stesse aree.

Quando il QA trova un problema con una build notturna, possiamo tornare indietro attraverso le build continue che abbiamo costruito quel giorno e capire che il problema era in una particolare build. (In altre parole, regrediamo le build per vedere dove si sono verificate.) Possiamo vedere quali commit erano presenti in quella build, restringerla all'essenziale se necessario, e o ripristinare il commit o correggere il problema.

score 1 · Answer 2

Avevo una vista simile. Ora penso che dovrebbe esserci una build giornaliera oltre a build per-commit.

Compiti extra: puoi aggiungere compiti extra sul tuo cron build che non vorresti sul tuo build per-commit. Ad esempio, la cron build può analizzare le dipendenze per gli aggiornamenti e creare magicamente una richiesta pull riguardo loro.
Sanità: se la build di cron fallisce per qualche ragione (non dovrebbe, ma potrebbe), allora è logico aspettarsi che successive build per-commit falliscano per lo stesso motivo. Piuttosto che tirare fuori i capelli per capire come le modifiche al codice interrompono la costruzione, risolvi il problema sottostante.
Riunioni di stato: se hai una riunione sullo stato alle 10:00, dovresti avere un cron build alle 9:00. Dovrebbe solo riuscire, ma se per qualche ragione non lo fosse, il tuo stato dovrebbe includere la correzione della build.
Costo: probabilmente non è necessario, ma quanto costa. Penso che i benefici giustificano il costo minimo.

Le build di cron sono un supplemento alle build per-commit e non dovrebbero mai essere considerate come una sostituzione.

score 0 · Answer 3

Non ci sono davvero vantaggi nel fare build giornaliere (o qualsiasi altro periodico) purché tu abbia abbastanza risorse per fare build uguali per ogni commit.

Le build periodiche sono solo un compromesso se non si hanno abbastanza risorse di questo tipo: si rinuncia alla capacità di identificare immediatamente un commit errato poiché, se tale build fallisce dopo aver raccolto più nuovi commit dalla precedente build di successo, si è necessario eseguire un lavoro aggiuntivo per identificare esattamente quello difettoso e risolvere il problema (s). E questo potrebbe non essere sempre semplice, c'è spazio per tutti i tipi di complicazioni potenziali , ad esempio:

più set di modifiche difettosi raccolti simultaneamente nella nuova build, rendendo l'identificazione più difficile
clean backout / ripristino di un changeset difettoso potrebbe non essere possibile a causa di successivi changeset impegnati su quello difettoso, la correzione non torna indietro allo stato di un buon repository noto ma lo sposta in un nuovo stato che può o potrebbe non essere buono, richiedendo una o più build aggiuntive per la conferma
anche il clean backout di un changeset difettoso potrebbe non portare ad una buona build a causa di successivi changeset che dipendono da quello di back-out o che sono anche difettosi

Personalmente preferisco i sistemi di CI che eseguono verifiche pre-commit / gating: possono essere molto più convenienti, specialmente nei progetti su larga scala, evitare che i changeset difettosi arrivino persino al repository piuttosto che rilevarli e correggerli dopo che hanno già avuto un impatto sul tutto il team che lavora al progetto.

A seconda dell'algoritmo di orchestrazione utilizzato, tali sistemi possono garantire il 100% di prevenzione di rotture / regressioni anche se senza dispongono di risorse sufficienti per eseguire una compilazione per ciascun changeset candidato.