A che punto dovresti passare alla versione di rilascio?

So, for people following the first principle, at what point do you switch from debug to release builds?

Ci spostiamo presto, quando il codice sorgente ha ottenuto un numero di versione ed è stato inserito nella coda di build di Debian. Siamo nella fortunata situazione di fare software scientifico con input e output ben definiti e poche interazioni di sistema, tuttavia, quindi il costo di riprodurre una situazione di errore è piuttosto basso.

Questa è anche la mia risposta generale: il punto di cambiamento delle build dipende principalmente dai costi di riproduzione degli errori. Se questi sono molto alti, spedirei anche build di debug per testare i clienti. Mentre ciò comporta il rischio di fallimenti di build per la produzione, questo potrebbe comunque essere più economico rispetto alla spesa di settimane nella riproduzione del caso di test.

So, for people following the first principle, at what point do you switch from debug to release builds?

Non appena passiamo al QA, passiamo a rilasciare build. Ma quando mai costruiamo una versione di build, il nostro processo di build crea anche una versione di debug delle DLL. Questo ci consente di rilasciare rapidamente le DLL di debug nell'ambiente QA e ottenere informazioni aggiuntive se necessario.

Sia le versioni di rilascio che di debug delle DLL vengono salvate e conservate per diversi anni.

Nel nostro ambiente, il codice viene distribuito in molti siti. E quindi dovrebbe essere applicato un contesto diverso a ciascuna istanza di distribuzione. Di solito lo distribuiamo in una chiave "meno rischiosa" e vediamo l'esperienza.

Questa distribuzione è ancora in produzione quindi, questa non è la modalità 'debug'. Ma presuppone anche che i test siano fatti bene.

Naturalmente, con la modalità di debug disattivata, il debug rapido del codice (sul sito) potrebbe essere difficile. Ma se il rilascio è fallito, la produzione torna al rilascio di sicurezza.

Tuttavia, proviamo a mantenere o creare un ambiente identico, in grado di riprodurre nuovamente un ambiente di questo tipo. (So che questo non è sempre banale da fare) ma tutto ciò che serve a volte è riprodurre le transazioni / input.

Il punto è, quanto mai la versione della modalità di debug, debug dovrebbe non essere in produzione. Però, non dirò che questa è una regola.

Un'altra cosa è che il rilascio è ancora chiamato trial fino a quando non si è stabilito (eseguendo per un periodo di tempo significativo) altre strutture non lo accettano ancora.

Esistono altre pratiche per garantire che il processo di compilazione non sia del tutto errato. Guarda questo: Un modo semplice per migliorare il qualità di rilascio nell'ambiente RAD

Abbiamo configurato le nostre macchine sviluppatore per creare build di debug. Ma una volta che il devs ha eseguito il commit del codice, viene creato un pacchetto di distribuzione nel nostro ambiente di integrazione continua (TeamCity) e creato per il rilascio. Pertanto, ogni volta che decidiamo di implementare il QA, prendiamo l'ultimo pacchetto di distribuzione dal server CI e lo rilasciamo, quindi è sempre rilasciato a meno che non si trovi su una macchina di sviluppo.

BTW, per alcune lingue, anche quando si crea un rilascio, è comunque possibile creare simboli di debug. In .NET, ad esempio, esiste un'impostazione "pdb-only" che consente ottimizzazioni, ma crea comunque file di debug. Ovviamente il debugging di una versione di rilascio è più complicato dal momento che non è un equivalente line-for-line, ma può comunque essere utile in un pizzico.