Jenkins Reviews

• Extensibility
• Usability

We've achieved continuous integration and delivery on all our commits, securing the quality of all of our products on their main branches. The features used come almost out of the box.

Many of the plugins needs to be streamlined, their terminology needs to be the same and some plugins should be split into multiple smaller plugins.

Since 2010, so almost five years.

No issues encountered.

Minor, but those issues typically gets fixed after reporting them. Some issues can be addressed as pull requests, fixing them myself.

No, not after the lazy-load of items were introduced.

5/10.

5/10.

I used Hudson before, so the switch was quite natural.

In-house implementation.

My colleagues and I did the setup, so only the hours we spent doing it.

We also looked at Buildbot.

Just go for it. It's simple and intuitive.

I can build slaves and extensions through plugins.

Automation in general has been improved.

Provisioning of VMs during deployment.

Five years.

Provisioning VMs during deployment was an issue.

No issues encountered.

No issues encountered.

Not needed.

Not needed.

We previously used Hudson, and CruiseControl.

Initial set-up was straightforward.

We implemented in-house.

We compared Jenkins to CruiseControl.

It works.

Open source community with many plugins & flexibility as an automation platform.

Rather than send emails and tickets around we can hand out "buttons" to teams so they can do self-service for actions that used to involve manual effort from the Operations group.

Polish for the user interface, stability of plugins beyond the very most commonly used ones.

Over seven years.

No issues encountered.

No, although in some scenarios memory use can bloat over time.

Not directly, but because of our overcomplicated networking setup we had to spread over multiple Jenkins masters each with a set of nodes.

Open source version, but have occasionally asked a quick question in the IRC channel and sometimes get a clue or two.

Open source version, but have occasionally asked a quick question in the IRC channel and sometimes get a clue or two.

We started with Bamboo, but it wasn't flexible enough (at the time) to also be used for general automation (code deployments, application restarts, etc). Really we might have just expected too much of it.

Easy. Drop in .war file, and restart the Tomcat server.

In-house.

Hard to say. Although it was free, so infinite.

Free. Takes some work hours of course, but those come back many fold in improved productivity through automation.

No, we picked a long time ago before there were a lot of alternative options on the market. The few others available were expensive. Jenkins (well, Hudson at the time) was free!

Do it! There's really no way you can lose. Even if you decide Jenkins isn't for you then you only spent work hours that helped train your staff and create reusable scripts that can be applied in other tools just as well.