21

There are quite a few different Continuous Integration (CI) frameworks out there and I'm wondering which is the most popular. Which frameworks have you used at firms where you work?

Is there any reason one CI framework is more popular than another - perhaps this is to do with the features it offers, things that integrate into it or maybe its just marketing?

It seems like continuous integration is used more in the Java and .net worlds than say ruby or python. Why is this?

Improve this question
  • One of the reasons why CI is not such relevant with Ruby and Python is that the languages are interpreted, so no need to compile anything. But that's only my personal opinion ... – mliebelt Dec 11 '11 at 10:59
  • 1
    @mliebelt --CI expands to more than just compile checks. You can run unit/integration tests (even with other dependent projects). – Apoorv Feb 2 '13 at 9:58

11 Answers 11

Active Oldest Votes
31

Hudson or Jenkins (the latter is a fork of the former). Reason: It is simple (simple to install and to use) and has great flexibility. The plugins add nearly every functionality I can think of.

Some years ago I used damagecontrol. It was also simple to use, but hadn't the plugins. But the author decided that he would give up on the simple solution and started development of a new version, that consisted of different servers communicating with each other (what the hell?). That didn't worked well and the project was given up. I was on the search some time, but neither cruisecontrol (too complicated) or continuum really got me. Until hudson, that worked from the first moment for me.

Improve this answer
  • I'm going to add a decent UI to this as well. – Martijn Verburg Dec 10 '10 at 17:30
  • Yes, I would sum up the UI under simple to use. – Mnementh Dec 10 '10 at 17:33
  • 5
    CruiseControl was a pain to get going... Hudson was so easy to get up and running. The Chuck Norris (wiki.hudson-ci.org/display/HUDSON/ChuckNorris+Plugin) plugin is a must. – Sam Dolan Dec 10 '10 at 18:04
  • Hudson is really great. Though, I do wish it was better at isolation. If you have a good number of different teams all working on loosely related projects, the potential for stepping on each other's toes is kind of high. – Greg Gauthier Dec 10 '10 at 19:44
  • This programmer still can't configure Hudson to work on Windows :( – Mchl Jan 13 '11 at 20:12
16

I use TeamCity at work and at home. It has great support for a variety of build runners and is extensible via plugins.

Not dealing with piles of XML for configuration is a huge plus in my books and the free version is sufficient for my home needs.

One problem I ran into with TeamCity has to do with trying to get it to automatically version .NET assemblies. I had to set up a relatively complicated workaround, but once it was in place, it worked like a charm.

Improve this answer
  • Im going to try TC at home. We have had nothing but problems with cruisecontrol.net. – Nobody Dec 11 '10 at 2:00
8

Personally, I've only ever used CruiseControl and CruiseControl.Net. The reason for this has to do with economics. They are reasonably stable and once you set them up, there really is little you need to do to maintain it. The user community is usually very helpful, and it can be extended to your needs.

That said, there are a couple commercial offerings available that I am aware of (one by JetBrains, the other by Atlassian) which offer a better set up experience and commercial support. I've been meaning to try these offerings but really haven't had a chance yet.

CI tools have a more important role to play with compiled languages than interpreted languages, but that isn't to say that the CI tool is wasted on interpreted languages. When you have several projects that depend on each other, and you want to make sure a change doesn't accidentally break it's dependencies--CI tools are invaluable.

There's three general classes of problems that CI tools can help you catch:

  1. Compile errors -- if the signature of a class changes in a way that breaks dependencies, it's best to know about it before the waining hours of a deliverable.
  2. Logic errors -- if the behavior of a class changes in a way that breaks dependencies, it's best to know about it early. This has to be checked by some sort of automated testing, most commonly unit testing.
  3. Acceptance Testing -- if you have an automated suite of tests to run on the finished product, it's best to run them often.

Interpreted languages are not compiled, so there are no compilation errors to catch. However, the other two problems are common enough that CI tools are useful for projects in Ruby/Python/Perl/etc.

The key word in both the logic errors and acceptance testing points is "automated" testing. If you don't have a suite of tests a machine can run, then you really are missing the greater benefits of CI tools. Automated suites can be built up with time, so you can start small.

Edit

