Quanto sono importanti le build giornaliere? [chiuso]

Penso che ciò che è importante notare qui è che le regolari build aiutano a catturare gli errori più presto che dopo . Non avere per essere quotidiano, ma abbastanza spesso. Idealmente, può anche eseguire i test di unità.

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

Configuralo per costruire i tuoi principali rami di sviluppo.

Lo usiamo al lavoro (anche se costruiamo ora), e spesso quando dimentichiamo di impostarlo, scopriamo problemi solo poche ore prima del rilascio.

Devi aggiungere un po 'di questo (e @GoodEnoughs):

but this only sounds like a minor nuisance for distributed version control.

Enfaticamente no - che cosa fa una build "server" ti dice che il tuo baule costruirà e passerà i suoi test più o meno da pulito (meno è la quantità di configurazione che devi fare del tuo ambiente).

Sto pensando di passare a DVCS ma, anche dopo averlo fatto, trascinerete la mia integrazione continua dalle mie fredde mani.

Per fare un semplice esempio - stai sviluppando la feature "a" che sta sviluppando la funzione "b" distribuita o no a un certo punto devi cucirla tutti insieme - se, quando ti impegni, dimentichi di aggiungere un file l'app si baserà sulla tua macchina ma non lo farà da nessun'altra parte. Quindi quando spingi la build sul tuo "tronco", l'integrazione continua si innescherà e la build fallirà e tu saprai e spero che prima qualcuno estrae il tuo codice non proprio così completo che sarai in grado di prendere passi.

Se stai lavorando su 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 dal modo in cui funziona il controllo della versione.

Se hai aggiunto una funzione, in particolare quella in cui altre persone hanno una dipendenza, puoi essere sicuro che quando viene spinto a "vivere" che crea e passa test in un luogo diverso dal tuo ambiente di sviluppo è enorme . Inoltre, distribuisco dalle build del mio server di build - il suo tipo di come si specifica la build "definitiva". In definitiva avrò build di distribuzione attivate dall'utente. Non è corretto dire che si può lavorare su di esso - non è possibile se ne avete bisogno (e io ho criptato attorno a scatole di sviluppo in un ufficio per trovare e commettere file mancanti).

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

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

Ai tempi dei sistemi di controllo dei sorgenti centrali, proponevo la creazione continua in esecuzione ogni 5-10 minuti quando qualcosa è cambiato nel codice sorgente. Da 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 distribuiti, un continuo la build potrebbe non essere necessaria tanto da quando gli sviluppatori toccano il "pristine" code-base direttamente meno spesso.

Idealmente, a meno che tu non stia costruendo qualcosa di enorme che richiede più di mezza giornata per costruire, lo faresti più di una volta al giorno. Dopo aver configurato un server di integrazione continua, ad esempio Hudson o TeamCity , le build avverranno automaticamente, in genere ogni ora o ogni commit, e sarai avvisato in caso di problemi.

È un buon modo per rilevare gli errori in anticipo, soprattutto se si eseguono anche test automatici 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 tracciare le metriche nel tempo (ad esempio percentuale di copertura del codice, tempo di costruzione, linee di codice, ecc.)

Le build giornaliere sono a posto. Ne hai davvero bisogno se non hai nient'altro che, a essere onesti, penso che il test di Joel sia un po 'datato in questi giorni.

Secondo me, dovresti costruire continuamente durante la giornata, eseguendo i tuoi casi di test unitari, di sistema e di funzionalità e, idealmente, impacchettando e implementando in un ambiente simile allo stage, verificando nel contempo che qualsiasi sistema di controllo delle versioni di DB e ambiente hanno funzionato come previsto.

Se i tempi di compilazione o di implementazione sono eccessivi, prendere in considerazione la possibilità di optomizing via alcuni di questi problemi con dischi RAM fisici o software, connessioni Internet più veloci, build parallellizzanti, ecc. Il tempo che si risparmia identificando rapidamente le interruzioni di build è l'amoratizzazione dell'hardware costa abbastanza rapidamente.

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

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

L'idea alla base di "build giornaliera" è di avere sempre qualcosa di pronto che i tester e i project manager possono eseguire in modo che tutti abbiano un'idea di quale sia lo stato reale del progetto.

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