Practicality when Branching in TFS

bdougherty — Sun, 10 Aug 2008 19:05:00 GMT

Here at Clarity, we hold infomal internal training events a couple times a month to discuss new technologies, tools, or other things related to software development. Recently, Don Peterson led a discussion on source control management strategies for development teams using Team Foundation Server. Some of what was discussed was based on Microsoft's Branching Guidance white paper. I've read the paper before and I think it is a good read, full of good info. The focus of our discussion the other day was Release Isolation since that is probably the most commonly used strategy. The paper shows branching for release isolation in this way:

I agree with the approach in spirit, but I think it's worthwhile to ask yourself a few questions to see if you need this much complexity:

How big is my team?
Do we need isolated feature changes?
How does development process work?

For small teams (< 10 developers), I think it can be in your best interest to simplify your branching structure to something more like this:

First, let's recognize that TFS, like any product, has some issues. As I've experienced lately, merging large structural refactoring changes can cause problems. I think you're best off limiting merges and merging often. And with smaller teams you don't necessarily have a lot of independent work going on and may not need separate Dev and Main branches. Main is meant to be your stabilization branch, but if your development team works together well in a single branch you can limit some of the merging needed by conceptually combining those branches. Feature separation is still possible by creating branches off of Main as needed. When it's time for QA, I think it's okay to simply branch off for the release and build your QA release out of the release branch (i.e. Release 1.0). Bugs found in QA testing can be fixed in the Release Branch and then merged back to Main. The final signed off QA build becomes the release version and then the release branch can have security locked down so that the only changes that will ever go into the release branch will be for approved hot fixes.

In summary, I'm not suggesting the approach described in the white paper is flawed. These are smart guys and everything makes sense. I simply think that it's best to be practical and consider what you really need to succeed.

Visual Studio Team Edition for Database Professionals: A Developer Productivity Tool

bdougherty — Tue, 18 Mar 2008 01:23:00 GMT

I wanted to share a few quick thoughts on Visual Studio Team Edition for Database Professionals. Over the past several months I’ve found this to be an invaluable tool. Aside from being a mouthful, the name is a little misleading as it implies that it is only targeted at DBAs. This is not the case. This component of the Visual Studio Team Suite is something that developers can use to gain productivity.

On most of the projects I’ve been involved in, developers are making changes to databases and a DBA may not even exist. Coordination of those changes during the development phase can be a challenge. Even more challenging can be the deployment of those changes to integration, testing, and production environments. VS DB Pro allows developers to track the database structure in a Visual Studio project, just like a class library. A project can be created from an existing database or a new project can be started. The main component of the tool is ability to perform a Schema Comparison, comparing one database or database project to another database. Developers can use the comparison to apply the changes to their local database, or to make changes to the project. I’ve found that this is very helpful for getting changes from one developer to another quickly. The integration with source control helps track your changes. Later in the application life cycle, developers and/or the operation team members can generate a script using the comparison to deploy changes to a test or production environment. In addition to schema comparison, there are other features the tool provides like refactoring and unit testing, which I haven’t used much of yet.

As always, you can’t beat good communication across a team as a key component of a successful project. However, I think that adding Visual Studio Team Edition for Database Professionals can make your project even more successful. I’ve got some further ideas about “best practices” for using the tool on a project and I’ll try to post those at a later date.

A couple notes for full disclosure: I’ve only used VS DB Pro with SQL Server 2005 databases and TFS source control so I can’t tell you about the experience beyond that. Also, I’ve never compared its feature set to that of other tools - I’ve simply taken it for granted as part of the Team Suite. And there are a few gotchas. For example, sometimes after getting latest from source control, even when clicking the “update schema” button, the local temp database doesn’t get updated and that can cause some problems. I’ll give MS a little break chalking this up to a first version of the tool (But it better work better in future releases!).

Search results matching tags 'Project Management' and 'Software Tools'

Practicality when Branching in TFS

Visual Studio Team Edition for Database Professionals: A Developer Productivity Tool