mvp orizzontale  psm1 small  cdap  sixsigma yellow belt mini  mcpd agileiot logo  ac2 logo

  • Categoria: ALM
  • Scritto da Felice Pescatore
  • Visite: 3706

ALM, Agile Branch Strategy

Gestire la strategia di “branch” (e di conseguenza di “merge”) è sicuramente uno degli elementi più delicati nella gestione dello sviluppo di un software (Construction in DAD), la cui complessità aumenta in modo proporzionale alla dimensione del Team e, @Scale, al numero di Team coinvolti.

Tipicamente possiamo identificare tre tipologie primarie di branch:

  • Branch per Release, in cui il ramo principale (tipicamente “Main”) subisce un branch ad ogni nuova major release (1.0, 2.0, ecc). Ottenuta la build finale (ready-to-release), viene effettuato il merge con il ramo “Main” e il ramo specifico di release viene congelato ed utilizzato per le attività di fix del sistema in produzione (Transition in DAD).

Il lavoro sulla nuova release parte sempre dal ramo Main, costantemente aggiornato all’ultima versione rilasciata;

  • Code-Promotion Branching: in questo caso lo sviluppo avviene direttamente sul ramo “Main” e il codice (una volta superata la build e i relativi test di unità) viene “promosso” sul ramo di “Test”, per i test di integrazione ed accettazione, e sul ramo di “Prod” che identifica la soluzione in produzione. Chiaramente i fix effettuati sul ramo di “Test” sono sottoposti a merge con il ramo “Main”;
  • Feature Branching: in questo approccio il ramo “Main” viene splittato in funzione delle feature da sviluppare, consentendo di procedere parallelamente nello sviluppo della soluzione. Al termine dello sviluppo della feature, il codice viene unito a quello del ramo “Main”. Questa soluzione è molto utile quando il sistema è realizzato da più Team e quando si vuole parallelizzare al massimo le attività.

Ognuno degli approcci presentati ha, chiaramente, pro e contro, e si adatta meglio a diverse dimensioni del gruppo di lavoro annesso (1 o più Team) al progetto.

Nel caso specifico di un approccio Agile, è utile inserire una quarta tipologia, che definiremo: Iteration-based Branch. Si tratta, in pratica, di un mix tra le tre tipologie appena presentate, che associa il codice e le build all’evoluzione time boxed tipica di un approccio Scrum-like e che possiamo articolare come segue:

  • Si effettua il branch del ramo “Main” in concomitanza all’inizio delle attività sulla nuova release;
  • Si effettua il branch di Iterazione (Sprint)
  • Sul branch di iterazione si opera per feature (ricordiamo che le feature sono un insieme di User Story afferenti allo stesso ambito, anche assimilabili alle Epic). Quanto sviluppato va sempre validato con build e test automatizzati, in ottica di Continuous Integration;
  • Terminate le Iterazioni, si “promuove” il codice al branch di “Test” per effettuare i testi di Accettazione e quelli di Sistema. Il codice presente sul ramo di “Test”, eventualmente fixato, completa lo sviluppo della release e ne viene effettuato il merge sul ramo “Main”;
  • Completate le operazioni sul ramo di Test, il codice va in branch sul ramo di produzione, consentendo di gestire separatamente eventuali bug-fix annessi.

iteration-branch

Iteration-based Branch

Sebbene tale approccio possa sembrare complesso e, ad un primo sguardo, sembri produrre un numero elevato di branch (che comunque, utilizzando GIT, hanno un costo assolutamente trascurabile), la sua adozione permette di avere un totale controllo di quanto sviluppato e delle varie attività di Continuous Integration e Continuous Delivery.

Inoltre, più Team possono lavorare per feature, parallelizzando le attività e aumentando l’efficienza complessiva.