Qual è la tua strategia per convertire le build RC in retail?

Segui il tuo istinto. Sarebbe bello se si potesse fare in modo che il candidato alla release guardasse prima del rilascio e in un altro modo, ma hai ragione: è importante che la versione rilasciata sia esattamente ciò che il QA ha approvato. Nella mia esperienza, il solito MO è:

• Produce versioni di test (alfa, beta) chiaramente contrassegnate. Mandali al QA per i test.

• Man mano che ti avvicini al rilascio, produci versioni candidate di rilascio che sono ancora chiaramente contrassegnate. Mandali al QA per i test.

• Una volta che il candidato al rilascio ottiene il sigillo di approvazione, produce una build finale "golden master" che esattamente che intendi spedire. Nessun marchio "golden master" o "release candidate". Invia questo a QA ancora una volta.

• Quando il QA approva il golden master, spediscilo. O meglio, li ha loro in modo che non ci siano dubbi sul fatto che la versione approvata sia la versione di spedizione.

È comunque una buona idea trovare alcuni mezzi tecnici per attivare e disattivare i segni "test". Ciò ti aiuterà a ridurre al minimo i passaggi che devi eseguire tra l'approvazione del candidato finale e la versione di spedizione. Il mio punto qui è che dovresti controllare il prodotto dopo che hai eseguito quei passaggi, qualunque essi siano.

Diamo un'occhiata a questo modo orientato agli oggetti. Un progetto ha solo una versione - nel senso che un cambio di codice lo rende diverso dalla sua versione precedente. Pertanto, la versione deve essere una proprietà del progetto.

D'altra parte, un progetto (nella maggior parte dei casi) non verifica se stesso o non lo certifica. Questa decisione è presa dai team di test / controllo qualità. E quindi, mentre loro possono etichettare il progetto "Alpha", "Beta", "RC", "Oro", "Platino", "Vendita al dettaglio" ecc. Questa etichettatura non è una proprietà della costruzione ma piuttosto della tua percezione di quella build.

Si sta tentando di archiviare queste informazioni nel progetto stesso (forse anche in AssemblyInfo.cs) ma come la tua domanda e la risposta di Caleb mostrano che è necessario ricostruire il progetto dopo ogni fase (per modificare / rimuovere la filigrana).

Quindi ecco la soluzione - Generare la filigrana in fase di esecuzione utilizzando un altro sistema (può essere semplice come un oggetto Web interrogabile dal progetto, un semplice file, una voce di database - decidere). La chiave è mantenere questo sistema al di fuori dell'ambito del progetto e solo le autorità di test aggiornano i "filigrane" di compilazione.

Ecco come appare questo sistema (con la timeline):

  Version  |   Status |    Comment
------------------------------------------------------------------------------------------------------------
    1.0    |   Alpha  |  First dev. build released
    1.0    |   Beta   |  Dev. team tests and decides to release it as beta without any code change/rebuild
    1.0.1  |   Beta   |  QA team identifies a bug, dev. fixes, rebuilds, updates the version, sends it for more testing.
    1.0.2  |   Beta   |  QA team identifies a bug, dev. fixes, rebuilds, updates the version, sends it for more testing.
    1.1    |   Beta   |  QA team identifies a bug, dev. fixes, rebuilds, updates the version, sends it for more testing.
    1.1    |   RC     |  QA team promotes it to RC build. You send the exact same build for user testing/preview.
    1.1    |   Retail |  Users do not report bugs, QA team also does not. You decide this build (without any change) can be shipped to retail.

Un ulteriore vantaggio di questo sistema è che controlli il tag di build e puoi facilmente creare un tag più recente (ad esempio, scaduto, richiamato) e inviarlo senza reinstallazione o implementazione dell'applicazione. In quanto a prova di errore, la filigrana dovrebbe mostrare un valore predefinito o l'ultimo valore interrogato nel caso in cui non possa stabilire una connessione al sistema.

Modifica: se non sei un fan dei sistemi esterni, tieni semplicemente un semplice file all'interno del progetto stesso ma non incorporato nell'assembly principale / jar / etc. Questo file può tracciare la filigrana di costruzione. La chiave è non incorporare la filigrana in un'unità che deve essere compilata per poter essere modificata.

Dovresti esplorare Gestore configurazione di Visual Studio . Può fare ciò che vuoi che faccia. Abbiamo implementato ogni configurazione con un diverso progetto di installazione in modo che per ogni build fosse necessario eseguire compilazione sul progetto di installazione che il desiderio era quello di creare. Abbiamo implementato lo schema Dev / Test / prod watermarking in questo.