È buona norma memorizzare i numeri di versione del software in VCS?

Question

È buona norma memorizzare i numeri di versione del software in VCS?

#1 da (25 voti)
#2 da (8 voti)

19

Una versione del prodotto, ad esempio v1.0.0.100 , rappresenta non solo una versione di produzione univoca del software, ma aiuta a identificare i set di funzionalità e le fasi di aggiornamento rapido per il suddetto prodotto. In questo momento vedo due modi per mantenere il pacchetto finale / build / versione binaria di un prodotto:

Controllo versione. Un file da qualche parte memorizza il numero di versione. Il server di build CI (Continuous Integration) avrà uno script per creare il software che utilizza questo numero di versione verificata per applicarlo a tutte le aree del software necessarie (file binari, pacchetti di installazione, pagine di aiuto, documentazione, ecc.)
Ambiente e / o parametri di costruzione. Questi sono mantenuti al di fuori del controllo della versione (cioè non sono legati allo snapshot / tag / ramo). Gli script di compilazione distribuiscono e usano il numero allo stesso modo, tuttavia hanno solo ottenere il valore in modo diverso (è fornito per lo script di compilazione, invece di far sapere allo script dove per ottenerlo relativamente all'albero dei sorgenti).

Il problema con il primo approccio è che può complicare le fusioni tra i rami principali. Se mantieni ancora 2 versioni parallele dello stesso software, risolvi i conflitti durante l'unione tra le due linee principali se la versione è stata modificata su entrambi dall'ultima unione.

Il problema con il secondo approccio è la riconciliazione. Quando torni ad una versione 1 anno fa, ti baserai esclusivamente sulle informazioni del tag per identificare il suo numero di versione.

In entrambi i casi, potrebbero esserci alcuni aspetti del numero di versione che non sono noti prima della build dell'elemento della configurazione. Ad esempio, una build CI può inserire un quarto componente in modo programmatico che è in realtà il numero di build automatico (ad esempio 140 ° build sul ramo). Potrebbe anche essere un numero di revisione in VCS.

Qual è il modo migliore per tenere il passo con il numero di versione del software? Le parti "conosciute" devono essere sempre mantenute in VCS? E se sì, i conflitti tra le filiali principali sono un problema?

In questo momento manteniamo il nostro numero di versione tramite parametri specificati e mantenuti nel piano di build CI (Atlassian Bamboo). Dobbiamo fare attenzione prima di unire al nostro ramo master che i numeri di versione sono impostati correttamente prima della creazione della build CI . Per quanto riguarda il flusso di lavoro Gitflow, ritengo che se il numero di versione fosse tracciato nel controllo del codice sorgente, potremmo garantire che sia configurato correttamente quando creiamo il nostro ramo release in preparazione del rilascio. Il QA eseguirà il test di integrazione finale / fumo / regressione su questo ramo e al momento del signoff, si verificherà un'unione con master che segnala l'impegno a rilasciare.

version-control versioning release-management continuous-integration continuous-delivery

posta void.pointer 17.08.2015 - 22:39

fonte

2 risposte

8

Sì. È buona norma conservare la maggior parte del numero di versione in vcs. Se consideriamo la versione semantica di semver.org dove abbiamo major.minor.patch.build i primi tre devono vivere in vcs. L'ultimo può essere un numero incrementale dal tuo server di build usato per tornare indietro allo specifico commit da cui è fatto un binario.

Per facilitare questo in .NET abbiamo creato un piccolo exe della linea cmd che è impegnato a git. Con un evento di pre-build, raccoglie il numero di build che teamcity ha taggato durante la compilazione. Questo strumento della linea cmd genera automaticamente una classe con una costante contenente il numero di build. Il resto del numero di versione: major.minor.patch è solo una costante normale in un altro file. Questi due file condivisi sono inclusi in ogni assembly in una soluzione come collegamento (alt + maiusc + trascina).

Questo approccio è abbastanza potente da consentire a teamcity di costruire e testare il nostro codice. Spingi in blu e fai in modo che Kudu lo ricostruisca ma con il numero di build di TeamCity come versione della DLL.

risposta data 18.08.2015 - 07:17

fonte

Leggi altre domande sui tag version-control versioning release-management continuous-integration continuous-delivery

Perché dovrei usare Angolare? Come posso iniziare i test in una campagna di test? [chiuso]

score 25 · Accepted Answer

Personalmente, scelgo l'opzione 3: mantieni le informazioni sulla versione in metadati di VCS, in particolare, tag.

Git rende molto facile farlo, perché c'è un comando git describe , che può essere univoco descrivere un commit basato su un tag. Ecco come funziona:

Se il commit corrente è taggato, invia il nome del tag.
Altrimenti, riporta indietro la cronologia finché non trovi un tag e quindi generi una descrizione nel seguente formato: <tag>-<number of commits since the tag>-g<abbreviated commit hash> .
Se ci sono modifiche non vincolanti nella scala di lavoro, aggiungi -dirty .

Quindi, se stai facendo una versione di rilascio e il commit è taggato con 1.2.3 , verrà visualizzato 1.2.3 . Se stai lavorando su 1.2.4 e hai commesso 4 commit dalla 1.2.3, e hai modifiche non accettate nell'albero, verrà visualizzato 1.2.3-4-gdeadbee-dirty .

Questo è garantito per essere univoco e monotono, oltre che leggibile dall'uomo, e quindi può essere usato direttamente come una stringa di versione. L'unica cosa che devi assicurare è una convenzione di denominazione appropriata per i tag.