If you start by looking at the basic branch plan, here we have three branches: Main, Development, and Release. Let's suggest that there are three releases being supported (Release 1.0 and Release 2.0 are both in production, while Release 3.0 is in development)
Let's call Release 2.0 the *current* release (vCurrent). This makes Release 1.0 vCurrent -1 and next release is Release 3.0 (vNext), which is not yet in production.
The only difference between the basic branch plan and the standard branch plan is that we have added a new *level* of branching on the Release side, the Service Pack branch. This is the branch where post-release hot fixes and / or service pack changes are
Let's suggest that you are getting to the point where you are finalizing vNext (Release 3.0). All of the enhancements for this release have been tested in the Development branch and, when they are ready to be released, are merged into the Main branch. What
triggers a merge from Development to Main? The code in Development must be *feature complete* and tested. The code in Development must pass pre-established quality gates before it can be considered *Ready to be stabilized for Release* or *Ready to Share* or
*Ready for Integration*. You need to determine what you establish for quality gates (typically you track code quality indicators such as rates of new bugs reported, rates of bugs fixed, rates of bugs re-tested and marked complete, etc.). What this means is
you should have a formal QA process to test code in the Development branch *before* it is merged to Main. Bugs in development should be tracked and reported. When you get to the point where the rate of new bugs reported declines (toward zero) and the number
of outstanding bugs declines (towards zero). When you reach a predetermined level of quality, then the code is ready to be released. You should label this code (milestone labels are useful). Then you should merge the code from Development to Main.
The same process applies to code in the Main branch. After the new features are merged for vNext stabilization in Main, you continue to stabilize the code in Main until you reach a pre-determined level of qualtity. When you reach this level of quality, the
code is ready to be shipped. You would not create a Release branch until the code is ready to be shipped and released. The assumption here is that you would complete all testing including UAT before you branch from Main to Release (or Main to SP and SP to
I look at supporting test environments as a deployment issue, not so much a build issue (although the two are related). Rather than have separate branches for UAT1 and UAT2 (as some suggest), I deploy code from Main to each of the UAT environments. This
allows you to control which build is in each UAT environment and allows bugs to be associated with specific builds. It is difficult for QA if the code in UAT is continually being changed and built. Deployments to QA (UAT) should be controlled so they are testing
a relatively stable code base.
Each branch should have it's own automated build process. There are many flavors of build that you can consider. However, I would strongly suggest that you consider moving to TFS 2005 to TFS 2010 (or even TFS 2008) becuase of improvements that have been
made to MSBuild and Team Build since 2005. Where supported, I recommend implementing Continuous Integration (CI) builds. This means that whenever a developer check-in code to a Development branch, an automated build is automatically triggered. There is
a flavor of this in TFS 2010 - the rolling builds- that queues up check-in triggered builds so that a new build waits until a prior build completes. There is even an option for delaying the next build for a specified period of time so you do not overload the
build server during times when there a many check-in in a short period of time.
We recommend doing daily builds in the Main branch. After a good daily build in Main, we recommend merging Main to the Development branch(es). This reduces the degree to which Main and Development become out of sync. When you do this on a daily basis, there
will be more frequent merges with fewer merge conflicts each time. If you wait a long period of time between merges from Main to Development you will have the *big bang* effect where a lot of merge conflicts may need to be resolved at the same time.
In short, you would deploy from Development to QA for feature testing (you may have more than one feature branch in development). You would deploy from Main to QA for integration testing and for stabilizing the code for release.
How do you ensure you build production from the correct branch? This is why you have a build master. You do not want every developer having the ability to do builds on the Main branch. The build master should be knowledgeable and experienced enough to follow
proper procedures when building for production release. If you have the advanced branch plan (with three levels of branches on the release side), you should be aware that these three branches are created at the same point in time. When the code is ready to
ship, branch Main to Service Pack. Branch Service Pack to Hot Fix, and Branch Hot Fix to Release read-only. You should not have bidirectional branching on the release side of the picture (e.g. you would not merge a hot fix down into the release branch, but
you could merge a hot fix up into the service pack branch and then up to main to bring it forward).
On typical projects you have a variety of roles. On larger teams you might have developers grouped into teams with technical team leads. Then you have focused roles such as project manager, technical team lead, branching lead, build master, release master,
etc. It is difficult to make specific security recommendations that apply generally to a wide variety of situations. At a minimum developers probably need check-in and build privleges on a development branch. Nobody should have check-in privileges on a Main
branch. The build master should have build permissions on the Main branch, etc.
As for locking / unlocking the hot fix branch - this is probably not necessary. Controlling merges involving the hot fix branch seems to me to make more sense.
I am not an expert on DBPRO. I would be interested in hearing of your experiences in this area. What are the shortcomings or challenges you face when managing the schema with DBPro. Perhaps we can forward some ideas along to the product group.
VS ALM Ranger