Rilascio degli strumenti di gestione con DVCS (Mercurial)

3

Il mio team di sviluppo sta migrando da SVN a Mercurial. Dopo aver ricercato le best practice DVCS, è stato suggerito che sviluppiamo contro feature branch della linea principale del repository, li testiamo separatamente, quindi selezioniamo le funzionalità che vogliamo in ogni release, prima di unire i rami selezionati nella mainline e infine rilasciandoli.

Domanda : quello che sto cercando sono raccomandazioni per una sorta di strumento software che renderà più semplice il mio ruolo di "gestore di rilascio del software", in quanto mi consentirà di controllare (cherry- selezionare) quali rami (funzionalità, correzioni di errori, ecc.) vengono uniti (usando Git, o Mercurial) in cui rilasciare il software (in ogni ambiente) e essere in grado di produrre l'artefatto di distribuzione binaria.

Le nostre applicazioni sono principalmente applicazioni Web Java, con una manciata di applicazioni Java e progetti creati utilizzando Maven (v2).

Mi sono guardato intorno per gli strumenti di gestione del rilascio, ma non c'è niente che risponda al vero.

NB : non tutte le modifiche vengono rilasciate non appena vengono completate e passano QA: alcune devono essere rilasciate in un secondo momento, come parte di un rilascio a tema

Cose finora rimosse (basate su raccomandazioni in domande simili, in altri thread SE):

  1. Trac (sembra essere solo materiale di tipo PM, che abbiamo già con l'offerta di Atlassian OnDemand)
  2. Jenkins (più altri strumenti CI) - sto cercando qualcosa per gestire i miei rilasci, piuttosto che uno strumento CI (abbiamo usato Jenkins nel passato).
  3. Mercurial Patch-Queues - Potrei averne bisogno, ma stavo cercando una sorta di interfaccia "migliore" per aiutarmi a gestirlo.
  4. Offerte ERP - TBH, non ho cercato troppo in questa opzione, poiché la mia sensazione iniziale era che erano troppo pesanti.
  5. BuildMaster , di Inedo - Questa è stata la partita più vicina, di gran lunga, ma non era abbastanza adatta a causa della sua mancanza di prelievo di VCS / fusione di funzionalità. Direi comunque che si tratta di un software molto carino, e lo consiglierei, se si adatta al tuo caso d'uso, e ha un prezzo ragionevole, anche per uso aziendale.

Attualmente sto valutando i seguenti strumenti:

  1. Funzione Bitbucket Gestione delle filiali (poiché utilizziamo Bitbucket per i nostri progetti, sembra prudente valutare il loro approccio)

Dato che DVCS è nuovo per noi, queste cose potrebbero essere state respinte prematuramente, quindi sentitevi liberi di rieducarmi. :)

    
posta Crollster 14.03.2013 - 06:17
fonte

3 risposte

3

Questo potrebbe non essere automatico come vuoi ma TortoiseHG ti permetterà di selezionare quale ramo vuoi unire e indicare che il ramo è unito. Il rovescio della medaglia è che non penso che ci sia una modalità TortoiseHG in cui puoi vedere quali rami sono ancora immersi. Dovresti scorrere la porzione del grafico del riquadro della cronologia per vedere cosa è cosa.

Modifica: Dalla riga di comando hg head -t mostrerà tutte le diramazioni che non hanno figli e quindi non si fondono.

Sto sperimentando il filtro set di revisione in TortoiseHG per vedere se è possibile duplicare il risultato all'interno di THG ma ancora senza fortuna: - (

    
risposta data 14.03.2013 - 16:13
fonte
2

Il problema che vedo qui è più di uno di gestione delle fonti: quello che devi veramente fare è aggiungere un concetto di un ramo di rilascio che è dove puoi selezionare i rami di funzionalità da integrare e testare. Qualsiasi altro strumento che si desidera utilizzare può quindi essere indirizzato a detto ramo di rilascio senza avere molto lavoro offline.

Un'altra variante di questo concetto sarebbe l'uso di una fork e l'estrazione di richieste per estrarre questa roba in un repository "release" pulito per ogni versione. Non posso affermare di averlo fatto in questo modo però.

    
risposta data 22.03.2013 - 19:24
fonte
0

Mentre vedo come costruisci il tuo flusso di lavoro per il rilascio (è tag nel ramo predefinito o branch-per-release separato speciale) e topologia del tuo repository (le versioni successive ereditano tutte le funzionalità da versioni precedenti o no), proverò solo alcune iterazioni :

Come già notato, penso che TortoiseHG sarà un buon strumento principale

Se le funzionalità unite in precedenza ereditate nelle versioni successive e i nomi dei rami seguono <some pattern> e tutti i rami sono aperti (differiscono solo la condizione "già unita o non ancora") e sono i tag che puoi utilizzare in TortoiseHG i seguenti giri di filtro (ma per produrre elenchi CLI è meglio, dal mio POV - Revset con template darà un buon output)

  • Non uniti rami delle caratteristiche

branch(re:some pattern) and not ancestors(tag())

(se la versione non è tag, ma ramo speciale - sostituisci tag() con branch(release-branchname)

  • Diramazioni sui rami (versione semplificata del revset precedente)

head() - ancestors(tag()) o heads(all())

(potrebbe essere necessario escludere i capi di alcuni rami con nome)

  • Unita nel ramo dall'ultima versione (tag nel ramo)

p2(last(tag()):: & merge())

ma nella CLI sarà più bello con alcuni template aggiuntivi

hg log -r "p2(last(tag()):: & merge())" --template "{branch}\n"

    
risposta data 22.04.2013 - 11:07
fonte

Leggi altre domande sui tag