SCM - Branching Guidelines for Agile Development

This article discusses the principles and policies around the branching guideliness with examples for Agile Software Development.

Branch Policy

Independent of the tool used for source control management, Mainline or Trunk will be the stable main source tree, ready for release at any time.

Branching as part of source control management is intended for code-separation or code-isolation and it becomes inevitable under the following scenarios

•  Release Branch for Major or Minor Releases
•  Maintenance Branch for Patches / Hotfixes
•  Feature Branch in case of Feature Driven Development (FDD)
•  Team Branch in case of Agile Development or FDD where you branch to isolate sub-teams. 

Each team will have a development branch where they will do the day to day work.

 

Each team can promote or merge their finished stories to the mainline branch.

 

When all storied or features are done for a release, then create label (TFS) or TAG in SVN with the release name.

 

Ideally we would create the following branches for efficient code-isolation

Trunk or Mainline– Stable Code line

Dev – Feature or Team branch under development

Release –  From which the code is deployed to production

• Maitenance - Fixes for code-breaks, if any, in production. This will be usually under the corresponding release branch.

Branch Owner

Each branch will have an appointed branch owner who will be responsible for enforcing branch policy and will be responsible for merging and resolving conflicts.

 

 

Trunk or Mainline Branch

The Trunk and Mainline branch is from where the releases are made. This line should never break otherwise the whole idea of having Team or Feature specific branch will go in vain.

Trunk or Mainline Policy

 The name of the Branch will be either Trunk or Mainline

 1.    Can be released at any time

At any moment, the product owner can decide that we should make a new production release directly from the tip of the mainline. A release branch can be created to proceed with the production release.

2.    Want to release ASAP          We shouldn't check in or merge a finished story to Trunk unless it has to go live (or at  least wouldn't mind if it goes live).  

Team Branches

Team branch is for checking in stories which are in progress. This branch is also used to run integration tests before checking in stories to the Trunk and can be used by the Agile or Attached QA to verify the completed stories before it goes to Trunk. The name of the branch will be  Team_A, Team_B etc.

Team Branch Policy

    1.    Code compiles & builds.

2.    All unit tests pass.

The terms Promote and Rebase are tied to the source control tools like Seapine Surround and TFS but where as SVN and Git uses Merge (upward or downward) extensively.

Rebasing

This is the process of propagating changes from the Trunk to the team development branches. This has to done often, minimum once a day, preferably when the developer starts his day.

Rebasing Policy

1.    Every day when a team gets to work, someone (generally the branch owner) in the team is responsible for merging the latest version from Trunk to the team dev branch.

2.    If the team discovers a code conflict it has to be resolved it immediately - that's top priority!

3.    If the team needs help from other teams or whoever wrote the code that conflicts the team has to go fetch them and work together to sort it out.

4.    The important thing is that team is responsible for getting the problem sorted out, and that we need to sort it out on the team dev branch and not on the Trunk.

5.    Conflict should be resolved in the branch which is least stable.

6.    Rebasing can be done as frequently as possible and not necessarily once a day. But the minimum should be once a day.

 

 

 

 

 

 

 

 

 

 

Promoting

 

The stories that are completed in the team dev branch and ready for production is merged upwards to the Trunk and is termed as Promoting.

 

Promoting Policy

 

1.    When stories are completed and ready to go to production, they will have to be promoted to the Trunk branch from the Team branch.

2.    Ideally there should be no selective promotion which essentially means that the complete changes in Team Dev branch should be promoted and after the promotion is done the Team Dev branch and the Trunk should be equal.

3.    "Ready to Promote" is the Team's decision when they feel that the stories are ready.

4.    The promotion has to be done by the branch owner or under his or her supervision.

5.    The promotion should be done as and when a story is completed and should not be deferred to end of the sprint.

6.    Just before the promotion is done a rebase should be done to identify and relsove the conflict, if any.

 

Release Branch

Release branch (say Release 1.1.0 in the below image) is created when the product is ready for release.

After the release, based on the Product Road Map, the Product Owner may choose to release Service Pack Release or work on the bug fixes for critical issues, if any, reported by the customer. In the above image, any issues reported on 1.1.0 will be fixed in that branch and release to customer. After releasing the HotFix 1 for the patch, Release 1.1.1 branch is created. In some cases, if more than 1 HotFix needs to be worked on independently at the sametime, the developer can create HotFix specific branch (similar to Team Dev branch) and merge it to the respective release branch before taking it to production.