Integrazione continua: crea Debug e Release ogni volta?

8

È prassi normale quando si imposta un server di Continuous Integration per creare una versione di debug e release di ciascun progetto? La maggior parte delle volte gli sviluppatori codificano con un set di configurazione del progetto in modalità debug abilitato e potrebbero esserci configurazioni di percorsi della libreria, definizioni del compilatore o altri elementi configurati in modo diverso tra debug / release che li indurrebbero ad agire in modo diverso.

Ho configurato il mio server CI per creare sia Debug & Rilascio di ciascun progetto e mi chiedo se lo sto solo pensando troppo. Il mio presupposto è che lo farò finché riesco a ottenere un feedback rapido e una volta che ciò accadrà, quindi spingerò il Release su una build notturna forse. Esiste un modo "standard" di approccio a questo?

    
posta Darian Miller 02.04.2012 - 18:27
fonte

5 risposte

8

Costruire entrambe le configurazioni non farà male, ma se devi scegliere (soprattutto a causa dei vincoli di tempo di costruzione), allora crea la configurazione di rilascio.

In definitiva, vuoi creare, testare, impacchettare e distribuire la configurazione che i tuoi clienti useranno e trovare eventuali problemi con esso prima che facciano.

    
risposta data 04.04.2012 - 03:23
fonte
8

Solo versione.

Supponiamo che gli sviluppatori stiano eseguendo debug build e che i bug peggiori siano quelli "funziona con debug". Più velocemente sarai in grado di individuarli e restringere i cambiamenti che potrebbero averli provocati, più felici saranno tutti!

    
risposta data 03.04.2012 - 22:49
fonte
4

Vorrei strongmente consigliare di costruire e testare entrambi se può essere fatto in una sola notte.

  • potresti rilevare alcuni heisenbug
  • ti assicuri che il tuo cliente riceva il comportamento che hai testato e convalidato
risposta data 03.04.2012 - 22:52
fonte
1

Dovresti costruire tutto per il quale esiste la possibilità che non venga provato da nessuno per qualche tempo. Il che significa che se hai un solo target di build, non hai bisogno di eseguire Debug in continua integrazione, perché gli sviluppatori noteranno rapidamente. Ma il più delle volte ci sono più componenti e i componenti su cui non si sta lavorando attualmente non saranno costruiti dagli sviluppatori, ma potrebbero comunque essere interrotti da modifiche nel codice comune. In questi casi è necessario creare tutte le configurazioni in modo da non trovare la build danneggiata quando è necessario toccare tali componenti.

Ora spesso creare tutto in ogni configurazione richiede molto tempo, quindi non è possibile creare tutto dopo ogni commit. In tal caso, eseguire sempre le configurazioni di rilascio dei componenti più importanti e aggiungere una build notturna di tutto.

Al momento lavoro sul progetto, dove abbiamo una build continua, che esegue il polling del controllo della versione ogni 10 minuti e anche se è solo che le configurazioni selezionate possono ancora richiedere più di 1 ora dopo i commit più grandi. Poi abbiamo una build notturna, che costruisce tutti i componenti in tutte le configurazioni e crea sempre una build pulita, che richiede circa 5 ore. E che abbiamo una build settimanale, che crea versioni in tutte le varianti personalizzate e che richiede più di un'intera giornata.

    
risposta data 04.04.2012 - 08:30
fonte
0

Dipende dal tuo progetto. Nel mio attuale progetto creiamo solo il debug (ed eseguiamo test unitari) su ogni commit mentre realizziamo la versione di rilascio come parte della "build di distribuzione".

All'ultima società che ho lavorato abbiamo avuto alcuni problemi con la versione di rilascio che funzionava in modo un po 'diverso, quindi abbiamo compilato il debug e il rilascio su ogni commit ed eseguito test di unità su entrambi.

    
risposta data 03.04.2012 - 22:42
fonte

Leggi altre domande sui tag