Choosing continuous integration (CI) tool. Comparison : CruiseControl, Hudson, Continuum vs. TeamCityBy neokrates, written on April 2, 2010
You are choosing the CI solution for your firm. There is a bunch of open source CI tools, and they are all good. So, is there a reason for your company to go with professional CI and pay for it handsomely?
This article has become a kind of TeamCity against the pure Open Source discussion. And if after reading it you choose the open source, you will still need to decide which CI is good for you. So, check the feature lists and maybe talk to contractors to choose wisely.
Open source: CruiseControl, Hudson, Continuum
What ALL this tools have in common?
- basic CI process works good (what a surprise );
- some build triggering options. (Time controlled, or triggered by previous build);
- many “build runners”. You may build maven or ant, bash or ivy. All this support major builder. Although check the supported list first. Newer or exotic builders may be not supported or just don’t work properly;
- basic or advanced web interface;
- some VCS support. Integration with SVN, CVS, GIT, etc…
- mostly good usability. Most of Hudson and continuum can be configured through web GUI, CC is easier to configure through the central xml configuration file;
- build logs and metrics. All tools have it, but TeamCity tends to give you more options to extract relevant info…
- simple install. Basically, those are webapps, so installing them is like putting new __war file_ under tomcat or jetty;
- remote API. Want to use Java or RPC to interact with your CI? “Yes, they can.”
- feedback and notifications. Email is supported by all tools. There is limited support for IM, but it may change;
- plugins, extensions. Hudson and Cruise Control. Both have many plugins made by community. TeamCity has many plugins provided by JetBrains. Continuum plugins seem to be scarce this days
Advantages of TeamCity
- distributed build. Hudson and TeamCity do support distribution. TeamCity has some more options. So, just a tiny here;
- professional support. There is a dedicated firm (JetBrains) with skilled professionals. Hence, you can expect consistent code, good documentation etc…
- And if you buy the licenses, you can request new features and plugins just for your special case.
- build from multiple VCS roots. One build, many repo locations;
- many advanced options, largest feature list. Example: it is not important for you if you don’t need Skype notification. But if you do, that may spare you weeks or more if this feature just happens to be already there. If not, JetBrains will make it happen (only if you are a customer);
- large enterprise needs permanent partner. You cant expect the open source community to be your permanent partner. Yes, you can hire some contractors near to those projects, but it might be not enough if you are a big company.
Drawbacks of TeamCity
- too much for basic projects. You need the system which can checkout and build some Java projects, and then show you the status or your builds? You don’t need TeamCity to do that, and you definitely don’t need to pay for it to get simple job done;
- useless if open source can all what you want. Project, in which the expected CI features are known and will rarely change. If you know that hudson or CC can do it, just get some contractor and let him setup it once. You don’t need TeamCity, that gives you nothing you cant have from open source CI. And having just one contractor will reduce your costs dramatically;
- large projects, price will become a problem. Do you have 50+ developers, partner firms, complex agile infrastructure with testates and staging? Then, you will end up with the perfect solution which you probably can’t afford. The thing is, with TeamCity you will pay pro additional ‘agents’. And even large enterprises can’t afford to spend lots of money every month just to be able to build own software;
- no open source community. With open Source tools you have many sources of information. With TeamCity, you main partner is JetBrains and if it fails to support you, you are on your own. Each time you want a new feature from the TeamCity, you will basically have to read the support agreement. Maybe you have a wrong setup, or some custom plugin and now nobody but yourself can help you. No big forums, no tweakers, you are on your own.
Choose TeamCity if …
Does many of the following apply to your case? If yes, then you probably need TeamCity:
- you are middle to large company;
- you have enough money to spend on CI. Not only now, but in the future as well;
- you need guarantees, that you CI works perfectly any time;
- you need the newest features;
- you expect most of the options, maximum flexibility and usability;
- you builds are distributed with some custom setup;
Go with open source if …
If the list below describes your problems better, you might want to use open source CI:
- you have basic requirements;
- one of open source products meets your requirements. You don’t expect that requirements change dramatically in the future;
- money is a problem;
- you have a team of skilled builders and and/or release manager;
- you have huge build-chain, huge numbers of artifacts, etc. Don’t take TeamCity. Yes, it can handle the problem. But it will cost you big time. Try Hudson. It has limitless scalability and costs zero;
- you don’t want to be limited by the support, JetBrains gives you. If you have lots of good coders, they might ask you why do you wait a week for the feature which will take 5 minutes to code. And the answer is “because we loose the support for this TeamCity instance otherwise”. Well, in my experience, it is not the most popular answer.
LEARN MORE (amazon bookstore)
INCOMING SEARCH TERMS