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...

Answer 3

As much as people hate consultants, you might consider talking to a firm that does commercial svn support. If TFS is as expensive as you say, this may save you some money with the benefit of starting you off with a good setup. There are risks involved with this of course.

Answer 4

I would look into SVN,Trac,CruiseControl, and Nant... all free, open source, and extremely mature.

I have convinced my workplace on this stack, and I haven't looked back...

Answer 5

If the target developers are Microsoft-centric and the customer wants enforcable process, then staying with the TFS is a good call. Implementation costs have to take into account the learning curve, any lost productivity and existing infrastructure. If this is a big shop, and it sounds like it is, you'll also need an "IT" team's buy-in, which may be hard to get with a whole new technology stack.

Having said that, here are some other options:

You might want to take a look at Subversion + Atlassian's Jira (issue tracking), Confluence (wiki), Bamboo (CI), Clover (code coverage), Fisheye (repository "insight")

These are commercial tools, but are also already integrated and integrate well with Subversion.

The Rational toolset, which IBM now sells and develops, is robust, reliable and is very process-oriented. Probably more expensive than TFS, though. I have not used this recently, but in past engagements it performed well for those shops.

And finally, there's Computer Associate's Software Change Manager which has the most obnoxious process enforcement of any tool I've ever had the misfortune to be forced to use. But if anal-retentive, obsessive/compulsive mandatory process is what you want, this is the tool for you.

Answer 6

I associate the "Subversion stack" with FOSS for some reason. Not that it can't be used for enterprise work, but in my experience, enterprise customers prefer the all-in-one solution.

Answer 7

Team Foundation Server also includes build management, TFS build management can be used for Continuous Integration as well as release builds etc.

I have used CruiseControl.NET with Subversion for build management and it worked. However TFS will give you more control and auditing etc. Consider if you wish to have that level of control over your programmer, or should you be trusting them more.

Also consider Vault or Fortress from SourceGear, as the are designed to be easy for people that are used to Visual SourceSafe, .e.g. they have pinning.

Answer 8

Though question, I think both routes have their merits. I really like the usability of basic & daily operations that TFS provides through it's Visual Studio integration. GUI'wise if you compare it to TortoiseSVN it really looses feature wise. TFS does have a command line utility that covers most functionality missing in the GUI. Beyond source control I think TFS provides far stronger cohesion when it comes to setting check-in/commit policies, associating it with work items and such. I like the web interface in particular that TFS provides (although do look into it's licensing model before getting overly enthusiastic) Merge conflict handling is rather poor in VS2008, something they will be improving in VS2010. TFS is somewhat a jack of all trades, perhaps mastering non. However also TFS allows hybrid solutions when it comes to continuous integration, various tools from what you call "Subversion stack" can be used in combination with TFS also.

Answer 9

VisualSVN provides really good integration between SVN and VS. we migrated from TFS to SVN. back then(about 2 years ago i think...) what we felt was that TFS was bloated and slower(much slower compared to svn). But i am sure by now it must have improved.

One main difference between the two routes is that TFS can be setup easily when compared to a 'svn stack'. you would have to install different tools and applications and get them to work together. it would take some time. but after wards it will work with out complaining.

Answer 10

I think the following stack is superior to TFS:

• VisualSVN Server - source control
• Hudson - automated build
• Redmine - issue tracking

Each one of these tools serve a specific purpose and stand on their own merit. They work well together but can be replaced individually when something better comes along.

Answer 11

Our stack looks like:

Configuration management (e.g., source control)
SVN

Change management (workflow and doco for change requests, tasks)
Trac

Release management (builds and deployments)
Hudson

Incident and problem management (issues and bugs)
Trac

Document management (similar to source control, but available via web)
SVN (with Apache for web interface)

Code analysis constraints on check-ins
Coverity

A testing framework
Hudson (supports many various unit testing frameworks)

Reporting
StatSVN

Visual Studio 2008 integration
VisualSVN

Answer 12

I'm surprised no-one's mentioned Collabnet's TeamForge. Its the 'stack' part of SVN for all the bug tracking and other management controls on top of SVN.

It doesn't do requirements management as well as other apps (eg Polarion's Requirements) but if you can trace a requirement as a 'bug' then it'll be fine.

Incidentally, there is Polarion's ALM that is a competitor to TFS - they have a comparison chart on the website. Expensive though :(

The best free alternative would probably be Redmine IMHO.

Answer 13

I've worked with both sides of the fence. I was originally forced to use SourceSafe. I hated it with a passion. When I was in a position to steer IT policy I tried a few different options and went the SVN and Trac route. It was not without its learning curve as well but the results were great.

I most recently started working at a pretty big place which uses SourceForge and RedMine. I miss SVN majorly. I like Redmine. We more recently moved everything to TFS and Jira. Sometimes I think big companies do things just because they like spending money. If I had a choice and price was no issue I'd still choose SVN and RedMine.