Jenkins has served as a continuous integration (CI) tool long before the emergence of Kubernetes and distributed systems running on cloud native platforms. Working with Jenkins as a stand-alone open source tool — as developers and operations folks will be the first to say — can also be extremely difficult.

Now, more recently, the shift to cloud native and Kubernetes poses even more Jenkins management-specific challenges for organizations. As a result, Jenkins X has emerged as a way to both improve and automate continuous delivery pipelines to Kubernetes and cloud native environments. For many, however, there is a concern about compatibility between Jenkins and Jenkins X pipelines. And the role of each is also a worry expressed in forum posts and comments on Reddit and other outlets.

Indeed, understanding the role of each, the changing landscape of Jenkins, as well as the role CloudBees — the commercial distribution of Jenkins — plays, as enterprises continue to work with pipelines for on-premise, cloud native or a combination of both types of deployments, has also served as a source of confusion.

The short answer is that Jenkins X is indeed geared for Kubernetes deployments — but that does not mean it necessarily needs to replace existing Jenkins configurations, at least in the immediate. Nor does that means Jenkins X is unable to manage Jenkins pipelines for on-premise or non-cloud production pipelines. Meanwhile, CloudBees is applicable for both. Hence lies the source of difficulty in understanding the roles each can play.

“It’s quite a leap for the people to understand — basically, we see lots of confusion. Plus a lot of things are changing and we see [even more] confusion,” James Strachan, senior architect at CloudBees, the project lead on Jenkins X, said. “ And inside CloudBees and with our customers there’s a lot of misunderstanding out there. I hope we can make this a little bit clearer. I think it’s supposed to be shown, for example, you can use Jenkins X to orchestrate Jenkins.”

In many ways, confusion exists “almost every time you rename well-known software projects,” Torsten Volk, an analyst for Enterprise Management Associates (EMA), said. “Remember the outcry when Docker renamed the community version of its software to Moby? Here the issue was that CloudBees first came up with the Jenkins Enterprise and CloudBees Suite product names, where Jenkins Enterprise already started supporting containers,” Volk said. “Then wrapping all this mess into the CloudBees Core offering was always going to be hard, but had to be done.”

The idea now is to blend the classic Jenkins world and the Jenkins X world into one experience “so that it really doesn’t matter” if an organization, for example, were to combine Jenkins servers for serverless and automated pipelines and, for example, on-premise deployments with a single user interface (UI) and command line interface (CLI),  Strachan said. “Both of these use cases are solved since some teams are using both, right?” Strachan said. “Some teams are building new microservices but they still have that classic VM.”

Strachan did not come out and describe Jenkins X as “Jenkins 2.0.” However, the hope is that Jenkins X, following its relatively recent release, will eventually cover the bases of all Jenkins pipelines, both classic and for Kubernetes. “I think, we’ve not really gotten the message out to the community quite well enough: Jenkins X is really how everyone will use Jenkins at some point,” Strachan said.

The Use Cases

On the surface at least, arguments to adopt Jenkins X for production pipelines for Kubernetes makes obvious sense. As the Jenkins X authors define it:

“Jenkins X is a CI/CD [continuous delivery] solution for modern cloud applications on Kubernetes … Jenkins X provides pipeline automation, built-in GitOps and preview environments to help teams collaborate and accelerate their software delivery at any scale.”

For those starting a new greenfield project “and you have no CI, you just go straight to Jenkins X and that’s easy — you just automate all that stuff and you’re done,” Strachan said.

But outside of the usage sphere of cloud native-only pipelines, things can get murky — at least from the outset. It is still not readily apparent in the minds of many, for example, that Jenkins X is also designed, as mentioned before, to serve those organizations with on-premise production pipeline-only needs — whether they eventually decide to deploy to cloud native platforms or not.

Most of the organizations Strachan said he has spoken with already have Jenkins set up for pipelines and want to extend them into Jenkins X. “You could just go and say “hey, let’s just try Jenkins X to automate all of our pipelines,” Strachan said. “And it might be better for you… But really long term, we want to get rid of those Jenkins files you wrote by hand because we think our pipelines can do better.”

During the months that have followed the final production release of Jenkins X, the tools are seen as doing a good job of merging GitOps concepts and leveraging Kubernetes as the orchestration and target platform, Ravi Lachhman, a technical evangelist for AppDynamics, said. “By leveraging Kubernetes as the platform to run Jenkins X on, the CI/CD solution can be much more robust in resource placement e.g. worker nodes and availability.”

At the end of the day, “no matter what the open source platform is, each organization is different when considering build vs buy,” Lachhman said. “CloudBees provides a lot of expertise in their domain/stack and offering capabilities in scalability, security and support. For teams that are versed in GitOps, Jenkins X is a modern prescription for running a CI/CD stack on Kubernetes,”  Lachhman said. “The Jenkins family continues to evolve as the backbone of many DevOps pipelines and continues to evolve with the push into cloud native architecture.”

“CloudBees is a commercial open source software company, which writes the vast majority of Jenkins code. These sorts of structures are by no means uncommon in commercial open source,” James Governor, an analyst for and co-founder of Redmonk, said. “Jenkins is a more well-known brand than CloudBees, but again that is very common in these situations, where open source distribution gets far ahead of commercial customer acquisition.”

Strategy Revealed

CloudBees has drawn $112 million in capital since 2010 and therefore needs to reach terminal velocity sometime soon, Volk said. “They managed to sign up hundreds of paying customers for their various Jenkins support offerings, but at the same time they need to pay great talent like James Strachan who is one of the main contributors across the Jenkins and Jenkins X projects,” Volk said. “And, of course they need to support lots and lots of Jenkins integrations with every piece of infrastructure and middleware under the sun.”

The Jenkins X project was also necessary to not get behind the competitions, such as Xebia Labs, Atlassian and Electric Cloud in terms of Kubernetes support, Volk said.

“That’s why they decided to roll Jenkins, Jenkins X, Codeship, and their DevOps analytics product into one DevOps management platform that spans the whole enterprise,” Volk said. “What they now need to do is evangelize the heck out of CloudBees Core and explaining their involvement in Jenkins and Jenkins X — this is difficult.”