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, we’ve 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 big picture.

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 more 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 tried 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. Improvements will be made to those pillars and others in coming months and years continuously. If you’d like to get a 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. Ten 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.