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

Un collega e io a turno abbiamo discusso / discusso dei problemi / meriti dell'integrazione di una versione derivata dall'attuale repository git nel nostro codice ogni volta che viene compilato.

Pensiamo che i meriti includano:

• Non è necessario preoccuparsi dell'errore umano nell'aggiornamento di un numero di versione
• Tracciabilità tra ciò che troviamo in un dispositivo e il codice sorgente da cui è derivato

I problemi che sono sorti (per noi) includono:

• I sistemi di generazione derivati ​​dall'IDE (ad es. MPLABX) possono rendere difficile capire dove inserire questi tipi di ganci (e alla fine può sembrare piuttosto scadente)
• Più lavoro per integrarlo effettivamente negli script di compilazione / makefile
• L'accoppiamento a un particolare approccio di compilazione (ad esempio cosa succede se una persona costruisce con XCode e l'altro MPLABX) può creare sorprese a valle

Quindi siamo curiosi di sapere dove altri sono arrivati ​​a questo dibattito. È davvero facile che la discussione diventi aneddotica. Ci sono molte persone là fuori che insistono sull'automazione end-to-end, appendono la quantità di lavoro iniziale e l'accoppiamento che crea. E ci sono molti altri dall'altra parte del dibattito, che fanno solo la cosa più semplice che funziona e convive con i rischi.

Esiste una risposta motivata su quale lato è meglio atterrare?

Usiamo git descritto con tag di versione. Il flusso è sostanzialmente:

• creare tag per la versione su cui stiamo lavorando (ad es. v1.1.2)
• ogni serie di build git describe
• quando spediamo, usa il nome del tag

git describefornisce il nome del tag, il numero di commit dal tag e l'hash del tag. Un tag di esempio è simile a:

v1.1.2-6-a3b27gae

Questo ha il vantaggio che gli sviluppatori ottengono hash, quindi se qualcosa si rompe tra le build, lo sviluppatore può facilmente diff le modifiche. È anche stupido semplice da gestire; chiedi solo al tuo team di creare e spingere il tag su un nuovo ramo bugfix e il tuo sistema di compilazione si occuperà del resto.

Eliminiamo l'hash (e costruiamo il numero) perché semplifica la comprensione da parte degli utenti dei nostri numeri di versione. Scopriamo che questo ci dà il meglio di entrambi i mondi, pur fornendo abbastanza informazioni rilevanti durante la progettazione di una versione.

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

Un tempo eravamo un negozio SVN, quindi questa matematica era semplice: il numero di build era il numero di giri SVN e basta. Abbiamo provato a farlo andare avanti quando abbiamo iniziato a passare a DCVSes e abbiamo scoperto che falliva per alcuni motivi.

Primo, chissà se rev 69bc333bc8d8 è prima, dopo o in concomitanza con rev 25b0f0d1052c? C'è un contesto molto piccolo rispetto al sistema SVN quando almeno sapevi che 101 era dopo 100. In secondo luogo, la natura del controllo del sorgente DCVS rende le cose non lineari in molti modi quando 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 giusta visibilità e capacità di gestirlo.

Uso il seguente schema per un sistema di compilazione di Visual Studio di una DLL C # per generare automaticamente i numeri di versione (storicamente abbiamo avuto problemi con le distribuzioni non eseguite correttamente, quindi era necessario un modo chiaro per garantire la distribuzione della versione corretta).

• Maggiore: codice 1 rigido, in genere determinato dal lato aziendale
• Minore: hard coded 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 dalla 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. Si potrebbe anche 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 git come numero di versione informativa.

Sto collegando direttamente l'output di stato git, log e diff nell'eseguibile. Quindi 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 non incluse sono incluse. Perfavore guarda:

https://github.com/colding/MercuryFIX/tree/master/stdlib/scm_state

Dovresti essere in grado di usare quei 3 file per creare il tuo stato lib SCM stato.

Consiglierei l'uso di Autorevision .

È possibile ottenere output in diversi formati, ad esempio un'intestazione di stile c .

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

Inoltre, poiché oltre a gitAutorevision funziona svne hgrende più semplice il passaggio da svn senza dover cambiare troppo dopo averlo impostato.