Quanto sono importanti le build giornaliere? [chiuso]

Uno dei criteri del test Joel è build giornaliere. L'idea è che se la build viene interrotta, chiunque l'abbia rotta è in giro per sistemarla. Se la build non può essere riparata, tutti dovranno provare una vecchia versione e lavorarci su. Riesco a capire come questo può essere piuttosto negativo sul controllo centralizzato della versione in cui è importante evitare il più possibile la fusione e la ramificazione, ma questo sembra solo un piccolo fastidio per il controllo della versione distribuita. Sei d'accordo con questo? Ci sono altri motivi per cui le build giornaliere sono importanti?

Penso che ciò che è importante notare qui sia che le build regolari aiutano a rilevare gli errori prima piuttosto che dopo . Non deve essere quotidiano, ma abbastanza spesso. Idealmente, può anche eseguire i test unitari.

L'obiettivo è scoprire quando una build si interrompe prima della fase di test finale, per trovarli il prima possibile.

Basta configurarlo per creare il / i proprio / i ramo / i di sviluppo principale.

Lo usiamo al lavoro (anche se costruiamo ogni ora), e spesso quando dimentichiamo di installarlo troviamo dei problemi poche ore prima del rilascio.

È necessario aggiungere un po 'a questo (e @GoodEnoughs):

ma questo sembra solo un piccolo fastidio per il controllo della versione distribuita.

Assolutamente no - ciò che fa una build "server" è dirti che il tuo trunk costruirà e supererà i suoi test più o meno da clean (minore è la quantità di configurazione che devi fare del tuo ambiente).

Sto pensando di passare a DVCS ma anche dopo aver fatto ciò trascinerai la mia continua integrazione dalle mie fredde mani morte.

Per fare un semplice esempio - stai sviluppando la funzione "a" sta sviluppando la funzione "b" distribuita o meno ad un certo punto devi ricucire tutto insieme - se, quando ti impegni, ti dimentichi di aggiungere un file che l'app creerà sulla tua macchina ma non lo farà da nessun'altra parte. Quindi, quando spingi la build nel tuo "trunk", l'integrazione continua si innescherà e la build fallirà e lo saprai e, si spera, prima che qualcuno tira il tuo codice non così completo, sarai in grado di fare dei passi.

Se stai lavorando a un progetto con più sviluppatori, devi essere in grado di definire da dove provengono le versioni di rilascio - il trunk in effetti - questo è vero indipendentemente da come funziona il controllo della versione.

Se hai aggiunto una funzionalità, in particolare una su cui altre persone hanno una dipendenza, essere sicuri che quando viene spinto a "vivere" si costruisce e supera i test in un ambiente diverso dall'ambiente di sviluppo è enorme. Inoltre, eseguo la distribuzione dalle build dal mio server di build, ovvero il modo in cui si specifica la build "definitiva". Alla fine avrò build di distribuzione attivate dall'utente. Il suo non va bene dire che si può lavorare intorno ad esso - non si può se ne avete bisogno (e io ho strapazzate scatole dev rotonde in un ufficio per trovare e impegnarsi file mancanti).

È tutto un po 'forte? Non lo so, ma il mio server di build è una di quelle cose che avendo non ho alcun desiderio di restituire.

Le build giornaliere credo siano molto importanti. Se hai una squadra distribuita in diversi fusi orari, allora è meglio trovare il tempo che è approssimativamente "fine giornata" per la maggior parte della squadra. Inoltre, se le build quotidiane hanno un componente di test automatizzato, è più desiderabile.

Ai tempi dei sistemi di controllo del codice sorgente centrale, raccomanderei build continue in esecuzione ogni 5-10 minuti quando qualcosa veniva cambiato nel codice sorgente. Poiché un errore di compilazione ha il potenziale di rallentare la maggior parte della squadra. Per le organizzazioni che eseguono sistemi di controllo del codice sorgente distribuito, potrebbe non essere necessario un build continuo poiché gli sviluppatori toccano la base di codice "incontaminata" direttamente meno spesso.

Idealmente, a meno che tu non stia costruendo qualcosa di massiccio che richiede più di mezza giornata per essere costruito, dovresti costruire più di una volta al giorno. Dopo aver configurato un server di integrazione continua, come Hudson o TeamCity , le build avverranno automaticamente, in genere ogni ora o su ogni commit, e riceverai una notifica in caso di problemi.

È un buon modo per rilevare gli errori in anticipo, soprattutto se si eseguono anche test automatizzati come parte della build. È particolarmente utile per trovare errori di configurazione in cui la build funziona sulla macchina di uno sviluppatore ma non funziona altrove perché qualcosa è stato omesso dal repository o dall'ambiente.

I server di integrazione continua più avanzati consentono anche di tenere traccia delle metriche nel tempo (ad es. Percentuale di copertura del codice, tempo di costruzione, righe di codice, ecc.)

Le build giornaliere vanno bene. Ne hai sicuramente bisogno se non hai nient'altro che essere sincero, penso che il test di Joel sia un po 'datato in questi giorni.

A mio avviso, dovresti costruire continuamente tutto il giorno, eseguendo i tuoi casi di test a livello di unità, sistema e sistema e idealmente impacchettando e distribuendo su un palcoscenico come ambiente allo stesso tempo, verificando al contempo che tutti i meccanismi di versioning di DB e ambiente che hai in atto stanno funzionando come previsto.

Se i tempi di compilazione o distribuzione sono eccessivi, prendere in considerazione la possibilità di eliminare alcuni di questi problemi con dischi RAM fisici o software, connessioni Internet più veloci, parallelizzazioni di build, ecc. Il tempo che si risparmia identificando rapidamente le interruzioni di build aumenterà il costo dell'hardware piuttosto rapidamente .

Le build giornaliere non sono importanti. Le build giornaliere che hanno sempre successo sono (o quelle in cui si interrompe solo per un'ora). Avere CI quando la build viene interrotta il 70% delle volte non è molto utile, perché se la cosa è in gran parte rotta non ti aiuta a identificare un errore.

Penso che dovrebbe essere costruito, testato e distribuito quotidianamente sul server di gestione temporanea.

L'idea alla base della "costruzione quotidiana" è quella di avere sempre qualcosa pronto che i tester e i project manager possono eseguire in modo che tutti abbiano un'idea di quale sia il vero stato del progetto.

In passato con le app desktop dopo la "build giornaliera" un tester o un project manager può immediatamente eseguire l'app, quindi non è stato necessario menzionare alcuna fase di distribuzione.