Jenkins World is a two-day conference held specifically for IT executives, DevOps practitioners, Jenkins users and partners.
This year, I attended the conference in Nice, France. Jenkins World has traditionally always been held in San Francisco, but this year it expanded across to Europe with the additional conference admitting more than 800 attendants. Due to the success of the first European conference, another has been scheduled for next year—taking place in Lisbon.
The event was sponsored and driven by CloudBees, the company behind Jenkins (in fact, the creator of Jenkins, Kohsuke Kawaguchi, is CTO of CloudBees. A few big names attended, such as Amazon, Google, Microsoft, Docker and VMWare. There was also a great presence of the Jenkins OSS community.
While Jenkins has been around for more than ten years, its roots can be traced back almost 15 years, so it was created in a completely different landscape compared with today’s technology and industry practices—for example, there were neither cloud nor Agile methodologies back then. In 2014, the then-called workflow plugin (later renamed to Pipeline) was introduced. It was a disruptive change, as there was no direct compatibility between old-style pipelines (that were, and still are available) and new pipelines. I remember being very critical at the time, since it was quite bugged and a somewhat incomplete function, (even in 2016 when Jenkins 2.0 was announced) so I wouldn’t have recommended migrating to Jenkins pipelines at that point. However, I was proven wrong and it evolved well. By mid-2017 it was production ready, so we started a successful migration at Ebury later that year.
Note that we are talking about three years of evolution to have a usable pipeline, which is a considerable amount of time. In fact, during this time other pipeline solutions, like CircleCI and Bitbucket Pipelines managed to be built from scratch and launched. However, this last year has been a year of wonder for Jenkins, with lots of amazing initiatives crystallizing for pipeline and beyond. All of this was presented at the Jenkins World conference in a quite well structured way:
With Declarative Pipeline Syntax and multibranch and organization jobs, Jenkins made a step forward in the last couple of years. Pipeline as Code continues being the backbone of the project, and that’s good news.
Configuration as Code
Although Pipeline as Code helped us a lot with job configuration, and the different cloud plugins also helps configuring slaves/nodes… when it comes to configure the Jenkins instances that instrument all that, it’s still really painful, and this tool comes to fill that gap.
We’ve been waiting for something like this for a long time, and thanks to Praqma and Ewelina Wilkosz, it’s finally here. It’s important to note that while this has not come from Cloudbees or Jenkins core, it has now been embraced as part of Jenkins core. It just looks awesome. We’re really excited to start configuring our instances this way.
This project is about Jenkins out-of-the-box experience. Think of it as a Linux distribution, a complete set of plugins thoroughly tested together for functionality and security, bundled with a Jenkins LTS version.
Of course, it will reduce flexibility in some scenarios, but quoting Michaël Pailloncy, we used to install the latest Jenkins versions instead of LTS when we were young… but we don’t do it anymore, and the same may apply for the huge collection of plugins we use day-to-day.
Cloud Native Jenkins
Along with configuration, another long lasting pain in Jenkins’ administrations has always been infrastructure for the master instance, particularly when it comes to storage. It also weighed the possibility of true high availability (HA) for Jenkins master. This is by far the less polished of the superpowers, exemplified by the fact that it is a Special Interest Group and not a Project.
Continuous integration and deployment for Kubernetes in an “opinionated” way. This means it’s only for Kubernetes, and it enforces a certain way of working. Quite far from the extraordinary flexibility that has characterised Jenkins. As Koshuke explained, it acts like a train with a fixed destination (i.e Kubernetes) and fixed rails… but it’s a really comfortable and fast train.
Kubernetes has been a topic of discussion in almost every talk, as it’s now seen almost as a standard for microservices architectures.
An other interesting topic at the conference was the “Jenkinstein”. Over the time, when Jenkins instances start to grow in usage in organisations, they sometimes tend to grow in uncontrollable ways, essentially becoming monsters that need more and more dedicated work maintaining them.
These ‘superpowers’ will help developers and Jenkins administrators to fight these “Jenkinsteins” monsters. At Ebury, we’ve taken advantage of everything included in Jenkins 2.0—over the last year we’ve managed to remove all the mess in jobs creation, linking and configuration. However, we still need some puppeting when it comes to the operations side, and we will for sure also take advantage of Configuration as Code and Jenkins Evergreen projects.
Enjoy Jenkins and automation, and remember two quotes I have learnt over the last two days:
- “If you automate a mess, you get an automated mess”
- “Never send a human to do a machine’s job”