views:

2888

answers:

16

We're currently in the process of setting up a source control/build/and more-server for .NET development and we're thinking about either utilizing the Team Foundation Server (which costs a lot of dough) or combining several open source options, such as SourceForge Enterprise/GForge and Subversion and CruiseControl.net and so on. Has anyone walked down the full blown OSS road or is it TFS only if you want to get it right and get to work soon?

+1  A: 

Our company uses the CruiseControl/SVN/nAnt/JIRA combination with great success.

The deal breaker with TFS is that it is only worth it for larger companies. It will be terribly expensive for smallish companies with 30 or less developers, which would already benefit greatly from the above open source combo.

Jon Limjap
I'm interested why you use JIRA with your other selections, unless the product you are developing is also open source. We use the same stack except we use TRAC for our bug tracking / wiki. TRAC is free for commercial use.
Mike Schall
+5  A: 

My work is currently using a mostly OSS build process with Cruise Control as the engine and it is great. I would suggest that if you don't know why you would need TFS, it's probably not worth the cost.

The thing you have to keep in mind with the OSS stuff is that the software has either been in use by the Java crew for years previously, or the software is a port of similar Java code. It is robust and is suitable for purpose.

Microsoft cannot ship OSS code, which is why they have to re-implement a lot of Open Source stuff. So, no, it is not necessary, and there have been millions of projects shipped on that stack. The flip side is that there is also a lot of nice features that you get with TFS that you won't (easily) get with the OSS stack, such as integration with your bug/feature tracking software.

Travis
CruiseControl.NET has some nice integration with Altassian JIRA, however.
Jon Limjap
Microsoft _can_ ship open source code, and they do (jQuery, their MVC framework...)
sgwill
I'm pretty sure that this response was composed before MS announced they would be bundling their _first_ open source project, the aforementioned jQuery :-). But yes, they are opening up a little and showing some of their code to the world, but it's certainly baby steps at this stage. Also, did the MVC guys accept patches? That to me is the minimum that I consider to be open source - not just code on display.
Travis
Microsoft cannot ship open source code and charge for it. MVC doesn't cost anything to download. TFS on the other hand... That's the difference.
Jaco Pretorius
A: 

