New Early adopter or innovator? InfoQ has been working on some new features for you. Learn more

CloudBees Releases Jenkins Enterprise

| by Kostis Kapelonis on Dec 20, 2011. Estimated reading time: 6 minutes |

CloudBees has announced Jenkins Enterprise, a commercial version of the open source continuous integration server that is aimed at companies with big Jenkins installations.

The Enterprise version focuses on:

  1. Technical support available 24/7 on a global basis.
  2. Extension of Long Time Support versions from 3 months (community supported in the open source version) to 12 months (in the Enterprise version).
  3. Extra proprietary Jenkins plugins useful to companies with large scale Jenkins installations.

CloudBees employs Koshuke Kawaguchi who lead the development of the original Hudson before the split. In addition, several CloudBees employees are Jenkins committers. So while other companies may offer professional Jenkins support, CloudBees clearly has deep expertise on Jenkins internals.

Another feature of Jenkins Enterprise is less frequent updates for those companies that request it. The original Hudson had a very busy release schedule. Jenkins continues this trend and new versions might come out even weekly. While this pace shows healthy development and solid interest, it does not fit very well companies that need stable, long lasting releases. Several companies keep private branches of the Hudson/Jenkins code for stabilization efforts.

To address this issue, Jenkins introduced LTS versions (similar to Ubuntu Linux) that happen every 3 months. This service is offered by the open source version. Jenkins Enterprise extends the 3 month window to 12 months. Companies who wish to do so, can select an LTS version and keep it up to a year knowing that they will still get all the important updates (e.g. critical security fixes).

The most user visible addition to Jenkins Enterprise compared to the open source edition is a set of plugins that solve issues encountered in big Jenkins installations. At the time of writing these plugins are:

The Templates plugin may be useful to many companies (regardless of Jenkins installation size) because it addresses the problem of similar jobs. Several times developers create jobs which have the same settings apart from a single detail such as the branch of the source control system, the post build step, or the Maven profile used. Having to define these jobs manually is cumbersome because a later change cannot be easily applied to all jobs automatically. Creating new jobs in a copy-paste manner from existing ones is an error-prone process. Capturing "sameness" of jobs is such an important characteristic that Oracle has decided to include it as a major new feature in Hudson. Hudson recently released version 2.2.0 that supports Project Cascading (available in the open source version).

The rest of the plugins are clearly aimed at large Jenkins installations with a lot of projects/jobs which may exist outside the intranet in a public facing address.

InfoQ contacted Steven Harris (formally of Oracle, now Senior VP of Products at CloudBees) for some clarifications:

InfoQ: What type of companies should adopt Jenkins Enterprise? What is the target group?

Although Jenkins is used in both large and small organizations, we expect Jenkins Enterprise to be of most interest to organizations with large numbers of servers dedicated to Jenkins. There are two reasons. First, these organizations have more concerns and can benefit most from the additional plugins, which help address security, sprawl, and optimization. Second, these organizations often have constraints on software update processes and require committed level of support. Recent data from a survey of more than 600 Jenkins users shows that 82% of respondents consider Jenkins to be mission-critical. Almost 20% have 10 or more machines servers dedicated to Jenkins, and 13% have more than 50, so we see a growing need for these kinds of capabilities.

InfoQ: Is Jenkins Enterprise aimed only at current Jenkins users or Hudson as well? Can they both use it as a drop-in replacement for their current system or extra changes are needed (e.g. in the case of Hudson)?

Jenkins is basically a drop-in replacement for Hudson, but both our support and CloudBees plug-ins are only provided for Jenkins. So, the path for Hudson users to take advantage of Jenkins Enterprise would be to take the few hours it takes to get Jenkins in place first. Then they just open the Jenkins Update Center and have access to the Jenkins Enterprise plugins.

InfoQ: Who should run Jenkins Enterprise and who should run Jenkins in the cloud (now that CloudBees offers both)?

It is possible to use both! Our Jenkins service lets companies pay only for the resources they use to run Jenkins and extends additional one-click access to source control and partner ecosystem offerings. So, it eliminates the headache of IT ops and setting up of additional resources when your Jenkins needs to grow, and you're not charged for resources sitting around when not in use. You can use the Jenkins Enterprise plugins and support using our hosted Jenkins service, too, of course. The integrated ability to stage running applications on our runtime service (RUN@cloud) also makes it incredibly easy for teams to share their work and adopt a continuous delivery strategy as part of their agile practice. Jenkins Enterprise is a great solution for organizations who are focused on improving their on-premises Jenkins. As mentioned earlier, Jenkins Enterprise helps address security, sprawl and optimization issues and every organization that manages its own Jenkins needs help in these areas.

InfoQ: How exactly is the 12-month LTS achieved? Are the same bug fixes going to appear in the community release at the same time as well? Are they going to appear at a later time (or at all)?

Fixes will be made using the current LTS, and back-ported to the previous three versions, effectively giving a year time window and making it so that people who want to stay on a particular LTS for longer than the normal three month Jenkins community cycle don't have to move versions but still get fixes. We expect that almost all fixes will end up in the community release, thereby strengthening the community itself. There could be fixes that we need to deliver to a particular Jenkins Enterprise customer that we or the community feel are inappropriate for LTS, which is aimed at stability, but we expect these to be exceptional cases.