See this nice chart for feature comparisons of a large number of CI Tools (many of which I didn't know about):

http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix

Improve this answer
  • The compiled/interpreted distinction is not so black and white. For example, Perl has a compile phase that runs at startup (and can be invoked separately with the "-c" option) to check for any syntax errors. – nobody Dec 10 '10 at 19:11
  • This is true. Ruby 1.9 and Python also have compile phases. Compile Error class of problem applies to any language that will alert you if the reference class/variable/method does not exist during compilation. It definitely applies to any statically typed language. YMMV on dynamic but strong typed languages (like Ruby and Python). – Berin Loritsch Dec 10 '10 at 20:01
  • "once you set them up, there really is little you need to do to maintain it" -- isn't that true of all continuous integration servers? – Bryan Oakley Dec 11 '11 at 14:47
5

Team Foundation Server

Solid CI, tight integration with Visual Studio, and Git as the version control. I've seen more flexible CI Servers, like Hudson, but TFS's tight integration with other products makes the experience so seamless that it just makes sense for my team.

Improve this answer
  • By 'other products', you mean 'Microsoft products'. I'm not critising you, but MS have structured their tech stack so that in order to integrate with MS products, you need other MS products, or a lot of patience and/or perseverance. – GKelly Nov 21 '11 at 11:43
  • 1
    Utter nonsense. They have APIs and SDKs for almost everything they make, even the Kinect, but non-MS programmers don't know, because they cover their ears as soon as they hear Micros.. (link to TFS SDK) msdn.microsoft.com/en-us/library/bb130146(v=VS.80).aspx – Luke Puplett Dec 21 '12 at 22:08
2

I use both CruiseControl.NET and Hudson. Some of my builds are on one of them and some are on the other.

Why? Because I am not the build engineer and he who is the build engineer set them up this way!

I don't have a problem with the way my builds are set up or complaints about either product. I'm reporting to you the way the things are here, matter-of-factly and hope you appreciate this perspective!

UPDATE: Since I posted the answer, Hudson has been forked and became Jenkins. The above recommendation applies to Jenkins.

Improve this answer
1

Pulse. It basically Just Works, which for a busy build engineer is a big deal. They also have really excellent technical support. The main reason I love it so much is that we have 250+ projects and it handles them without a hiccup; I cannot say the same for Hudson.

Improve this answer
1

Our team works mainly in Python, C++ and Java. We use Buildbot for CI. We initially got started with it because it integrates with Trac and because it seemed simple and straightforward. I believe it is the CI framework of choice in the Python world.

Improve this answer
1

Hudson. It's a little buggy at times, and some of the more interesting plugins don't actually work, but with a little handholding it's pretty usable.

I'd probably use Pulse instead, but if you need to build on multiple platforms it's >$5k, which is a bit much.

Improve this answer
1

CruiseControl.NET for continuous integration. Works pretty well, although with the very large number of build project we have set up in CruiseControl, the CCTray desktop tray app is horribly non-responsive, even with long refresh intervals.

NAnt is for the build scripts that get executed in the CruiseControl projects. For more complex build scripts, we've extended NAnt with custom C# NAnt tasks, which is very nice - writing code in C# is much more enjoyable than creating NAnt scripts.

We're a Microsoft shop and theoretically will be moving to Microsoft's Team Build 2010 once we migrate our Team Foundation Server environment to 2010.

Improve this answer
0

Note that you should be able to build your application from the command line regardless of you have a CI-engine running or not.

This means that all the CI-engine does is systemizing your build invocations, and you can choose the engine that fits your particular needs best.

PErsonally I like Hudson primarily because it "feels" nice, but I know that if all fails I can switch to another one without too much effort. If so, I would probably first investigate the one made by Atlassian, since I like the "feel" of the other programs they make.

Note that the interchangability implies that it doesn't matter what language they are written in. I believe Java was chosen for many engines because the many platforms supported, combined with the many building blocks easily available. Need a web server - grab one. Need many concurrent threads - just use them. Need extensibiility - drop in a jar.

Improve this answer
0

Before I ever heard the term "continuous-integration" (This was back in 2002 or 2003) I wrote a nightly build script that connected to cvs, grabbed a clean copy of the main project and the five smaller sub-projects, built all the jars via ant then built and redeployed a WAR file via a second ant script that used the tomcat ant tasks.

It ran via cron at 7pm and sent email with a bunch of attached output files. We used it for the entire 7 months of the project and it stayed in use for the next 20 months of maintenance and improvements.

It worked fine but still prefer hudson over bash scripts, cron and ant.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.