Release build vs nightly build

13

Una soluzione tipica è quella di avere una build CI (Continuous Integration) in esecuzione su un server di build: analizzerà il codice sorgente, creerà build (nel debug) ed eseguirà test, misurerà la copertura del test, ecc.

Ora, un altro tipo di build di solito noto è "Nightly build": fai cose lente come creare documenti di codice, creare un pacchetto di installazione, distribuire in ambiente di test ed eseguire test automatici (fumo o accettazione) sull'ambiente di test, ecc.

Ora, la domanda:

  • È meglio avere una terza "build di rilascio" separata come build di rilascio?
  • Oppure fai "Nightly build" in modalità di rilascio e usalo come versione?

Che cosa stai usando nella tua azienda?

(La versione di rilascio dovrebbe anche aggiungere qualche tipo di tag al controllo del codice sorgente della potenziale versione del prodotto.)

    
posta Tuomas Hietanen 08.03.2011 - 14:09
fonte

4 risposte

13

Un caso per cui la versione di rilascio è uguale alla build notturna è: vuoi testare esattamente le stesse cose che hai pubblicato . Non vuoi scoprire bug di produzione che potrebbero essere stati già rilevati in test di sviluppo.

La differenza tra versioni e versioni notturne:

  • nightly build viene eseguito automaticamente, beh, ogni notte, mentre la build di rilascio dovrebbe essere eseguita manualmente in determinati momenti nel tempo
  • release build dovrebbe idealmente taggare / ramificare il codice sorgente, e possibilmente distribuire gli artefatti di build in un repository centrale (ad es. quando si usa Maven)

Queste differenze sono in pratica alcune opzioni extra nella maggior parte dei sistemi di gestione delle build che conosco. Per ridurre al minimo la possibilità di errori umani, questi potrebbero essere salvati per es. in un file batch / script che prende solo i parametri necessari (e li convalida).

    
risposta data 08.03.2011 - 14:14
fonte
7

Bene, vorrei che la versione di rilascio fosse il più vicino possibile alla notte possibile! Idealmente esattamente lo stesso, ma con un tag.

Il fatto è che se il tuo rilascio è compilato e la notte non sono uguali, c'è una possibilità che qualsiasi cosa sia diversa possa mascherare un problema (o rendere più difficile rintracciarne uno).

    
risposta data 08.03.2011 - 14:13
fonte
3

Avrei un unico processo di compilazione, che creerebbe ogni cosa che viene eseguita dal servizio CI. Sarebbe sia il debug che i build di rilascio.

Avere due o tre processi separati sta solo chiedendo loro di iniziare a cambiare casualmente senza essere documentati, e non passerà molto tempo prima che qualcuno si ritrovi a dover fare 15 passi per ogni potenziale release per prepararlo ad uscire porta.

    
risposta data 08.03.2011 - 15:46
fonte
2

Una cosa che mi piace fare è mettere la compilazione notturna in modalità di rilascio piuttosto che in modalità di debug. Con i framework di registrazione come log4net che sostituiscono System.Diagnostics.Debug le principali differenze tra le modalità Release e Debug sono la durata degli oggetti e le ottimizzazioni del codice.

A meno che non si stia effettivamente allegando un debugger alla build notturna, suggerirei di farlo anche in questo caso.

Il processo che seguiamo è che la compilazione notturna viene eseguita ogni notte e, se funziona, possiamo distribuire la stessa build sui nostri altri server (nessuna ricostruzione, basta prendere gli installer impacchettati ed eseguirli). Se abbiamo un problema con la compilazione notturna, controlliamo le modifiche ad esso su un ramo ed eseguiamo un build "notturno" durante quel giorno. I test possono quindi essere rieseguiti.

    
risposta data 08.03.2011 - 14:34
fonte

Leggi altre domande sui tag