Is the Subversion 'stack' a realistic alternative to Team Foundation Server?

Question

I'm evaluating Microsoft Team Foundation Server for my customer, who currently uses Visual SourceSafe and nothing else. They have explicitly expressed a desire to implement a more rigid and process-driven environment as their application is in production and they have future releases to consider.

The particular areas I'm trying to cover are:

• Configuration management (e.g., source control)
• Change management (workflow and doco for change requests, tasks)
• Release management (builds and deployments)
• Incident and problem management (issues and bugs)
• Document management (similar to source control, but available via web)
• Code analysis constraints on check-ins
• A testing framework
• Reporting
• Visual Studio 2008 integration

TFS does all of these things quite well, but it's expensive and complex to maintain, and the inexpensive Workgroup edition doesn't scale. We don't get TFS as part of our MSDN subscription.

Those problems can be overcome, but before I tell my customer to go the TFS route, which in itself isn't a terrible thing, I wanted to evaluate the alternatives. I know Subversion is often suggested for its configuration management/source control, but what about the other areas? Would a combination of Subversion/NUnit/Wiki/CruiseControl/NAnt/something else satisfy all of these requirements? What tools do I need to include in my evaluation?

Or should I just bite the bullet and go with TFS since we're already invested in the Microsoft stack?

Answer 1

Some very large projects are succesfully running on SVN or GIT.

I would be inclined to use different best of breed apps that talk to each other than a single monolithic creation like TFS. A lot of free and commercial bug trackers integrate with SVN as do test runners. It's also generally easier to create your own interfaces to something like SVN than to make an MS server app do something new.
And finally it's easier to migrate from something like SVN to the next great new thing than to get data out of a proprietry package like TFS.

Answer 2

Good question(s). I've never used TFS but all this certainly is possible with a number of tools. The biggest hurdle is the culture and mindset of the company and developers.

I am pro SVN. (But TFS would work I am sure)

I'd suggest very light intrusion on daily tasks.

Having sandboxes or promotion rules from one branch to another in SVN is one way to do code analysis without holding up the commit process.

So, to address each of your points: SVN handles source control and is ancillary/included in change management and Release management

Change management/Workflow is basically defined by the project team and can be helped with simple tools or just enforced by policy.

Release management is also policy based and uses the existing framework/tools (SVN)

Most any of the popular defect/issue tracking systems will handle the Incident and Document management - think wiki with trac or fogbugz (along with SVN for doc mgmt)

FXCop and all the other tools can be part of a build for code analysis

Testing framework is more policy based than tool driven - you have to make it a priority if that is what you want.

Your reporting notion is vague, but I think you have more than enough tools in any scenario to satisfy this

I am not sure what you really need as far as integration with 2008. In any case this not much can be as as tightly coupled as TFS, but I don't see that as a problem.

(I think you answered your own question.) This may end up being a religious war between MS and anti-MS sides.

In the three places I was at where I was in charge of recommending and implementing a solution, we voted with our wallets - against MS. I am sure TFS is capable, but the competition is quite up to the task and I think those tools translate well for other jobs.

As for tools to consider - I think searching Stack overflow for nant, msbuild, cruisecontrol, etc will give you more content than you can shake a stick at...