git, maven e jenkins - workflow di versioning, dev e release builds

Question

git, maven e jenkins - workflow di versioning, dev e release builds

#1 da (3 voti)
#2 da (1 voti)

12

Qual è il modo migliore 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 le risorse di rilascio avessero versioni come 1.5.2 e le versioni di sviluppo sarebbero semplicemente 0.0.1-SNAPSHOT. Mi piacerebbe non dover avere 2 diversi file pom.xml.

Ho esaminato i profili, ma non sembrano in grado di modificare le versioni degli artefatti. Un modo in cui ho guardato potrebbe aggiungere un "qualificatore" ai build di test. Ovviamente potrei semplicemente rinominare il file, perché le informazioni sull'artefatto reale su questo non sono importanti, perché l'app è indipendente.

Quale sarebbe il modo migliore per farlo? O come faresti questo?

git versioning workflows maven jenkins

posta varesa 29.03.2012 - 19:38

fonte

2 risposte

1

Ripensa il tuo approccio.

È molto comune usare per es. 1.4.2 per una versione di rilascio e poi 1.4.3-SNAPSHOT per lo sviluppo al successivo.

Quando è necessario maintain release 1.4.2 THEN lo si dirama dal commit che ha originato il tuo artefatto 1.4.2.

Poi comunichi a Jenkins la posizione del tuo repository e il nome del ramo, dando come risultato 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 l'artefatto effettivo e un altro pom.xml per creare i bit effettivi da inviare al cliente.

risposta data 03.04.2012 - 22:12

fonte

Leggi altre domande sui tag git versioning workflows maven jenkins

Git workflow / practice per un piccolo progetto (diagramma di flusso in png) Quali sono gli svantaggi dell'uso / scrittura di un provider di abbonamento personalizzato .Net?

score 3 · Accepted Answer

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

Rilascio

Immagino che potresti fare qualcosa come unire un codice pronto per la produzione dal ramo dev al ramo di rilascio, quindi eseguire una versione Maven (tramite Jenkins o manualmente). Questo porta automaticamente i numeri di versione 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 porta automaticamente la tua copia di lavoro su 1.4.8-SNAPSHOT.

Aggiornamento baseline (facoltativo)

Se non si sta già utilizzando il trunk (o il ramo di base, ecc.) come luogo per le proprie versioni, è necessario aggiornare il trunk non appena si completa un rilascio. Ciò significa che anche i numeri di versione vengono aggiornati. Questo passaggio potrebbe essere discutibile se si considera il ramo di rilascio come base di riferimento.

Riunione 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 rilasciare il ramo, a seconda dell'implementazione) fino al ramo di sviluppo. Questo è importante nel tuo caso perché significa che le modifiche al pom che si sono verificate durante il processo di rilascio, che hanno cambiato la versione in 1.4.8-SNAPSHOT, sono portate a questo ramo.

Basandomi sulla lettura che ho fatto (oltre ai processi con la mia organizzazione), questo sembra essere un uso abbastanza standard ed efficace delle versioni e delle istantanee di Maven, e invece di mantenere i numeri di versione completamente disconnessi su rami diversi, è facile dire che qualsiasi build 1.4.7-SNAPSHOT era in effetti un immediato predecessore della versione 1.4.7. Sono imparentati. Direi che se non stai unendo avanti e indietro tra questi rami, stai facendo sia la versione di SCM che quella di Maven sbagliate, e ti stai mettendo a rischio di sviluppare codice che non corrisponde alla produzione, reintroduce bug alla produzione, ecc.