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?
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…