InfoQ: What other Enterprise plugins will be developed in the future apart from those already announced?

We expect to continue to raise the bar on the three initial themes of security, large installations, and optimized execution. We also expect to address themes like reporting and failover. Also, because the community is such an incredible strength of Jenkins, we will continue to work diligently within the community simply to make Jenkins better overall, thereby raising the bar against which our Enterprise plugins have to add value.

InfoQ: Any thoughts on Hudson vs. Jenkins now that the dust has settled? How is Enterprise Jenkins different by Sonatype supported Hudson? What are the advantages over the competition?

We captured our position on this in a white paper we called Jenkins -- The Safe and Sensible Choice For Your Continuous Integration (CI) Investment. We expect Hudson to emerge from incubator status at Eclipse shortly, but the former Hudson community has pretty much voted with its feet and their commitment is to Jenkins. We will have to see if Hudson's visibility in the Eclipse community changes things. Sonatype appears to have focused their energy around their Insight product at this point, not Hudson.

InfoQ: Can you give us an indication of pricing?

Our pricing is based on the actual numbers of executors running within an organization. This pricing means that organizations pay only for resources used, say as opposed to per user based pricing. Also, as expected of any enterprise class support offering there are multiple tiers. Organizations looking to buy can contact us at this link. Meanwhile, we recommend organizations to try Jenkins Enterprise as it has a 30-day trial period. Our public cloud offering pricing is available here.

Jenkins Enterprise is available in a trial version (1 month) as a direct download. The installation is similar the open source version and this is the easiest way to evaluate the extra plugins in a running instance.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Maven 3.0 Support by Michael Kimber

Whats Jenkins Maven 3.0 support like. We have some internal debate over Jenkins and Hudson (suspect thats the case in a lot of places), with the Hudson advocates; stating a better Maven 3.0 integration due to the fact that SonaType commit on both projects and have made releases in this area. With the Jenkins advocates naming the founder of Hudson and a more active release schedule as its plus points.

Thanks Mike

Re: Maven 3.0 Support by Kawaguchi Kohsuke

Maven3 is well supported on Jenkins, long before the split has happened, thanks to Olivier Lamy and others (who are the Maven committers) As you may know, Maven support comes in two flavours; one as a launcher in free-style project, and the other as a dedicated project with a deeper comprehension. It works well with both, and I've been using it daily.

If you are still unsure which way to upgrade, you might like some of our recent stats at and

Re: Maven 3.0 Support by Kawaguchi Kohsuke

Given what said above, I don't think Maven3 support should have any real bearing on making a choice. I think a bigger question is where the community is (which translates to plugins), which is what really made this tool so useful in the first place. And I think it's pretty clear where that is now.

Re: Maven 3.0 Support by Kawaguchi Kohsuke

(reposting --- looks like something happened to my original comment)

Maven3 is well supported in Jenkins, actually long before the split, thanks to Olivier Lamy (who is a committer of the Apache Maven project) and others. As you may know, Maven support comes in two flavours --- one as a launcher of a freestyle project, and the other as a dedicated project type with a deeper project comprehension. Both works well, and I use it every day.

If you are considering which way to upgrade, I think (especially the "Update since the split" section) and stats in are useful.

Re: Maven 3.0 Support by Michael Kimber

Thanks for this, thsi is very useful

Re: Maven 3.0 Support by Michael Kimber

Not sure I totally agree on that statement, there are lots of great open source communities, but they don't necessarily meet our requirements I/we need so they are not a good fit for us. Hudson is backed by SonaType (and unfortunately Oracle who have definitely replaced Microsoft as the dark lords of IT) who also provide Nexus and Maven, which we both use. They seem to be investing in a tight integration between Maven 3.0, Hudson and Nexus, with the key feature that the Hudson advocates here (I'm on the fence by the way) site as being automatic dependency management of down stream Builds based on pom file hierarchy, rather than having to set it up manually. SonaType seem to be a switched on viable company, so whilst Hudson may not have as vibrant community its focus may fit our needs better.

All that said we have actually upgraded all our production CI servers to the latest version of Jenkins :-), but have a Hudson test rig configured to run the above feature (which pretty much comes out of the box)

Re: Maven 3.0 Support by Stephen Connolly

I need to correct you on one point.

Sonatype do NOT produce Maven.

Maven is an Apache project produced by the *individuals* who are committers to the Apache Maven project.

Apache recognises individuals in their own right.

Sonatype cannot (and to the best of my knowledge do not) claim to be a source of Maven, just as CloudBees cannot claim to produce Maven even though I am on the Apache Maven PMC.

Re: Maven 3.0 Support by Michael Kimber

Fair comment and I totally agree. A poor choice of words. Apologies.

Re: Maven 3.0 Support by Stephen Connolly

there are other points that i should make, however as a member of the Apache Maven PMC i have a duty to protect the Maven mark and my other points are as an employee of CloudBees so they can wait until after xmas ;-)

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

9 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date with curated articles from top InfoQ editors

"You dont know what you dont know" change that by browsing what our editors pick for you.