Difference between revisions of "Branching strategy"
From AccountIT
(1st version of branching strategy) |
|||
Line 1: | Line 1: | ||
Our mantra : "Trunk is always releasable" | Our mantra : "Trunk is always releasable" | ||
− | Configuration Management is based on [http://www.infoq.com/articles/agile-version-control|Agile version control with multiple teams] by Henrik Kniberg. Highlights from the document are: | + | Configuration Management is based on [http://www.infoq.com/articles/agile-version-control| Agile version control with multiple teams] by Henrik Kniberg. Highlights from the document are: |
* trunk is always releasable | * trunk is always releasable |
Revision as of 14:09, 16 February 2014
Our mantra : "Trunk is always releasable"
Configuration Management is based on Agile version control with multiple teams by Henrik Kniberg. Highlights from the document are:
- trunk is always releasable
- all work is done on development branches
- frequent merges from branches back to trunk (when in a releasable state, of course)
- frequent merges from trunk to branches in order to get latest changes from other teams
From Build and Deployment we also get:
- all maven version numbers on trunk and branches should be SNAPSHOT-versions.
An example of a workflow in SVN:
- Branch out from trunk
- Name the branch <defect / feature id> ; e.g. branch P175555 used for fixing prosupport issue P175555. For feature id we should use JIRA id.
- Do the work
- Develop and test locally
- Verify successful integration test
- Commit the work in SVN
- Merge branch back to trunk
- The JIRA Id must be prefixed the check-in comment, e.g. "FDD-3083: merge feature to trunk". This is used in Build and Deployment
Guidelines on how to do branching and merging can be found here.