Over the past 10 years, Jenkins has really
grown to a
de-facto standard tool that millions of people use to handle automation in
software development and beyond. It is quite remarkable for a project that
originally started as a hobby project under a different name. I’m very proud.
Around this time last year,
celebrated 10 years, 1000 plugins, and 100K installations. That was a good time
to retrospect, and we started thinking about the next 10 years of Jenkins and
what’s necessary to meet that challenge. This project has long been on a
weekly “train” release model, so it was useful to step back and think about a
That is where three pillars of Jenkins 2.0 have emerged from.
First, one of the challenges our users are facing today is that the automation
that happens between a commit and a production has significantly grown in its
scope. Because of this, the clothing that used to fit (aka “freestyle project”,
which was the workhorse of Jenkins) no longer fits. We now need something that
better fits today’s use cases like “continuous delivery pipeline.” This is why
in 2.0 we’ve added the pipeline capability. This 2 year old effort allows you
to describe your chain of automation in a textual form. This allows you to
version control it, put it alongside your source tree, etc. It is also actually
a domain specific language (DSL) of Groovy, so when your pipeline grows in
complexity/sophistication, you can manage its complexity and keep it
understandable far easily.
Second, over time, Jenkins has developed the “assembly required before initial
use” feeling. As the project has grown, the frontier of interesting development
has shifted to plugins, which is how it should be, but we have left it up to
users to discover & use them. As a result, the default installation became very
thin and minimal, and every user has to find several plugins before Jenkins
becomes really functional. This created a paradox of choice and unnecessarily
hurt the user experience. In 2.0, we reset this thinking and tries to create
more sensible out of the box experience that solves 80% use cases for 80% of
people. You get something useful out of the box, and you can get some
considerable mileage out of it before you start feeling the need of plugins.
This allows us to focus our development & QA effort around this base
functionality, too. By the way, the focus on the out of the box experience
doesn’t stop at functionality, either. The initial security setup of Jenkins is
improved, too, to prevent unprotected Jenkins instances from getting abused by
botnets and attacks.
Third, we were fortunate to have a number of developers with UX background
spend some quality time on Jenkins, and they have made a big dent in improving
various parts of Jenkins web UI. The setup wizard that implements the out of
the box experience improvement is one of them, and it also includes other parts
of Jenkins that you use all the time, such as job configuration pages and new
item pages. This brings much needed attention to the web UI.
As you can see, 2.0 brings a lot of exciting features on the table, but this is
an evolutionary release, built on top of the same foundation, so that your
existing installations can upgrade smoothly. After this initial release, we’ll
get back to our usual weekly release march, and more improvements will be made
to those pillars and others in coming months and years continuously. If you’d
like to get more in-depth look at Jenkins 2.0, please join us in our virtual
Jenkins meetup 2.0 launch event.
Thank you very much for everyone who made Jenkins 2.0 possible. There are
too many of you
to thank individually, but you know who you are. I wanted to thank CloudBees in
particular for sponsoring the time of many of those people. 10 years ago, all I
could utilize was my own night & weekend time. Now I’ve got a team of smart
people working with me to carry this torch forward, and a big effort like 2.0
wouldn’t have been possible without such organized effort.
Original URL: http://feedproxy.google.com/~r/feedsapi/BwPx/~3/BMlOmDLSXU4/