Rilasciare build vs build notturno

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

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

Ora, la domanda:

• È meglio avere un terzo "Release build" separato come build di rilascio?
• Oppure fai "Nightly build" in modalità di rilascio e utilizzalo come versione?

Cosa stai usando nella tua azienda?

(La build di rilascio dovrebbe anche aggiungere una sorta di tag al controllo del codice sorgente della potenziale versione del prodotto.)

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

La differenza tra release e build notturne:

• la build notturna viene eseguita automaticamente, beh, ogni notte, mentre la build di rilascio deve essere eseguita manualmente in determinati momenti
• release build dovrebbe idealmente taggare / ramificare il codice sorgente ed eventualmente distribuire gli artefatti di build in un repository centrale (ad esempio quando si utilizza Maven)

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

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

Il fatto è che se la tua versione di rilascio e quella notturna non sono le stesse, c'è la possibilità che qualunque cosa sia diversa potrebbe mascherare un problema (o rendere più difficile rintracciarne uno).

Avrei un unico processo di compilazione, che avrebbe creato tutto ogni check-in eseguito dal servizio CI. Sarebbe sia debug che build di rilascio.

Avere due o tre processi separati sta semplicemente chiedendo loro di iniziare a cambiare in modo casuale senza essere documentati, e non passerà molto tempo prima che qualcuno si ritrovi a dover fare 15 passaggi per ogni potenziale rilascio per essere pronto ad uscire.

Una cosa che mi piace fare è mettere la build notturna in modalità di rilascio piuttosto che in modalità debug. Con 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 l'ottimizzazione del codice.

A meno che tu non stia davvero collegando un debugger alla tua build notturna, ti suggerirei di fare anche questo.

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