Domanda Build notturni: perché dovrei farlo? [chiuso]


Perché dovrei farlo Build notturni?


46
2017-10-15 12:58


origine


risposte:


Dovresti fare build notturni per assicurarti che il tuo codebase rimanga in salute.

Un effetto collaterale delle build notturne è che costringe il team a creare e mantenere uno script di compilazione completamente automatizzato. Questo aiuta a garantire che il processo di compilazione sia documentato e ripetibile.

I build automatici sono bravi a trovare i seguenti problemi:

  • Qualcuno ha controllato qualcosa che rompe cose.
  • Qualcuno ha dimenticato di archiviare un file o un cambio necessario.
  • I tuoi script di compilazione non funzionano più.
  • Il tuo computer di costruzione è rotto.

Fare questo notturno ti assicura di cogliere tali problemi entro 24 ore da quando si verificano. È preferibile trovare tutti i problemi 24 ore prima della consegna del software.

Dovresti anche, ovviamente, avere test unitari automatici che vengono eseguiti per ogni build notturno.


44
2017-10-15 13:05



Personalmente ho trovato che l'integrazione continua è meglio delle build notturne:
http://en.wikipedia.org/wiki/Continuous_integration

Lo uso persino su progetti one man, è incredibile quanto velocemente puoi esporre problemi e prendertene cura proprio lì.


22
2017-10-15 13:56



Ho fatto ingegneria di costruzione (tra le altre cose) per 16 anni. Sono un forte sostenitore dell'integrazione precoce, costruttiva, spesso continua. Quindi la prima cosa che faccio con un progetto è stabilire come sarà costruita (Java: Formica o Maven; .NETTO: NAnt o MSBuild) e come sarà gestito (Sovversione o qualche altro controllo di versione). Quindi aggiungerò l'integrazione continua (Regolazione automatica della velocità o CruiseControl.NET) a seconda della piattaforma, quindi lascia gli altri sviluppatori liberi.

Man mano che il progetto cresce e cresce la necessità di report e documentazione, le build impiegheranno più tempo per essere eseguite. A quel punto dividerò le build in build continue (eseguite al check-in) che compilano ed eseguono solo test unitari e build giornalieri che costruiscono tutto, eseguono tutti i report e creano qualsiasi documentazione generata. Potrei anche aggiungere una build di consegna che tagga il repository e fa qualsiasi pacchetto aggiuntivo per la consegna di un cliente. Userò obiettivi di compilazione a grana fine per gestire i dettagli, in modo che ogni sviluppatore possa costruire qualsiasi parte del sistema: il server di Continuous Integration usa gli stessi passi di costruzione di qualsiasi sviluppatore. Ancora più importante, non forniamo mai una build per i test o un cliente che non è stato creato utilizzando il build server.

Questo è quello che faccio - ecco perché lo faccio (e perché dovresti farlo anche tu):

Supponiamo di avere un'applicazione tipica, con più progetti e diversi sviluppatori. Mentre gli sviluppatori possono iniziare con un ambiente di sviluppo comune e coerente (stesso sistema operativo, stesse patch, stessi strumenti, stessi compilatori), nel corso del tempo i loro ambienti divergeranno. Alcuni sviluppatori applicheranno religiosamente tutte le patch di sicurezza e gli aggiornamenti, altri no. Alcuni sviluppatori aggiungeranno nuovi (forse migliori) strumenti, altri no. Alcuni ricorderanno di aggiornare il loro spazio di lavoro completo prima di costruire; altri aggiorneranno solo la parte del progetto che stanno sviluppando. Alcuni sviluppatori aggiungeranno il codice sorgente e i file di dati al progetto, ma dimenticheranno di aggiungerli al controllo del codice sorgente. Altri scriveranno test unitari che dipendono da specifici capricci del loro ambiente. Di conseguenza, vedrai rapidamente le famose scuse "Bene, costruisce / funziona sulla mia macchina".

Avendo un server separato, stabile, coerente e conosciuto per la creazione della tua applicazione, scoprirai facilmente questo tipo di problemi e, eseguendo build da ogni commit, sarai in grado di individuare quando un problema si insinua nel sistema . Ancora più importante, poiché si utilizza un server separato per la creazione e il confezionamento dell'applicazione, verrà sempre impacchettato tutto allo stesso modo, sempre. Non c'è niente di peggio che avere uno sviluppatore che invia una build personalizzata a un cliente, farlo funzionare e quindi non avere idea di come riprodurre le personalizzazioni.


19
2017-09-06 12:54



Quando ho visto questa domanda, per prima cosa ho cercato Di Joel Spolsky risposta. Un po 'deluso, quindi ho programmato di aggiungerlo qui.

Spero che tutti ne siano a conoscenza Joel Test su Carriere.

Dal suo blog su The Joel Test: 12 Steps to Better Code

3. Realizzi build giornaliere?