I've seen both in action (though I'm a Java developer). The upsides from a pick and mix approach is that you can choose the best bits for everything (e.g. I'd check out Hudson for CI - its excellent for Java, works for .Net too and has loads of plugins and is really simple to use). The downside is that you have to do all the integration yourself. However, this is getting a lot easier in the Java world. Also, don;t let folks tell you a supported product is better. On many OSS products in this space the quality is excellent and you get better support from the cimmunity rather than waiting for an answer from your vendor's support contract (IBM, I'm looking at you)

Hope this helps.

Andrew Harmel-Law
A: 

I would agree strongly with the point that it is only worth using TFS if you know exactly what you need it for. The OSS-based, cheap or free add-ins like Visual SVN and TestDriven.Net are so good that integration with VS is seamless already.

Joel in Gö
+4  A: 

I've always gone the OSS way and have never had a problem. I would also highly recommend TeamCity for your CI solution. There is a free licence and I think it blows CC.NET out of the water for ease of configuration and feedback.

Chris Canal
+3  A: 

I've been a daily user of TFS for about 1.5 years now.

  • Source control is stable
  • You can't easily work disconnected. File check out goes to the server.
  • Auto-merge works great, except sometimes it corrupts the source file (encoding problem).
  • TFS has a sluggish feel!? Especially the test manager. Managed code?
  • There are various silly bugs in the test part, nothing critical.
  • Test runs takes too long to start (pending).
  • I get SQL deadlocks once in a while!?
  • Issue tracking sucks imho. You are forced to work in the slow integrated dialogs, web is display only. I recommend comparing it with other issue tracking systems, like JIRA
  • Builds works ok.
Bjorn Reppen
You can work disconnected in TFS 2008 without a problem - we've been using it for a good few months. It sounds like you're still using TFS 2005 which had quite a few of these problems, but they're largely fixed in 2008.
Greg Beech
If your going to mention bug/issue tracking on Stackoverflow, I'm sure Joel would appreciate a mention of FogBugz.
Kelly French
A: 

I thought I'd throw in a new perspective that can be taken with a grain of salt because I haven't tried it yet, but I plan on using Bitten for CI in an upcoming project. This runs atop Trac+SVN, both great tools that I've used for many projects successfully.

Loren Segal
+1  A: 

Subversion + Cruisecontol.Net is a good alternative. SVN is is feature-rich, stable and flexible.

Anthony
+1  A: 

If you are using TFS make sure you install VSTS2008SP1. The vast majority of people I've seen posting complaints are using the 2005 version. 2005 is the classic "Microsoft 1.0" syndrome. There were a LOT of problems that have been fixed by the 2 later "versions".

The Service Pack for 2008 isn't just a bug fix - but added many new features.

As far as the choice vs OSS - there are a lot of discussion (here and elsewhere). It isn't a cheap product - but it is the best choice for a lot of scenarios (and the worst for others).

fuzzbone
A: 

We've built up a development stack gradually here, we're currently using:

  • Subversion
  • CruiseControl
  • RedMine (integrates bug tracking with source control and includes wiki, basic project management, etc).
Jim T
+2  A: 

We looked at TFS, but ended up going with Subversion + Trac + VisualSVN. We don't do CI right now but Cruisecontrol would be what we'd use, I think.

I started using Trac with numerous open-source projects, and it's a great. It's really only a portion of what TFS does, so you'll have to make a decision there -- if you use everything, TFS probably does a better job of tying it all together. Trac is a wiki/bug tracker/source browser. Everything is linked - when you type in the name of a WikiPage or say "Fix bug #1234" in a commit message, whenever you see that message in Trac the links go to the right places. It is tool that helps you do your job and but stays out of the way, generally.

VisualSVN is a great bridge between TortoiseSVN (a Subversion client) and VisualStudio, and greatly improves productivity. They have a free trial, and it's not very expensive afterwards ($50/user), but well worthwhile.

One possible downside to Trac is in a Windows world, it is a pain to get working on IIS. I've installed Trac many times, but got frustrated quickly trying to get it working properly. I ended up installing Apache on a different IP (could also use different port) and then it was seamless.

Except for one person on my team (who had a tiny bit of experience), no one had ever used subversion before. A couple had used VSS, and thats all. Everyone was pretty skeptical, but I'd say within a few days they were all converts. After fully learning Trac and getting used to everything (a few days more), everyone is totally sold and loves it.

gregmac
+1 Trac rocks. It's great because it's lightweight - stays out of your way and does everything you need. If only there was an open-source project that combines Subversion, Trac and Cruise Control - now that would rock.
Jaco Pretorius
Oh and in terms of running Trac - you don't need to run it in IIS. I just run it as a service with SrvAny - makes your life very easy.
Jaco Pretorius
A: 

The real benefit of using TFS compared to a separate set of OS tool is the integration of the various flow of informations available.

* Create a requirement and insert into TFS
* Create a set of task linking them to the requirement and assign them to the various developers
* Each developer work on his task and checkin, assigning the task to the changeset checked in
* A bug fix come in, also in this case the change set will be coordinated with the bug fix request and you can also map the bug fix to the original requirement

Once done this all the information can be used to track project and make evaluation about the work, like for example how many changes a bug fix caused, which are the requirement that has generated more bugs or change requests and so on.

All these informations are very useful in medium and large organizations and, from what I'm seeing now, are not possible (or very difficult) to track integrating different OS tools.

massimogentilini
A: 

The TFS stack is far more than source control and a CI/nightly build setup. Think about project management, bug reports and it all adds up to something more than just CruiseControl, SVN and NAnt. Just the reports alone might be worth the investment. And also remember that if you're a MSDN subscriber/ISV gold partner/etc. you might get some of this for free...

noocyte
A: 

I think that the TFS is worth it for all the extra features mentioned in above posts. It's continuous builds functionality is seriously lacking though so we augment that part using CruiseControl.NET which is awesome. The only reason we would choose against TFS if we were to do it right now is that we are moving to cross platform development of our products. So if you have even thought about that, think OSS. Subversion/Trac would be my favorite combo that way with CruiseCOntrol.NET still being the backbone. CC.NET using mono works well on Linux and Mac.

A: 

TFS2010 has a TFS Basic, which costs nothing (over and above your msdn subscription/visual studio licence). It is limited to 1 per VS licence, but you only need additional licences for non VS users

The UI Automation in VS2010 alone makes TFS a winner over cobbling together open source solutions

Mark Shurmer
A: 

It is worth mentionning that best alternative to a wide range of TFS features are not necessarily OSS, but low-budget commercial, like NDepend for code quality and architecture exploration, NCover for code coverage, TestDriven.NET for testing nested in IDE ...

Patrick Smacchia - NDepend dev
Patrick, you may want to explicitly note your association to NDepend. Your answer may seem a bit spammy otherwise.
John Saunders