Separa le build 'debug' e 'release'?

https://stackoverflow.com/questions/420343

05-07-2019
|

Domanda

Penso che sia meglio rilasciare la versione del software che i vostri sviluppatori hanno effettivamente testato; Tendo quindi a eliminare il target di "debug" dal project / makefile, in modo che sia possibile creare (e testare, eseguire il debug e rilasciare una sola versione).

Per un motivo simile, non utilizzo "asserzioni" (vedi anche Le asserzioni sono sempre male? ...).

Una persona lì ha sostenuto che il motivo di una versione di "debug" è che è più facile eseguire il debug: ma, ho contro-sostenuto che alla fine potresti voler supportare ed eseguire il debug di qualunque cosa tu abbia rilasciato, e quindi devi costruire una versione che puoi eventualmente eseguire il debug ... questo può significare abilitare i simboli di debug e disabilitare alcune ottimizzazioni, anche nella build 'release'.

Qualcun altro ha detto che "questa è una cattiva idea"; è una politica che ho sviluppato alcuni anni fa, essendo stata bruciata da:

Alcuni sviluppatori stanno testando il loro debug ma non le versioni di rilascio
Alcuni bug di scrittura degli sviluppatori che vengono visualizzati solo nella versione di rilascio
La società sta rilasciando la versione di rilascio dopo test inadeguati (è mai del tutto adeguata?)
Viene chiamato per eseguire il debug della versione di rilascio

Da allora ho visto più di un altro negozio di sviluppo seguire questa pratica (cioè non avere debug separati e build di rilascio).

Qual è la tua politica?

Soluzione

Questo potrebbe essere minore, ma si somma a ciò che altri hanno detto qui. Uno dei vantaggi di avere build di rilascio di test QA è che nel tempo le funzionalità integrate di debug e registrazione del tuo software avanzeranno a causa delle esigenze degli sviluppatori che devono capire perché le cose vanno male nel QA.

Più gli sviluppatori devono eseguire il debug delle build di rilascio, migliori saranno gli strumenti che avrai in seguito quando i clienti inizieranno ad avere problemi. Naturalmente, nessun motivo per gli sviluppatori di lavorare su build di rilascio come parte del ciclo di sviluppo.

Inoltre, non conosco alcuna società di software che abbia cicli abbastanza lunghi da permettersi il sovraccarico di passare dal QA al debug per rilasciare build a metà del periodo di test di una versione. Dover fare un ciclo completo di QA è qualcosa che troppo spesso accade abbastanza raramente.

Altri suggerimenti

Avere build di debug e release separate è una buona idea, perché semplifica lo sviluppo.

Ma le build di debug dovrebbero essere solo per lo sviluppo, non per i test. Si testano solo build di rilascio. E non usi gli sviluppatori per testare quelle build, usi i tester.

È una semplice politica che offre il meglio di entrambi i mondi, IMO.

Modifica: In risposta a un commento, penso sia ovvio che le build di debug e rilascio (possono) generare codice diverso. Pensa " -DDEBUG " vs. " -DNDEBUG " ;, e & # ;if se definito (DEBUG) " ;, ecc.

Quindi è fondamentale testare il codice che si finisce per spedire. Se fai generi codice diverso nei build di debug e release, questo significa test due volte, indipendentemente dal fatto che sia testato dalla stessa persona o meno.

I simboli di debug non sono un grosso problema, tuttavia. Compilare sempre con simboli di debug, conservare una copia del file binario non spogliato, ma rilasciare un file binario spogliato. Finché in qualche modo tagghi ogni binario con un numero di build, dovresti sempre essere in grado di identificare quale binario non spogliato corrisponde al binario spogliato che devi eseguire il debug ...

Come rimuovere binari e caricare simboli nel debugger da una fonte esterna dipende dalla piattaforma.

La nostra politica è di far lavorare gli sviluppatori sulle build di debug, ma TUTTI (QA, BA, vendite, ecc.) eseguono la versione di rilascio. Ieri ho dovuto correggere un bug che si presentava solo nella versione build it, era ovvio cosa stava succedendo semplicemente PERCHÉ si presentava solo in release

È il primo qui in questo negozio, e sono qui da circa 18 mesi.

Il punto in cui le cose si fanno pelose è quando la build di Release fa cose diverse rispetto alla build di debug - Sì, sono stato all'Inferno e l'ho visto in un codice di produzione molto vecchio e molto approssimativo.

Non vedo alcun motivo per non avere entrambi se l'unica differenza tra le configurazioni sono i simboli di debug e le ottimizzazioni.

quindi è necessario creare una versione che se necessario puoi eseguire il debug ... questo può significare abilitare i simboli di debug e disabilitando alcune ottimizzazioni, anche in la build "release".

Ummm ... sembra che tu stia facendo una build di debug per me ... giusto?

La parte in cui hai sbagliato è questa affermazione:

Penso che sia meglio rilasciare il versione del software che il tuo gli sviluppatori hanno effettivamente testato

Gli sviluppatori non testano il codice. Codice test test.

