I'm interested in your thoughts on my branching strategy for our web application. In particular, I want to know if I have accommodated the business needs for different execution environments.
Here's the situation:
- Our software is a web application
- Our release cadence anticipates periodic (say, quarterly) releases
- Our customers generally only need to use the latest released version of the software
- Some customers need to use a pre-release ("UAT") version to evaluate new features
With this in mind, I have proposed a 4-branch system:
- Dev - For ongoing latest development
- QA - For internal QA needs
- UAT - For pre-release testing
- Production - For customers
Merges will take place in the following manner:
- Changes to the QA branch will be made by merging FROM Trunk
- Changes to the UAT branch will be made by merging FROM UAT
- Changes to the Production branch will be made by merging FROM Production
Deployments will take place in the following manner:
- Builds from the Dev branch will be deployed to the Dev environment
- Builds from the QA branch will be deployed to the QA environment
- Builds from the UAT branch will be deployed to the UAT environment
- Builds from the Production branch will be deployed to the Production environment
So, what do you think? Am I vaguely on track?
We basically use that strategy. A branch per environment.
Sometimes we make a service pack branch for any major issues that we would eventually dead end.
There is a TFS branching strategy guide on codeplex.