Convenzioni per il controllo di revisione con Maven / Jenkins

Question

Convenzioni per il controllo di revisione con Maven / Jenkins

#1 da (2 voti)

3

Per un progetto software su cui sto lavorando, abbiamo un 'dev = > QA = > metodologia di produzione. Cioè, creiamo un release candidate (implementato in Artifactory), lo diamo al QA (deploy per i sistemi QA e un backend / application server QA) che impiega circa una settimana per guardarlo, e se è ok, facciamo una versione di produzione.

Ora provengo da uno sfondo app nativo / incorporato, non tanto da Java / sistemi / CI. E sono abituato al controllo delle revisioni organizzato con tutte le versioni taggate (in questo caso, i tag di rilascio di produzione sono sempre solo copie di un tag RC).

 branches/1.2
 branches/1.3
 tags/1.2.0-rc
 tags/1.2.0
 tags/1.3.0-rc
 tags/1.3.1-rc
 tags/1.3.1

Tuttavia, diversi membri del team affermano che questo non funziona bene con Maven (e forse anche con Jenkins). Invece, suggeriscono:

 branches/1.2.0-rc
 branches/1.3.0-rc
 branches/1.3.1-rc
 tags/1.2.0
 tags/1.3.1

Sto sostenendo che un candidato al rilascio non dovrebbe essere una succursale, dato che abbiamo bisogno di consegnare un'entità nota al QA (al contrario di una situazione di integrazione / distribuzione continua in cui potremmo tagliare il rilascio di produzione direttamente dalla nostra linea di sviluppo senza aspettare per QA). Il fatto che diversi sviluppatori stiano controllando il codice nel ramo RC, e c'è poco controllo intorno ad esso, ha causato problemi.

Qualcuno potrebbe spiegare se c'è qualcosa riguardo a Maven o Jenkins che renderebbe la seconda strada "migliore"? C'è qualcosa che rende la prima via più difficile da implementare?

svn java maven jenkins

posta BobIsNotMyName 21.04.2015 - 17:26

fonte

1 risposta

Leggi altre domande sui tag svn java maven jenkins

Laravel 5 Multi-App L'obiettivo di 3 dipendenze per classe è sempre raggiungibile?

score 2 · Answer 1

Non vedo proprio come Maven o Jenkins si sarebbero riferiti a questo! Ma mi piacerebbe dare una distinzione generale a questo. (Anche se questa è una domanda piuttosto vecchia ...)

Un ramo è qualcosa su cui lavori.

Un tag è solo un nome.

Quindi, nel caso in cui il tuo lavoro sia un RC, potresti comunque aver bisogno di correzioni o miglioramenti, per questo continui a lavorarci e disponendo di un ramo.

Una volta che hai finito e il tuo lavoro è stato rilasciato, mantieni un puntatore permanente a quella versione (il tag).

Quindi preferirei anche la versione 2! Lo chiamerei il modo tipico. E forse è anche per questo che si integra meglio con Jenkins - perché finché è ancora in corso il lavoro e potresti dover ridistribuire, è meglio avere un ramo (come fonte di distribuzione - almeno lavoriamo in questo modo con Bamboo).