I test unitari dovrebbero testare TUTTI costruire configurazioni. Non far lavorare i tuoi sviluppatori con una mano legata dietro la schiena: lascia che utilizzino tutti gli strumenti di debug di cui dispongono. Una build di debug è una di queste.

Per quanto riguarda le asserzioni: l'uso delle asserzioni dipende in larga misura dalla programmazione o meno del contratto. In tal caso, le asserzioni verificano semplicemente il contratto in una build di debug.

Come da mia risposta nel thread collegato, usiamo anche la stessa build per il debug e il rilascio per ragioni molto simili. I miglioramenti delle prestazioni del 10% -20% dall'ottimizzatore tendono ad essere molto minori rispetto alle ottimizzazioni manuali a livello di algoritmo. Una singola build rimuove molti potenziali bug. Specificamente;

Variabili non inizializzate e piccoli buffer overflow potrebbero finire con risultati molto diversi in debug e build di rilascio ottimizzate.
Anche con le informazioni simboliche disponibili, il debug di una versione ottimizzata può essere difficile in quanto l'oggetto non corrisponde alla sorgente, ad es. le variabili potrebbero essere state ottimizzate e il codice potrebbe essere stato riorganizzato. Pertanto, i bug segnalati nelle build di versioni testate possono essere più difficili, e quindi richiedono molto tempo, da rintracciare.

Dopo aver confrontato build non ottimizzate e ottimizzate con test di regressione automatizzati, i miglioramenti delle prestazioni forniti dall'ottimizzazione non forniscono un valore aggiuntivo sufficiente per avere due build nel mio caso. Vale la pena notare che il software che sviluppo è molto affamato di CPU (ad es. Creazione e manipolazione di modelli di grandi superfici).

Quando sviluppo con Java, odio le versioni non di debug. Quando viene generata un'eccezione, non si ottengono informazioni sulla linea che rendono difficile o addirittura impossibile rintracciare i bug. Inoltre, la differenza di runtime tra debug e non debug è di circa il 5% con Java 5 o versioni successive, quindi questo non è davvero un problema e con i dischi rigidi di oggi, le dimensioni non contano più.

Sul lato positivo usando le versioni di debug:

Le tracce dello stack contengono tutte le informazioni necessarie
Le variabili possono essere esaminate
In caso di problemi di produzione, è possibile semplicemente collegarsi al processo in esecuzione senza dover prima arrestare il server per installare una versione di debug.
Non sarai catturato da bug di ottimizzazione intelligenti
La build è più semplice (solo un artefatto)

Gli sviluppatori lavorano con build di debug, QA e tutti gli altri usano la versione di rilascio, che chiamiamo "produzione". Il vantaggio principale di ciò è che nella build di debug possiamo aggiungere un sacco di codice aggiuntivo e asserzioni. Alcuni oggetti contengono informazioni extra che non hanno alcun utilità tranne quando si visualizza il codice nel debugger. Alcuni oggetti si convalidano periodicamente per assicurarsi che tutte le informazioni sullo stato siano coerenti. Queste cose rendono la versione di debug molto più lenta, ma ci hanno aiutato a trovare la fine di bug che sarebbe stato un inferno trovare nella build di produzione.

Come ho detto, tutti i nostri controlli di qualità e test delle prestazioni utilizzano build di produzione e occasionalmente ci imbattiamo in problemi che si presentano nella produzione ma non nel debug. Ma sono relativamente rari e, come sviluppatore, i vantaggi del debug di una build di debug piuttosto che di una build di produzione superano di gran lunga questo problema.

Penso che dipenda dalle dimensioni del progetto e dal tipo di sistema di build e test che stai utilizzando.

Se disponi di un sistema di compilazione automatizzato ed è semplice eseguire test di unità e funzionali su una data build, non dovresti mai avere problemi con più tipi di build.

Mi sono sempre iscritto a " Spedisci ciò di cui esegui il debug, quindi puoi eseguire il debug di ciò che spedisci " approccio, per tutti i motivi che elenchi nella tua domanda.

Secondo me questa discussione manca di un punto molto importante:

Dipende molto dal tipo di progetto!

Se crei un progetto nativo (C / C ++), in effetti sarai costretto a creare build di debug, semplicemente perché l'ottimizzazione del compilatore può rendere il debug quasi impossibile in alcuni casi.

Se crei applicazioni Web, potresti preferire semplicemente avere una build (sebbene "build" sia piuttosto fuorviante per alcune applicazioni web) che può abilitare le funzionalità di registrazione durante il runtime.

Sebbene un progetto C ++ nativo e un'applicazione web PHP non siano ovviamente tutti i tipi di progetto esistenti, spero che il mio punto sia stato superato.

P.S .: Durante lo sviluppo per C #, ti imbatti in un caso limite poiché, sebbene l'utilizzo di una build di debug disabiliti le ottimizzazioni del compilatore, nella mia esperienza non incontrerai quasi le stesse differenze rispetto a C ++

qui sviluppiamo in modalità debug e facciamo tutti i test unitari in modalità release. siamo un piccolo negozio con poche (meno di 12) applicazioni da supportare che vanno da ASP classico, ASP.Net, VB.Net e C #. Abbiamo anche una persona dedicata per gestire tutti i test, i problemi di debug vengono restituiti agli sviluppatori.

