le="text-align:justify;

With the release of SQL Server 2016 RC2, the RTM version must surely be nearly upon us. And certainly it has to be one of the most antcipated versions of SQL for some time? Now, I’m not one to drink the Kool-Aid on anything and everything, but I read a great post about SQL Server 2016 and the build/deployment process and how it has changed within the SQL Server Team. The most surprising aspect about this post was that the SQL Server code is kept in one branch, and that Azure SQL is deployed directly from this branch. And it got me thinking about branching strategies.

I’ve always advocated a dev/main/release process, but I’ll admit this has weaknesses, not least that testing will usually only take place properly in one branch, and that bugs found in one branch may not find there way “back” or “forward”, but to go with one branch means that you are forced to keep the quality at production-code quality and make use of feature switches. Certainly it’s an ambitious way of working, and Microsoft’s ALM documentation suggests that no branches is reserved for smaller teams, but surely if the SQL team at Microsoft are able to do it then certainly it’s a branching strategy worth considering?