CloudBees sponsored this post, which was written independently by The New Stack.
We all get how the explosion of open source tools gives DevOps teams an unprecedented freedom of choice for cloud native and on premises application development and deployments. However, this abundance of options poses an abyss of freedom — among the pitfalls are difficulties finding the right toolset and processes that fit the specific needs of your organization, given the wide range of alternatives to choose from.
For organizations assessing and testing tools, especially for cloud native deployments, there are a few fundamental ways to either get started or to streamline your legacy tools and processes for faster and more robust continuous integration and continuous delivery (CI/CD). This also applies to those organizations that plan to retain their bare metal server operations, either on premises or in the cloud.
In this article, we look at how open source Jenkins X, geared for cloud native, as well as for existing legacy application deployments, can automate CI/CD throughout the production and deployment pipeline. Designed to automate a range of pipeline types organizations might adopt, Jenkins X is also applicable for both Jenkins and Tekton, Google’s recently created framework for cloud native CI/CD.
“Generally speaking, the idea is for Jenkins X to offer automation across the board to help developers go faster, and remove as much of the undifferentiated heavy lifting for pipelines and their libraries as possible,” James Strachan, senior architect at CloudBees and the project lead on Jenkins X, said.
We also take a step back by providing an overview of how organizations will soon be able to take advantage of the frameworks and guidance the Continuous Delivery Foundation (CDF) will offer. In this way, DevOps can rely on the CDF to better navigate the Wild West of available tools and platforms for a wide range of deployment structures.
Why Jenkins X Means Automation
Jenkins X serves as a way to orchestrate production pipelines on cloud native platforms that usually consist of microservices and Kubernetes. Since it is also compatible with existing Jenkins pipelines, Jenkins X is much more than an extension of Jenkins for cloud native deployments.
Jenkins X sits on top of existing and future execution engines in addition to Jenkins, and can extend to Tekton Kubernetes pipeline tool, for example. The idea behind Jenkins X is for it to stave off much of the complexity of developing cloud native applications with Kubernetes, as well as the confusion and worry about getting locked into specific toolsets and associated infrastructures. Of course, you can also automate and improve CI/CD processes.
In addition to serving as an orchestration tool for whatever CI/CD implementation an organization might choose, “Jenkins X raises the bar for ease of use and abstractions,” said Kohsuke Kawaguchi, chief scientist for CloudBees, the company overseeing the management of Jenkins X.
“The open source ecosystem is messy, as a lot of new technologies continue to crop up. Developers, when deploying applications, don’t have time to figure everything out,” Kawaguchi said. “The idea is for developers to focus on higher-level concepts while Jenkins X enables Jenkins or Tekton to do the behind-the-scenes work.”
The automation is apparent from the outset. With a single command, it is possible to deploy applications on cloud native platforms without having to directly configure Kubernetes clusters and requisite YAML files, for example. As Strachan described in a blog post, the main beauty of Jenkins X is that it automates the work that developers would otherwise have to do manually. This includes automatically packaging code as Docker images, creating YAML files so the code can run on Kubernetes clusters and the preview environments, and implementing CI/CD pipelines with declarative pipeline-as-code Jenkinsfiles.
“Jenkins X is essentially focused on allowing people to make microservices on Kubernetes and automating all this so the developer does not have to manually code CI/CD pipelines and Jenkins files,” Strachan said.
Ideally, DevOps teams can rely on Jenkins X to spend more time doing higher-level — and certainly more intellectually fulfilling — tasks than managing different declarative pipelines.
An organization, for example, might use Jenkins X for a Jenkins execution engine pipeline for certain cloud native deployments, while also orchestrating a Tekton layer on another platform. In addition to cloud native deployments, the DevOps team might have Jenkins pipelines to manage on premises, bare metal deployments. Additionally, it is not uncommon for an organization to have over 1,000 Jenkins masters to create virtual machines as well as mainframe applications.
Conversely, another organization may seek to deploy an application it has created and mainly wants to deploy on a purely cloud native platform as fast as possible, with the cheapest cost-build model available.
With Jenkins X and CloudBees’ service-support business model, both of the above scenarios would be accommodated. CloudBees is “focusing on everybody in the spectrum,” Strachan said.
“We’re trying to bring everyone forward and are trying to use as much of the automation for everyone. While at the same time, we’re trying to use as little technology as we can, because the more tech you have, the more you have to manage,” Strachan said. “We’re trying to simplify the tech stack to also offer higher quality and higher value software. That approach also makes it easier for us to maintain, as well.”
As another way to stave off what many DevOps teams see as confusion among the very wide gamut of open source and platform choices, the CDF is intended to help introduce processes, standards and other support and stewardship for DevOps teams seeking guidance for toolsets, standards and processes.
While there have been concerns expressed about potential overlap with the Cloud Native Computing Foundation (CNCF) — another Linux Foundation-managed project — the CDF is especially geared for those teams that plan to or already rely on Jenkins, Jenkins X, Spinnaker and Tekton for their production pipelines. Announced earlier this year, the CDF isn’t yet ready to begin releasing specifications and primitives. Until then, the foundation is helping to foster integration between Jenkins, Jenkins X, Spinnaker and Tekton, as well as other options.
Dismissing the effects of potential overlap with the CNCF, Kawaguchi said the CDF should help organizations to have a clearer understanding of what combination of toolsets works best for them. “I see the CNCF and the CDF as complementary,” Kawaguchi said. “The overall impact of the CDF will be to help organizations transform themselves.”
In the immediate future, the CDF will seek to create “huge amounts of integration between testing, development, code coverage-reporting and deployment tools,” Strachan said. Already, the CDF has “dramatically increased” collaboration between the Jenkins, Jenkins X, Spinnaker and Tekton communities, Strachan said.
“I see these just accelerating perfectly and there are more projects to come along,” he said. “Because of the close collaboration already between Jenkins, Jenkins X, Spinnaker and Tekton, this is going to encourage other projects to take part — but basically, this integration layer is happening, right now.”
In many respects, the CDF will help guide developer teams through “where to start, because that’s the other challenge,” Strachan said. “We’ve got four things today, and next year, we might have 10 things and I also hope we don’t go CNCF where there are 5,000 things,” Strachan said. “We want to help guide people through the journey because there’s so many technologies out there and it can be mind boggling to know where to start.”
With “Transform and Deliver” as the main theme, organizations can learn more about how Jenkins X and the CDF can serve as the underlying building blocks for CI/CD by attending DevOps World | Jenkins World 2019 (San Francisco, August 12-15, 2019). The conference’s high-level and nuts-and-bolts talks as well as hands-on workshops are geared for newcomers as well as for DevOps teams with mature on-premise and cloud native deployments already in operation.
The Cloud Native Computing Foundation and the Linux Foundation are sponsors of The New Stack.
Feature image by Susan Hall.
The New Stack is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.