Costruiamo sempre entrambi, mai nemmeno considerato di non farlo. L'abilitazione delle opzioni di debug aumenta la dimensione del codice e rallenta le prestazioni, probabilmente non è un problema con il tipo di software durante il test, ma cosa succede se il cliente esegue il codice più altre 5 app ...

I problemi con i test possono essere risolti utilizzando i test automatici in modo che la build di rilascio possa essere testata senza sforzo quando pensi di essere pronto per il rilascio. L'incapacità degli sviluppatori o della società di testare correttamente i build di rilascio non è un errore nell'idea di build di rilascio e debug, ma nei propri sviluppatori e / o società.

Sul tuo ultimo punto, non sono mai stato invitato a eseguire il debug di una build di rilascio, solo per risolverlo ...

È un compromesso. Dato che i cicli della CPU sono economici e diventano più economici mentre i cicli umani rimangono costosi, ha molto senso mantenere solo una singola versione di un programma ampio e complesso: la versione di debug (gable).

Usare sempre le asserzioni è sempre una politica più sicura che non usarle mai. Se si producono versioni separate di debug e rilascio, riattivare qualsiasi simbolo #define necessario per garantire che le asserzioni siano abilitate anche nella versione di rilascio.

Penso che il compromesso sia semplice: sì, con solo una build di rilascio, testerai davvero ciò che viene effettivamente spedito. D'altra parte, paghi un prezzo facilmente per il debug per i tuoi sviluppatori e / o le prestazioni per l'utente, quindi spetta a te controllare entrambi i casi.

Sulla maggior parte dei progetti di medie e grandi dimensioni, la facilità di debug garantirà un prodotto migliore per i tuoi utenti alla fine.

Vedi questo Qual è la tua opinione di programmazione più controversa?

citazione:

Opinione: mai e poi mai diversamente   codice tra " debug " e "rilascio"   costruisce

La ragione principale è quella versione   il codice non viene quasi mai testato. Meglio   per avere lo stesso codice in esecuzione nel test   come è in natura.

Rimuovendo il "target di debug", stai forzando gli sviluppatori a eseguire il debug sulla versione di rilascio del software. In pratica, ciò che questa procreazione è due cose:

1) " build di rilascio " le ottimizzazioni saranno disabilitate (gli sviluppatori di altro genere non possono utilizzare un debugger)

2) Nessuna build avrà macro PREPROCESSOR speciali che ne alterano l'esecuzione.

Quindi quello che farai davvero è unire le configurazioni di rilascio e debug piuttosto che eliminare solo il "debug" modalità.

L'ho fatto personalmente con lo sviluppo di iOS senza effetti negativi. La quantità di tempo trascorso nel nostro codice scritto è inferiore all'1% di ciò che sta realmente accadendo, quindi le ottimizzazioni non hanno contribuito in modo significativo. In questo caso, sembrano davvero causare un aumento dei bug, ma anche se non lo facessero, l'idea di testare in un modo, quindi dare al QA con codice diverso introduce solo un altro fattore da considerare con i problemi.

D'altra parte, ci sono casi in cui le ottimizzazioni sono necessarie, dove sono utili e anche dove c'è abbastanza tempo per testarle entrambe. Di solito, i cambiamenti tra debug e release sono così minori che non causano alcun problema a nessuno.

Se hai un vero gruppo di controllo qualità su cui poter contare per testare completamente la cosa, direi di eseguire il debug build fino a quando non ti avvicini al rilascio, e quindi assicurarti che un ciclo completo di QA sia eseguito sul stessa build che esce dalla porta.

Anche se in almeno un caso abbiamo rilasciato qualcosa che conteneva ancora del codice di debug. L'unica conseguenza è stata un po 'più lenta e i file di registro erano dannatamente grandi.

Nella mia azienda abbiamo sia Debug che Release. - Gli sviluppatori utilizzano la versione di debug per trovare e correggere correttamente i bug. - Stiamo usando TDD e quindi disponiamo di una grande suite di test che eseguiamo sul nostro server che verifica sia le configurazioni di debug che di rilascio nonché build 64/32 che abbiamo.

Quindi, se si utilizza il " debug " la configurazione aiuta uno sviluppatore a trovare un bug più velocemente, non c'è motivo di non usarlo - quando il codice entra nel server (per essere ulteriormente testato) o rivisto usiamo il "Rilascio". uno.

Ho imparato a creare la versione di rilascio con i file .PDB molto tempo fa in modo da poter eseguire il debug della versione di rilascio. Ciò che molti programmatori tendono a dimenticare è che quando si esegue la versione di debug, con tutte le ottimizzazioni disattivate, si esegue il debug di un programma completamente diverso. Potrebbe comportarsi come la build di rilascio (per la maggior parte), ma è ancora un programma diverso rispetto alla build di rilascio.

Inoltre, il debug della build di rilascio non è così difficile. E se ricevi una discarica, devi essere in grado di farlo comunque.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow