Difference between revisions of "Branching strategy"

Revision as of 14:57, 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
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 DEF-1234 used for fixing defect issue DEF-1234. For feature FEA-1234 branch FEA-1234 is created and used for development.
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.

@@ Line 7: / Line 7: @@
 * 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.
@@ Line 15: / Line 12: @@
 * 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.
+** Name the branch <defect / feature id> ; e.g. branch DEF-1234 used for fixing defect issue DEF-1234. For feature FEA-1234 branch FEA-1234 is created and used for development.
 * Do the work
 ** Develop and test locally