Branching, Versioning and Deployment of Sitecore
Here’s quick set of recommendations for setting up your deployment processes with Sitecore once a solution goes live into Production.
Versioning
For versioning I’d recommend the http://semver.org convention of MAJOR.MINOR.PATCH.BUILDNo-BranchName
e.g. 1.2.15.1102-hotfix
Source Control Branches
Branches in source control should be setup as follows:
Master: should be the current production code or code about to be deployed.
Hotfix: should be used for small fixes for production.
Release “A”: larger changes that require a longer period of development and testing.
Each branch is distinguished using a suffix and has it’s own Build Number. The exception is the Master branch, which has no suffix.
The Major.Minor.Patch number reflects which version of Production has been merged into that branch.
When a support/development branch is merged into Master (i.e. ready for Deployment to Production) the version number of Master is incremented (to reflect whether this is a major, minor, or patch change).
This all looks like this over the life of the solution:
Channels
Using Octopus Deploy we can create release Channels based on the version numbers suffix. Create a Channel and add a Version Rule. Set the “Tag” filter to be the name of the branch e.g. hotfix. For the Master branch set this value to ^$
Each Channel can have it’s own Lifecycle, so we could set it up so that only the Master branch can be deployed to Production, while others can only go to testing environments.
Sitecores Recommendations
Sitecore have some of their own best practices around deployment, which you can read about on the official Sitecore Helix best practices website: http://helix.sitecore.net/devops/deployment/strategy.html