Difference between revisions of "Branching strategy"

From AccountIT
Jump to: navigation, search
 
(4 intermediate revisions by one user not shown)
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 Version Control for Multiple Agile Teams] by Henrik Kniberg. Highlights from the document are:
  
 
* trunk is always releasable
 
* trunk is always releasable
Line 7: Line 7:
 
* frequent merges from branches back to trunk (when in a releasable state, of course)
 
* 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
 
* 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:
 
An example of a workflow in SVN:
Line 18: Line 17:
 
* Commit the work in SVN
 
* Commit the work in SVN
 
* Merge branch back to trunk
 
* 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.
+
 
 +
[[Category:Development]]

Latest revision as of 16:15, 30 April 2014

Our mantra : "Trunk is always releasable"

Configuration Management is based on Version Control for Multiple Agile 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

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