Quando usi il controllo del codice sorgente, a volte un programmatore   accidentalmente controlla qualcosa che rompe la build. Per esempio,   hanno aggiunto un nuovo file sorgente e tutto si compila bene   macchina, ma si sono dimenticati di aggiungere il codice sorgente al codice   repository. Quindi chiudono la loro macchina e tornano a casa, dimentichi e   contento. Ma nessun altro può lavorare, quindi devono andare a casa anche loro, infelici.

Rompere la build è così brutto (e così comune) che aiuta a fare   costruisce ogni giorno, per assicurare che nessuna rottura passi inosservata. In grande   squadre, un buon modo per assicurarsi che le rotture siano corrette subito   per fare la costruzione quotidiana ogni pomeriggio, per esempio, all'ora di pranzo. Tutti   fa il maggior numero possibile di check-in prima di pranzo. Quando tornano,   la costruzione è fatta. Se ha funzionato, bene! Tutti controllano il   ultima versione della fonte e continua a funzionare. Se la build fallisce,   lo aggiusti, ma tutti possono continuare a lavorare con la pre-build,   versione ininterrotta della fonte.

Nel team di Excel avevamo una regola che chiunque avesse rotto la build, come loro   "punizione", è stato responsabile per il babysitting delle build fino a quando qualcuno   altrimenti l'ha rotto Questo è stato un buon incentivo a non rompere la build e a   buon modo di ruotare tutti attraverso il processo di costruzione in modo che tutti   ho imparato come funzionava

Anche se non ho l'opportunità di creare build giornalieri, ne sono un grande fan.

Non sei ancora convinto? Dai un'occhiata al brief qui in Build giornalieri sono tuoi amici !!


9
2017-10-15 13:05



In realtà, ciò che dovresti desiderare è l'integrazione continua e il test automatico (che è un passo in più rispetto alle build notturne).

Se hai dubbi, dovresti leggere questo articolo di Martin Fowler su Continuous Integration.

Per riassumere, si desidera creare e testare il più presto e spesso possibile per individuare immediatamente gli errori in modo che possano essere corretti mentre quello che stavi cercando di ottenere quando li hai causati è ancora fresco nella tua mente.


7
2017-10-15 13:07



In realtà, consiglierei di creare build ogni volta che effettui il check-in. In altre parole, ti consiglio di configurare un sistema di integrazione continua.

I vantaggi di un tale sistema e altri dettagli possono essere trovati nell'articolo di Fowler e sulla voce di Wikipedia tra gli altri posti.

Nella mia esperienza personale, è una questione di controllo di qualità: ogni codice temporale (o test, che può essere visto come una forma di requisiti) vengono modificati, i bug potrebbero insinuarsi. Per garantire la qualità è necessario creare una nuova build del prodotto come sarebbe stato spedito ed eseguire tutti i test disponibili. Quanto più spesso questo è fatto, i bug meno probabili saranno autorizzati a formare una colonia. Pertanto, sono preferiti i cicli giornalieri (notturni) o continui.

Inoltre, indipendentemente dal fatto che si limiti l'accesso del proprio progetto agli sviluppatori o ad un gruppo più ampio di utenti, una compilazione notturna consente a tutti di essere nella "versione più recente", riducendo al minimo il rischio di unire nuovamente i propri contributi nel codice.


7
2017-10-15 13:48



Vuoi fare build su a programma regolare al fine di cogliere problemi con l'integrazione del codice tra gli sviluppatori. La ragione per cui vuoi farlo ogni notte, a differenza del programma settimanale o di un programma più lungo, più a lungo si aspetta di scoprire questo tipo di problemi, più difficile sarà risolverli. La pratica di creare una build ad ogni check in (Continuous Integration) sta semplicemente portando il processo di costruzione notturno ad un estremo logico.

Il vantaggio collaterale di avere un processo di ripetizione è importante anche a lungo termine. Se lavori in una squadra dove ci sono più progetti in corso, allora a un certo punto dovrai essere in grado di ricreare facilmente una vecchia build, forse per creare una patch. :(

Più è possibile automatizzare il processo di costruzione, più tempo si risparmia per ogni build successiva. Inoltre, elimina il processo di costruzione dal percorso critico di consegna del prodotto finale, che dovrebbe rendere felice il vostro manager. :)


4
2017-10-15 13:02



Dipende anche dalle dimensioni e dalla struttura del / i team / i che lavorano sul tuo progetto. Se ci sono team diversi che fanno affidamento sulle rispettive API, potrebbe essere sensato avere build notturni per un'integrazione frequente. Se stai distruggendo solo uno o due compagni di squadra, potrebbe valere la pena o meno.


3
2017-10-23 17:31



A seconda della complessità del prodotto, l'integrazione continua può o meno essere in grado di eseguire una suite di test completa.

Immagina che Cisco collauda un router con letteralmente migliaia di configurazioni diverse da testare. Per eseguire una suite di test completa su alcuni prodotti è necessario tempo. A volte settimane. Quindi hai bisogno di build per scopi diversi. Una build notturna può essere la base per una suite di test più approfondita.


3
2017-10-15 13:04