Per integrare le versioni di git come numeri di build o no?

Usiamo git descrive con i tag di versione. Il flusso è fondamentalmente:

• crea un tag per la versione su cui stiamo lavorando (ad esempio v1.1.2)
• ogni build eseguita git describe
• quando spediamo, usa il nome del tag

git describe fornisce il nome del tag, il numero di commit dal tag e l'hash del tag. Un esempio di tag è:

v1.1.2-6-a3b27gae

Questo ha il vantaggio che gli sviluppatori ottengono gli hash, quindi se qualcosa si rompe tra le build, lo sviluppatore può facilmente diffare le modifiche. È anche stupido da gestire; fai in modo che il tuo team di piombo crei e spinga il tag su un nuovo ramo di bugfix e il tuo sistema di compilazione si occupi del resto.

Spogliamo l'hash (e il numero di build) perché rende più facile agli utenti la comprensione dei nostri numeri di versione. Scopriamo che questo ci offre il meglio di entrambi i mondi, pur continuando a fornire informazioni sufficientemente pertinenti durante la progettazione di un rilascio.

Al momento, abbiamo una versione leggermente più complicata di questo, ma l'idea rimane.

Prima eravamo un negozio SVN, quindi questa matematica era facile: il numero di build era il rev SVN ed era così. Abbiamo cercato di andare avanti quando abbiamo iniziato a passare a DCVSes e abbiamo riscontrato che non funzionava per alcuni motivi.

Innanzitutto, chissà se la rev 69bc333bc8d8 è precedente, successiva o concomitante con rev 25b0f0d1052c? C'è molto poco contesto rispetto al sistema SVN quando almeno sapevi che 101 era dopo 100. In secondo luogo, la natura del controllo sorgente DCVS rende le cose non lineari in molti modi quando le build successive potrebbero non far avanzare la stessa palla.

Alla fine abbiamo deciso di utilizzare un server di build per distribuire i numeri di build alle cose poiché aveva la visibilità e la capacità di gestirle correttamente.

Collego direttamente l'output di git status, log e diff nell'eseguibile. Poi c'è un'opzione per stamparlo. Il vantaggio è che non solo sei in grado di capire da quale ramo è stato creato il tuo binario, ma anche quali modifiche al codice sorgente sono incluse. Per favore guarda:

link

Dovresti essere in grado di utilizzare questi 3 file per creare la tua personale cosa della lib di stato SCM.

Uso il seguente schema per un sistema di compilazione di Visual Studio di una DLL C # per generare automaticamente numeri di versione (Abbiamo storicamente avuto problemi con le distribuzioni non eseguite correttamente, quindi era necessario un modo pulito per garantire l'implementazione della versione corretta) .

• Maggiore: hard coded 1, in genere determinato dal lato aziendale
• Minore: hard codificato 0, in genere determinato dal lato aziendale
• Revisione - Numero di giorni dal 1 ° gennaio 2010 (o qualsiasi altra data di inizio arbitraria)
• Build: metà del numero di secondi da mezzanotte (poiché è un numero senza segno a 16 bit)

Nota che questo presuppone che tu abbia 2 numeri fungibili a 16 bit senza segno con cui giocare. È anche possibile creare un sistema equivalente che utilizza numeri più piccoli.

Si noti inoltre che i campi non numerici possono essere utili se è possibile allegarli come metadati. Ad esempio aggiungendo il numero di versione di git come numero della versione informativa.

Raccomando l'uso di Autorevisione .

Puoi ottenere risultati in vari formati, ad esempio una intestazione di stile c .

Ci sono anche alcuni esempi (nella directory dei contrib) di come puoi collegare le cose in modo che, indipendentemente da chi sta costruendo e come lo stanno facendo, otterranno sempre le stesse informazioni sulla versione, anche se stanno costruendo da un tarball.

Inoltre, poiché oltre a git Autorevision funziona con svn e hg rende più facile passare da svn senza dover cambiare troppo dopo averlo impostato.