I’ve read the Team Foundation Server Branching Guidance several times but I still have some questions I’m hoping the development community at large can help answer.
The small team I lead does typical corporate development projects including data warehousing, business-to-business integration, e-commerce and intranet/extranet web applications. We develop all our corporate “applications” using Microsoft tools such as Visual Studio 2005 Team Suite, SQL Server 2005, BizTalk Server 2006 and Commerce Server 2007. Our development efforts are driven by both internal customers and external trading partners and all projects continue to “evolve” over time, adding new scenarios as the business continues to grow.
Although we don’t use this term, we “continuously integrate” these new scenarios into our TFS projects at a very rapid pace and deploy them on an “as needed” basis. We rarely “roll back” something that we have deployed and we tend to fix our “bugs” as we (or our internal or external users) find them. I believe this is a pretty typical corporate development scenario. What we need is guidance on setting up a branching/merging strategy that “fits” a corporate development scenario where “releases” are small and incremental (such as deploying a new SQL Reporting Service report or SSIS Package) and happen very often (sometimes several per week).
Today, we use a “branch per major release” strategy and only create a new branch when we need to temporarily maintain our “Release 1.0” code while deploying a “Release 2.0” to our users. After deploying the “Release 2.0” bits we discontinue supporting the “Release 1.0” branch. So far, we have never merged from branch to branch.
Questions:
1) Is this a legitimate branching strategy for a small corporate development team?
2) If not, how do we deploy a more traditional DEV/MAIN/PRODUCTION strategy without the “overhead” of merging almost continuously?