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,