Creazione di versioni in consegna continua

Question

Ho alcune domande concrete sul controllo delle versioni in Consegna continua. Penso di capire il flusso di lavoro globale che più o meno è questo:

1) Code 
2) Push to version Control 
3) Continuous Integration (unit, integration and end-to-end auto testing) 
4) Artifacts deployment 

E il controllo delle versioni? Come gestisci le versioni di build?

Diciamo che stiamo lavorando a un progetto basato su Maven con versioning semantico: major.minor.build.

Quando lo sviluppatore esegue il commit delle modifiche a VCS e il server CI esegue una compilazione, il server CI deve incrementare la versione di build e creare un tag in VCS?

Questa versione di build è presente nel codice sorgente? In tal caso, dopo ogni push su VCS, lo sviluppatore dovrebbe aggiornare il progetto, poiché il server CI ha eseguito il commit delle modifiche (incremento della versione) sul progetto.

Sono un po 'confuso e mi piacerebbe capire il flusso di lavoro del CD in modo pratico.

Answer 1

In generale si dovrebbe avere:

1. Un numero di versione gestita manualmente.
2. Qualsiasi numero di numeri di "riferimento".

Il primo punto è cruciale se ti interessa il semere o nel caso in cui devi fornire informazioni di compatibilità per altri strumenti/librerie. Solo tu sei in grado di dire se una nuova "release" rompe qualcosa: il sistema di indicazione più popolare sta seguendo le regole di versioning del semver.

Il secondo punto ("numero di riferimento") potrebbe o non potrebbe essere importante per voi. Di solito non è necessario più di uno, il numero di versione della build CI/CD (ogni popolare servizio CI/CD ha un ID di versione della build che si riferisce a quella specifica "build"). Il punto di questo numero è che è possibile controllare rapidamente i registri/log CI/CD relativi a un artefatto se necessario.

Come unire le due (o più) parti?

Non è raro avere numeri "versione" e "build" separati. In effetti ogni progetto iOS ha quello di default. In tal caso, il numero di "versione" viene gestito manualmente e un numero di "build" separato gestito automaticamente. Il numero di build può essere in nome del manufatto, oppure può essere stampato quando qualcuno recupera le informazioni --version in caso di un binario (es: $ brew info ->0.9.5 (git revision 18c48; last commit 2015-11-02)

In alternativa è possibile aggiungere nuovi componenti semver (x.x.x.BUILDNUM), l'uso l'ultimo componente di semere (x.x.BUILDNUM - Non lo consiglierei se hai un numero incrementale BUILDNUM) o semplicemente includi il numero "build" nel nome del manufatto

Queste sono tutte le possibilità, avrai per scegliere il migliore per il tuo caso, devi definire il significato di questi numeri e decidere dove deve essere presentato il numero (ad esempio dovrebbe far parte di unoChiamatao dovrebbe essere solo una parte del nome file).

: per riflettere sulla domanda "deve il server CI incrementare la versione di build e creare un tag in VCS?" - Non lo consiglierei mai. Anche un server CI può avere problemi, non si dovrebbe mai modificare il codice da un processo CI. Sovrascrittura accidentale (ad es.forza spingendo) qualcosa può essere veramente pericoloso. Ecco perché è meglio usare semplicemente il numero di build esposto dal servizio CI/CD.