dev:release-management
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
dev:release-management [2015/02/16 10:46] – Chiarimento warp10 | dev: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/ | ||
+ | |||
====== Sviluppo e gestione release ====== | ====== Sviluppo e gestione release ====== | ||
- | Questo documento | + | Questo documento |
- | Il documento si riferisce al repository cosiddetto " | + | |
- | 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 '' | + | Sul repo git di GF o degli altri software beFair |
- | - ogni release rilasciata viene taggata con '' | + | - **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. |
- | - $ver è il numero di versione seguendo http:// | + | - Da origin/stable |
- | - $extra può essere '' | + | - Su origin/stable |
- | - per i bugfix rilasciati su una specifica versione stabile, verrà creato un branch dalla release opportuna con nome '' | + | - Convenzione di naming per il -m dei commit: < |
- | - ogni feature che lo necessita può essere sviluppata in un branch di nome '' | + | - **origin/ |
- | + | ||
- | + | ||
- | ==== Proposta di warp10 ==== | + | |
- | + | ||
- | Sul repo git di GF (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. | + | |
- | - Da origin/prod si brancha solo origin/ | + | |
- | - Su origin/prod si mergia solo da origin/ | + | |
- | - Convenzione di naming per il -m dei commit: < | + | |
- | - **origin/ | + | |
- Da origin/ | - Da origin/ | ||
- | - Da origin/ | + | - Su origin/ |
+ | |||
+ | {{: | ||
Ogni sviluppatore clona sulla sua macchina i due branch principali di origin. In base alle necessità, può creare branch secondo lo schema seguente: | Ogni sviluppatore clona sulla sua macchina i due branch principali di origin. In base alle necessità, può creare branch secondo lo schema seguente: | ||
Line 31: | Line 23: | ||
- Si brancha da origin/ | - Si brancha da origin/ | ||
- Si mergia su origin/ | - Si mergia su origin/ | ||
- | - Convenzione di naming: feature-< | + | - Convenzione di naming: |
- | - **Bugfix branch**: identici ai feature branch, ma destinati a fixare bug di codice non ancora mergiato in origin/ | + | |
- | - Convenzione di naming: bugfix-< | + | |
- | - **Hotfix branch**: è dove si fixano bug severi del codice già andato in produzione. | + | |
- | - Si brancha da origin/ | + | |
- | - Si mergia su origin/prod e origin/ | + | |
- | - Convenzione di naming: hotfix-< | + | |
+ | {{: | ||
+ | |||
+ | - **Bugfix branch**: identici ai feature branch, ma destinati a fixare bug di codice non ancora mergiato in '' | ||
+ | - Convenzione di naming: '' | ||
+ | |||
+ | - **Hotfix branch**: è dove si fixano bug severi del codice già andato in produzione. | ||
+ | - Si brancha da '' | ||
+ | - Si mergia su '' | ||
+ | - Convenzione di naming: '' | ||
+ | {{: |
dev/release-management.1424083615.txt.gz · Last modified: 2015/02/16 10:46 by warp10