User Tools

Site Tools


dev:release-management

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
dev:release-management [2015/02/09 16:50] – abbozzato un documento su cui ci si può lavorare ferodadev:release-management [2015/07/17 10:35] (current) – messe le funzinoalità di CD di orgin/stable origin/master feroda
Line 1: Line 1:
 +//FIXME: nelle figure il naming origin/prod = origin/stable//
 +
 ====== Sviluppo e gestione release ====== ====== Sviluppo e gestione release ======
  
-Questo documento riassume la gestione dello sviluppo per i software beFair.  +Questo documento contiene le guideline per il branching model e lo sviluppo collaborativo dei software beFair.
-Il documento si riferisce al repository cosiddetto "origin" cui tutti  +
-i contributori al codice fanno riferimento per portare avanti lo sviluppo.+
  
 Se si desidera conoscere il workflow di sviluppo beFair, basato sul modello a fork, Se si desidera conoscere il workflow di sviluppo beFair, basato sul modello a fork,
 si consulti il documento [[git-forking-workflow]] si consulti il documento [[git-forking-workflow]]
  
-  - il ramo principale di sviluppo è il ''master'' +Sul repo git di GF o degli altri software beFair (origin) ci sono due branch principali: 
-  - ogni release rilasciata viene taggata con ''rel-$ver$extra'' dove: +  **origin/stable** è il branch dove HEAD corrisponde sempre a codice pronto per il deploy in produzione. In altre parole, ogni commit ha superato tutti i test ed è deployable in produzione. Ogni merge viene taggato con un numero di versione. Se proprio ci fossero problemi, si può rollbackare al tag immediatamente precedente. La funzionalità fondamentale del branch stable è il **continuous delivery in produzione**. 
-    - $ver è il numero di versione seguendo http://semver.org (MAJOR.MINOR.PATCH+    - Da origin/stable si brancha solo origin/master
-    - $extra può essere ''-dev'', ''-beta''''-rcX'', o omesso in caso di release ''stable'' +    - Su origin/stable si mergia solo da origin/master 
-  per i bugfix rilasciati su una specifica versione stabile, verrà creato un branch dalla release opportuna con nome ''rel-$ver-fix''. Al rilascio a sua volta verrà assegnata una release specifica con MINOR version + 1 verrà quindi elminato il branch ''-fix''; +    - Convenzione di naming per il -m dei commit: <numero_di_versione>, con, come detto, l'aggiunta di una tag con lo stesso nome. Usiamo http://semver.org come standard per il versionamento 
-  ogni feature che lo necessita può essere sviluppata in un branch di nome ''feat-$featname'' dove $featname è il nome della feature; una volta integrato nel master, il branch deve essere eliminato;+  - **origin/master** è il branch principale di sviluppo dove vengono mergiati tutti gli altri branch descritti sotto. E' anche usato per committare eventuali piccole modifiche necessarie per la release. In altre parole, è un ''integration branch'' ed anche ''release finalization branch''. La funzionalità fondamentale del branch stable è il **continuous delivery in staging**. 
 +    - Da origin/master si branchano tutti i branch descritti sotto 
 +    - Su origin/master si mergia da tutti gli altri branch, escluso origin/stable 
 + 
 +{{:dev:main-branches.png?200|}} 
 + 
 +Ogni sviluppatore clona sulla sua macchina i due branch principali di originIn base alle necessità, può creare branch secondo lo schema seguente: 
 +  - **Feature branch**: è dove si sviluppa una nuova featureTipicamente esiste solo sulla macchina dello sviluppatore, ma si può pushare sul repo per lavoro di team o se serve una review del codice. 
 +    - Si brancha da origin/master 
 +    - Si mergia su origin/master usando sempre e soltanto --no-ff (lo so, lo so, ma qui ha molti più pro che contro
 +    - Convenzione di naming: ''feature-<nome_descrittivo_della_feature>'' 
 + 
 +{{:dev:feature-branches2.png?200|}} 
 + 
 +  - **Bugfix branch**: identici ai feature branchma destinati a fixare bug di codice non ancora mergiato in ''origin/stable'' 
 +    - Convenzione di naming: ''bugfix-<numero_bug>'' 
 + 
 +  - **Hotfix branch**: è dove si fixano bug severi del codice già andato in produzione. 
 +    - Si brancha da ''origin/stable'' 
 +    Si mergia su ''origin/stable'' e ''origin/master'' con --no-ff 
 +    Convenzione di naming: ''hotfix-<versione>'' con il field PATCH aumentato di 1
  
 +{{:dev:main-branches.png?200|}}
dev/release-management.1423500618.txt.gz · Last modified: 2015/02/09 16:50 by feroda