Scelta della corretta gestione dei rilasci e strategia di ramificazione

Question

Scelta della corretta gestione dei rilasci e strategia di ramificazione

#1 da (2 voti)

0

Sto lavorando a un progetto in cui dobbiamo utilizzare SVN come repository di origine e dobbiamo identificare una strategia di ramificazione. Sono a conoscenza del ramo per versione & ramo per strategie di funzionalità in una certa misura, ma non sono un esperto e non sono sicuro di quale o se sia o meno adatto alle nostre esigenze.

Abbiamo 2 ambienti, produzione e pre-produzione. Una volta rilasciata una funzionalità, questa viene prima distribuita in pre-produzione e testata rigorosamente prima di passare alla produzione. Quindi l'ambiente di produzione è in genere un paio di versioni dietro l'ultima versione del codice. Potremmo ricevere bug sia sulla produzione che sulla preproduzione simultaneamente. Se un bug è riportato in produzione, è necessario fornire la correzione sulla sua versione attuale, mentre se in fase di pre-produzione deve essere consegnata su quella particolare versione più recente.

Qualcuno ha avuto requisiti ed esperienza simili nel gestire una simile situazione. Sarà bene comprendere le soluzioni candidate con pro e contro di ciascuna.

version-control branching svn release-management

posta Alok Save 18.10.2014 - 20:38

fonte

1 risposta

Leggi altre domande sui tag version-control branching svn release-management

Scenari per la libreria che verranno utilizzati dagli sviluppatori Quali metadati contengono i file? [chiuso]

score 2 · Accepted Answer

Sembra che usiamo simili procedure di staging / preproduzione nella nostra azienda.

La nostra strategia di ramificazione è (usiamo Git):

master contiene versioni, contrassegnate dai tag (1.0.0, 1.0.1, ...)
piccoli bugfix (1 commit) vai direttamente sul master
le prossime versioni vanno a rami come "devel-x.y.z"
e le correzioni più grandi sono diramate dai rami della versione ("feature-foo" in cima a "devel-x.y.z"), quindi nessun passo sulle dita degli altri

I project manager decidono quali correzioni / caratteristiche devono passare alla prossima release, quindi uniamo tutti i branch selezionati in master e distribuiamo la prossima release in modo semi-automatico con il plugin di rilascio di Maven. Facciamo spesso rebases per mantenere la cronologia del repository il più lineare possibile.

Quindi, in breve, eseguiamo entrambe le operazioni branch-by-release (perché supportiamo diverse versioni dei nostri prodotti) e branch-by-feature / bugfix. Non c'è contraddizione.

ramo-by-release

Pro:

possiamo rifiutare o saltare un rilascio senza toccare il master perché uniamo i rami delle caratteristiche nei rami di rilascio, non nel master
vedi la versione su cui stai lavorando

Contro: nessuno che vedo

ramo-by-funzione

Pro:

non calpesti le dita degli altri: basta unire quando hai finito
puoi tenere traccia dell'avanzamento di ogni funzione (usiamo Jira)
puoi tenere traccia delle modifiche apportate a ciascuna funzione in passato (denominiamo i rami dopo i problemi di Jira e li lasciamo dopo l'unione e anche il prefisso del messaggio di commit con il nome del problema)

Contro:

diventa caotico se ci sono un sacco di funzioni che vanno nello stesso momento e unisci qualcosa nel mezzo. È un po 'il fatto che puoi avere tutte le filiali che vuoi - non sei obbligato a implementare le funzionalità in modo sequenziale. Forse non è proprio un contrario, ma altrimenti non sarebbe possibile

SVN

Da quando lo hai menzionato ... SVN non funzionerà per quello che ho descritto. Ho solo un po 'di esperienza con esso, ed è stato doloroso. A proposito di ramificazione, i rami SVN sono pesanti e lenti e non è possibile effettuare il commit offline. Non sono un odiatore, mancano solo molte funzionalità di cui ho bisogno. Raccomando Git, ma potresti anche guardare Mercurial o altri DVCS.