TFS 2008/2010 vs Jenkins for Continuous Integration

12
votes

Does anyone have specific experiences with using TFS 2008/2010 AND Jenkins for Continuous Integration (CI)? We are trying to decide which CI server to use. Our team works exclusively in Microsoft .NET/Visual Studio 2010/C#. We have the following requirements:

  1. Automatically build our web project on every checkin.
  2. Run unit tests with each build.
  3. Automatically deploy green builds to development and/or test environments.
  4. Provide pretty reports.
  5. Provide build/deployment notifications via email.

I realize that installing a tool won't necessarily give us this functionality out-of-the-box and that we will have to integrate with other tools like MSBuild to achieve this.

I'm looking for specific features that Jenkins has that TFS 2008/2010 does not or vice versa. Also which is easier to maintain, use, etc.

3
tfscontinuous-integrationjenkins
Just off-hand, Jenkins can do all of those things (TFS SCM plugin, MSBuild plugin, deploy-to-X plugins), though the "pretty reports" part may require some effort on your part. But for that, there's a pretty comprehensive API to retrieve build info and whatnot that might help. – Christopher Orr
Also Jenkins is really really easy to maintain and use. You can do everything using the browser, all options have comprehensible context help and the community is very active and helpful. – pushy
Also, Jenkins has the Chuck Norris plugin, which is an absolute must for shaming developers who break the build. TFS does not offer this exceptional feature plugin. – Ray

3 Answers

11
votes

I would highly recommend using Jenkins - it will do all of your requirements out of the box apart from possibly #3, but if you can script your deployments then it can do that as well.

Here are some links to help you get your builds up and running:

Blog about doing .NET builds in Jenkins

Jenkins Windows installers

Installing the Jenkins master and slaves as Windows services

Disclaimer: I have no experience with TFS, but I think open solutions are nearly always more flexible and extensible (and cheaper !) than proprietary products.

8
votes

Late to this game, but I have used both TFS 2010 and Jenkins for CI. TFS 2010 has minimum set of CI tools in it. However, when you want to create a CI pipeline, it's a completely different story while Jenkins can easily create the pipeline.

If you are looking at only CI for one build either one should work. However, when it comes to the entire pipeline, Jenkins is way to go. With TFS it can be done, but Jenkins is better choice.

Here's quick bullet points:

TFS:

  • With a build definition you can compile, execute tests, return changeset/workitems, send an email when a build is broken

  • natural integration with visual studio

  • extremely hard to create CI pipeline. Requires custom handler and extensive workflow work. Not as intuitive as creating a build definition.

  • Because of the 3rd bullet, it's not easy to maintain/customize/scale CI pipeline

Jenkins:

  • Need to create a msbuild config file for CI, which is not much pain comparing to creating CI pipeline using TFS. However, TFS gives better/easier tool to create a build definition. however, it is not bad creating config file for msbuild for a project.

  • Creating a CI pipeline is very easy. Just chain them using upstream/downstream jenkins job trigger and passing an artifact from previous job.

  • Since Jenkins is very flexible, it is easy to create a jenkins plugin to meet your own needs and provide it to opensource community :)

In summary, if you need complete automated build, test, and deployment system go with Jenkins. If you just need only build and test, TFS might give you an edge over Jenkins.

1
votes

If you're using Team 2010-2012, there is no reason whatsoever to bring in Jenkins. Team has all the features you listed, and the build process is ridiculously flexible.

Note that if you are stuck on Team 2008 or earlier, you should seriously look at Jenkins -- 2008 and earlier are quite primitive and inflexible compared to 2010 or later.