dev:release-management
This is an old revision of the document!
Sviluppo e gestione release
Questo documento contiene le guideline per il branching model e lo sviluppo collaborativo dei software beFair.
Se si desidera conoscere il workflow di sviluppo beFair, basato sul modello a fork, si consulti il documento git-forking-workflow
Sul repo git di GF o degli altri software beFair (origin) ci sono due branch principali:
- origin/prod è 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. In caso di problemi, si può rollbackare al commit immediatamente precedente.
- Da origin/prod si brancha solo origin/master.
- Su origin/prod si mergia solo da origin/master
- Convenzione di naming per il -m dei commit: <numero_di_versione>, con l'aggiunta di una tag con lo stesso nome. Usiamo semver.org come standard per il versionamento
- 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.
- Da origin/master si branchano tutti i branch descritti sotto
- Da origin/master si mergia da tutti gli altri branch, escluso origin/prod
Ogni sviluppatore clona sulla sua macchina i due branch principali di origin. In base alle necessità, può creare branch secondo lo schema seguente:
- Feature branch: è dove si sviluppa una nuova feature. Tipicamente 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>
- Bugfix branch: identici ai feature branch, ma destinati a fixare bug di codice non ancora mergiato in origin/prod
- Convenzione di naming: bugfix-<numero_bug>
- Hotfix branch: è dove si fixano bug severi del codice già andato in produzione.
- Si brancha da origin/prod
- Si mergia su origin/prod e origin/master con –no-ff
- Convenzione di naming: hotfix-<versione> con il field PATCH aumentato di 1
dev/release-management.1424088584.txt.gz · Last modified: 2015/02/16 12:09 by warp10