La build dovrebbe guidare i tuoi tag o i tag dovrebbero guidare la compilazione?

Question

La build dovrebbe guidare i tuoi tag o i tag dovrebbero guidare la compilazione?

#1 da (1 voti)
#2 da (1 voti)
#3 da (1 voti)
#4 da (0 voti)
#5 da (0 voti)

6

Il nostro attuale metodo di creazione di una versione del prodotto è di contrassegnare tutti i repository dei componenti con la versione successiva appropriata e quindi modificare uno script di master build con questi nuovi numeri di versione per ciascun componente. Verrà quindi eseguito lo script di master build, che eseguirà un controllo SCM di ciascun componente, quindi modificherà il file AssemblyInfo.cs in modo che l'exe compilato (o dll) abbia il numero di versione corretto e quindi compili il componente. Tutti questi componenti vengono quindi combinati in una versione del prodotto che è "versionata" con un puro numero di marketing deciso.

Quindi il nostro processo rientra nella descrizione "tag drive the build", ma non sono sicuro che sia il metodo migliore. In particolare, dove vedo che questo ci sta fallendo è se dovessimo integrare la nostra versione di rilascio nel processo di configurazione, sembra che sarebbe retrocesso.

Non solo, ma dove in un tipico processo di gestione dei rilasci arriva la decisione per i nuovi numeri di versione dei componenti? Qualcuno deve decidere quando il componente A va da 2.1.4 a 3.0.0 e se la libreria B deve cambiare da 6.3.2 a 6.3.3 o 6.4.0. Dove vengono memorizzati questi numeri di versione e in quale fase vengono decisi? Attualmente, prendiamo queste decisioni all '"ultimo momento" e sono memorizzate nello script di master building. Lo script di masterizzazione stesso è versionato e contrassegnato con il numero di versione "marketing".

builds versioning release-management release configuration-management

posta Dave Nay 04.08.2011 - 03:23

fonte

5 risposte

Leggi altre domande sui tag builds versioning release-management release configuration-management

Rilevazione di perdite di codice Internet [chiuso] Refactoring di una base di codice MVC esistente per rimuovere la logica aziendale e l'accesso ai dati dai controller

score 1 · Answer 1

Esistono diverse risposte corrette, in base al ciclo di rilascio del prodotto, all'approccio delle patch, ecc.

Nelle aree con cui sto lavorando in questo momento, taggiamo le build RC con un numero intero incrementale. Le build in stile CI non vengono sottoposte alla versione. Non sono sicuro di cosa succede sul lato marketing. : -)

score 1 · Answer 2

Versioning semantico può aiutarti a identificare quando eseguire il bump della versione e su cosa eseguirne il bump.

Alcuni punti chiave:

Le modifiche incompatibili con le versioni precedenti ottengono un bump della versione principale ( 3.2.9 - > 4.0.0 ).
Le aggiunte / le modifiche alle funzionalità compatibili con le versioni precedenti ottengono un bump di versione minore ( 3.2.9 - > 3.3.0 ).
Le correzioni dei bug che non alterano l'API compatibili con le versioni precedenti ottengono un bump della versione a livello di patch ( 3.2.9 - > 3.2.10 ).

score 1 · Answer 3

Il sistema che utilizzo ha un numero di versione del file contenente i numeri di versione maggiore e minore, il mio server CI usa una modifica a questo file per attivare una build di "rilascio". Il server CI aggiunge un numero di build per creare una versione major.minor.build e quindi etichetta il codice utilizzato per quella build.

score 0 · Answer 4

Il modo in cui di solito lavoriamo è quello con un nome significativo in modo da sapere di cosa si tratta e taggare con un numero di versione incrementale come release finale. Un piccolo incremento per una piccola modifica (1.2 - > 1.3) e un incremento maggiore (1.0 - > 2.0) per funzionalità più grandi.

score 0 · Answer 5

Penso che "i tag guidino la build" sia un buon sistema in generale, perché è facile da capire e utilizzare in tutte le fasi del ciclo di sviluppo / test / qa / release. Se stai inserendo un tag nel tuo script di costruzione, stai deliberatamente dicendo che "build x.y" è pronto per il passaggio successivo.

Un numero di build che esce da un processo CI è anche utile, ma potrebbe non acquisire le informazioni sulle modifiche con la stessa grazia - che è più descrittiva: 2.3.5 o 23432?

Indipendentemente dal sistema pubblico di etichettatura che utilizzi, assicurati che le informazioni dettagliate sulla versione siano accessibili per il debug / reporting - sia il più accurato possibile: numero di versione, numero di build CI, numero di revisione del controllo sorgente, data e ora di costruzione - qualunque sia dati necessari per inchiodare esattamente quale build hai a che fare.

Per quanto riguarda i punti decisionali, sì alla fine sono arbitrari e si riducono a qualsiasi cosa funzioni. Il sistema di versioning semantico @Justice cita è fantastico: l'importante è che il team sia in grado di creare un sistema che sia abbastanza facile da usare quando si decide quale numero di versione utilizzare successivamente.