Un buon flusso di lavoro per iniziare con la consegna continua?

0

Il mio team sta affrontando un paio di nuove sfide nel prossimo futuro, poiché inizieremo a sviluppare un paio di (micro) servizi che verranno eseguiti in un ambiente cloud. Pertanto, vogliamo stabilire un flusso di lavoro di consegna continua (e magari passare all'installazione continua un giorno).

Attualmente stiamo sviluppando un'applicazione basata su Eclipse RCP insieme ad alcune applicazioni web (servlet Java). Dopo aver fornito gli artefatti rilasciati, il cliente è responsabile del funzionamento. Rilasciamo 3-4 volte all'anno con rilasci di manutenzione aggiuntivi quando necessario. Utilizziamo git con un flusso di lavoro basato su trunk (all-on-master) e rami di manutenzione aggiuntivi. Gli sviluppatori si impegnano almeno una volta al giorno, che attiva una build sul nostro server CI. Il master può diventare instabile una volta ogni tanto e contiene molte funzioni incomplete (e non nascoste!).

Dato che saremo responsabili per il funzionamento dei nostri servizi, il nostro obiettivo principale è una linea principale sempre pronta per il rilascio, in modo da reagire rapidamente in caso di problemi. Quindi abbiamo pensato di estendere il nostro flusso di lavoro git con i rami delle funzionalità. Ma abbiamo presto abbandonato questa idea a causa di diversi motivi (ad esempio, conflitti di fusione con caratteristiche / storie che richiedono 1-2 settimane, nessun feedback CI soddisfacente, ecc.) [1-2]. Quindi abbiamo deciso di mantenere il nostro flusso di lavoro on-the-master (senza rami di manutenzione) e di lavorare con modelli come interruttori di funzioni, branch-by-astrat- ting, ecc. [3-4]. Tuttavia, non abbiamo molta esperienza con questi modelli e pensiamo anche che non sia banale mantenere sempre la linea principale pulita al 100% e pronta per il rilascio. Così abbiamo deciso di avere un ulteriore ramo di sviluppo che viene unito di nuovo quando necessario o almeno alla fine di uno sprint. Questo assicura che il ramo master rimanga davvero pronto per la release, mentre il ramo di sviluppo non deve essere (ma ovviamente dovrebbe essere).

Dopochequestoflussodilavoroèstatostabilito,vogliamospostarciunpo'dipiùeintrodurreunasortadibranchdifunzionalitàabrevedurata.Amioavviso,iproblemiprincipaliconlefeaturebranchderivanodallaloroduratapiuttostolunga.Immaginadiavereunauserstorycompostadadiversesottoattività.Un'attivitàrichiedecirca1giornodilavoro.Quandol'attivitàèterminata,lemodifichevengonoinviateallalineaprincipalecheattivaunacompilazionecompletasulserverdibuild.QuestoèCIcomeloconosciamo,giusto?Tuttavia,ilmiocommitpuòancoraportareaunalineaprincipaleinstabile.Naturalmentepossoeseguiretuttiitestunitarilocalmente,adesempio,mailbuildserverpotrebbeeseguiretestaggiuntiviocontrollarealtremetrichediqualitàchenonvoglioeseguirelocalmente.Quindisarebbebelloavereunafilialededicataecostruireunlavoroperilmiocompito.Ciòmiconsentediverificareeverificarelemiemodificheprimadiinviarleallalineaprincipale.Quindiprendounasottoattivitàsucuilavorare,eautomaticamenteottengounramodifunzionalitàeunlavorodicostruzione.Quandol'attivitàèfinita,vienespintoallalineaprincipaleeilramo+illavorodicostruzionevieneripulito.

So che questo flusso di lavoro è simile a "gitflow", ad esempio, tuttavia la differenza principale è la durata dei rami come menzionato sopra.

Cosa ne pensi di questo flusso di lavoro? Quali flussi di lavoro usi?

(1) "Consegna continua", Jez Humble e David Farley, (2) martinfowler.com, FeatureBranch, (3) martinfowler.com, FeatureToggle, (4) martinfowler.com, BranchByAbstraction,

    
posta Andreas 15.04.2015 - 08:39
fonte

1 risposta

1

Se comprendo correttamente la tua domanda, l'unica ragione per cui vuoi un "padrone pulito" è che puoi "reagire velocemente se qualcosa è rotto". Credo che questo sia il modo migliore per eseguire gli hotfix su rami di rilascio , anziché spostare tutte le attività non hotfix su rami non master.

Fondamentalmente, si fa tutto il lavoro di sviluppo sul master come al solito, poi quando lo sprint termina e si fa un rilascio, si "taglia" un ramo dal master e lo si chiama qualcosa come "releases / 20150411". Quindi, se dovessi trovare un bug nella produzione, devi capire quali rami di release sono interessati da questo, applicare una patch a quei rami di rilascio, quindi rilanciare / ridistribuire / etc le versioni con patch agli utenti che hanno avuto le versioni non funzionanti. Questo è in realtà più flessibile dell'approccio "clean master" poiché si possono facilmente avere più rami di release, il che (supponendo che si abbiano diverse fasi di implementazione come facciamo noi) riduce al minimo il rischio di aggiungere accidentalmente nuovi bug / funzionalità all'utente "più lontano" raggruppa come effetto collaterale di correggere il bug corrente.

    
risposta data 15.04.2015 - 08:58
fonte