Most of us spend our time in Visual Studio writing .NET code within a Visual Studio solution.  Given this situation we find it very easy to integrate with Team Foundation Server for our source control and have a well known work pattern.  But what happens when you want to use TFS as source control for non-Microsoft development?

The most important thing to remember is that source control should be as transparent as possible to the developer.  If the particular language or product does not have an Integrated Development Environment then having plug-ins to maintain this transparency is not possible and your next concern is making the way the developers interact with TFS as simple as possible.

Let’s assume that you are facing the latter situation.  The first thing to do is sit down with the team and find out what their normal process is for developing.  You need to find out how the code that becomes their executables are organized.  The key is striking a balance between logical separation and making extra work by creating too many projects.  If they users are accustomed to managing their code in a single folder then you may want to maintain that same structure for your TFS projects.

Once you get past the structure issues you then need to address the subject of branching and labeling.  I recently ran into a situation where the non-Microsoft development was customization of a packaged software.  This presented additional considerations.  They get a copy of the off the shelf code with each release from the vendor.  There may be features that are actually removed from one release to the next.  This made it easier to start a new project for each release than using labels or branching.  The last thing they wanted was code files creeping back in if they got latest and only new files had been overwritten but the obsolete files were still there.

In the end it boils down to understanding the needs of your development teams and molding your usage models to those needs.  Maintain as much transparency for your developers as possible by limiting the touch points for TFS and as often as possible allowing them to continue developing the way the always have.