git, maven e jenkins - il flusso di lavoro di versioning, dev e release build

Qual è il modo preferito di fare quanto segue con git, maven e jenkins:

Sto sviluppando un'applicazione, che vorrei mantenere i rami "dev" e "release". Vorrei che Jenkins costruisse entrambi. Potrebbe essere che gli artefatti di rilascio abbiano versioni come 1.5.2 e gli sviluppatori di sviluppo siano solo 0.0.1-SNAPSHOTs. Vorrei non avere 2 file pom.xml diversi.

Ho esaminato i profili, ma non sembrano essere in grado di cambiare le versioni degli artefatti. Un modo in cui ho guardato potrebbe essere l'aggiunta di un "qualificatore" ai test-build. Ovviamente potrei semplicemente rinominare il file, perché le informazioni sul vero artefatto su questo non sono importanti, perché l'app è autonoma.

Quale sarebbe il modo preferito per farlo? O come lo faresti?

Immagino che ci dovrebbe essere una relazione intrinseca tra questi rami che dovrebbe affrontare il problema dei numeri di versione.

rilasciando

Immagino che potresti fare qualcosa come unire il codice pronto per la produzione dal ramo dev al ramo di rilascio, quindi eseguire una versione di Maven (via Jenkins o manualmente). In questo modo i numeri di versione vengono automaticamente spostati alla build successiva. Quindi unisci il codice 1.4.7-SNAPSHOT a questo ramo, esegui il rilascio e taglia la versione 1.4.7 e Maven lancia automaticamente la tua copia di lavoro su 1.4.8-SNAPSHOT.

Aggiornamento della linea di base (opzionale)

Se non stai già utilizzando il trunk (o il ramo di base, ecc.) Come posizione per le tue versioni, dovresti aggiornare il trunk non appena completi una versione. Questo significa che anche i tuoi numeri di versione vengono aggiornati. Questo passaggio potrebbe essere controverso se si considera semplicemente il ramo di rilascio come base.

Up-merge da Baseline a Dev Branch

È essenziale che il tuo ramo di sviluppo rimanga aggiornato con il codice di produzione effettivo . È necessario unire il codice dalla linea di base (o dal ramo di rilascio, a seconda dell'implementazione) fino al ramo di sviluppo. Questo è importante nel tuo caso perché significa che i cambiamenti pom verificatisi durante il processo di rilascio, che hanno cambiato la versione in 1.4.8-SNAPSHOT, vengono portati in questo ramo.

In base alla lettura che ho fatto (così come ai processi nella mia organizzazione), questo sembra essere un uso abbastanza standard ed efficace delle versioni e delle istantanee di Maven, e piuttosto che mantenere numeri di versione completamente disconnessi su rami diversi, è facile dire che qualsiasi build 1.4.7-SNAPSHOT era in effetti un predecessore immediato della versione 1.4.7. Sono imparentati. Vorrei arrivare al punto di dire che se non ti stai unendo avanti e indietro tra questi rami, stai sbagliando sia la versione di SCM che quella di Maven e ti stai mettendo a rischio di sviluppare codice che non corrisponde alla produzione , reintroduce i bug nella produzione, ecc.

Ripensa al tuo approccio.

È molto comune usare ad es. 1.4.2 per una versione di rilascio e quindi 1.4.3-SNAPSHOT per lo sviluppo a quello successivo.

Quando è necessario mantenere la versione 1.4.2 POI diramarla dal commit che ha originato il tuo artefatto 1.4.2.

Quindi dici a Jenkins la posizione del tuo repository e il nome del ramo, risultante in un set di file che viene estratto, e poi dici a Jenkins di usare Maven sul tuo progetto per costruirlo.

Nota: ho scoperto che è molto utile utilizzare un singolo pom.xml per creare il vero artefatto e un altro pom.xml per creare i bit effettivi da inviare al cliente.