GIT Flow e versionamento semantico

Git flow, ovvero come mantenere un repository organizzato, pulito, e organizzare cicli di rilascio senza rischi al crescere delle diemnsioni del team di sviluppatori.

Git flow e le sue convenzioni

Master, dev, feature, hotfix, branch definiti con significati diversi e condivisi all'interno del ciclo di vita del software e del flusso di sviluppo e lavoro del team.

Vincent Driessen ha teorizzato GIT flow per sfruttare al massimo le potenzialità di GIT e definire un modello di branching condiviso che facilitasse la collaborazione all'interno del team. GIT flow prevede la presenza di due master branch, “dev” (o “develop”) utilizzato per lo sviluppo, e “master” per i rilasci ufficiali. Questi due branch sono il riferimento per la 'storia' del progetto e la mantengono pulita e leggibile al netto dagli sviluppi di nuove feature e hotfix (correzioni sulla versione in produzione), che altrimenti confluirebbero senza filtri sul ramo principale, rendendo poco comprensibile la storia del progetto e complesse le reversioni a stati precedenti. In ELbuild utilizziamo GIT Flow per tutti i progetti di sviluppo, a prescindere dalla dimensione del team, ma è quando la dimensione del team raggiunge 5 o 6 sviluppatori che i benefici si fanno evidenti.

Versionamento semantico

x.y.z, come tre semplici numeri possono aiutare a risolvere conflitti e problemi di retrocompatibiltà e dipendenze

Il versionamento semantico (semantic versioning) è una convenzione di numerazione delle release software basato su tre numeri interi: major, minor e patch. Il nome di una release si ha concatenando questi tre numeri attraverso la notazione punto. Ad es: 2.3.4, indica major version: 2, minor version: 3 e patch: 4. Ci sono regole precise sulla retrocompatibilità o meno delle versioni, in funzione della variazione di uno dei numeri e questo porta a chiari benefici nella definizione delle strategie di release. Anche il versionamento semantico fa parte delle convenzioni condivisi, oggi parte delle best practice di sviluppo, che adottiamo per i progetti sia interni che cliente.

L'importanza di metodologie e convenzioni condivise

Abbiamo provato sulla nostra pelle il vantaggio di avere una metodologia e delle convenzioni condivise e possiamo offrirti consulenza per portare gli stessi benefici nel tuo team.

ELbuild molto spesso offre consulenza ad aziende dotate di un proprio team di sviluppo, sia su temi di transizione tecnologia (esempio per migrare competenze e risorse umane da uno stack all'altro) sia per quanto riguarda la formazione di una metodologia condivisa e di una serie di best practice volte a incrementare la qualità del lavoro di un team di sviluppo. Questa attività di consulenza è molto importante nel caso di startup che in una fase successiva al lancio del prodotto decidano di investire su un team interno per portare avanti in autonomia il progetto.