When to use Jenkins vs. Jenkins X for pipeline automation

Source:-searchitoperations.techtarget.com

Three primary factors — flexibility, Kubernetes adoption and the need for a GUI — should shape an organization’s decision between Jenkins and Jenkins X as a pipeline automation tool.

DevOps teams can use Jenkins or Jenkins X to automate CI/CD pipelines — both versions of the tool get the job done, but there are important distinctions between them.

Not every DevOps deployment is the same. Some IT organizations use a vast array of source code management, software build and deployment tools, with an accompanying range of steps to move code to production. Others have a goal of simple, fast and effective code pipelines without specific custom setups. Let’s review the core use cases, benefits and limitations of Jenkins vs. Jenkins X to enumerate the main considerations for DevOps teams.

Overview of Jenkins

Jenkins, an open source continuous integration (CI) tool, automates software builds, testing and deployment.

Jenkins is a well-known and real-world-tested CI tool. Jenkins is not one step in the software delivery life cycle; it is an automation technology for many steps of the process. IT organizations can use Jenkins to automate just a few steps of code delivery, or a complex chain of events from development through operations.

Its flexibility in configuration means Jenkins can support a wide variety of application and infrastructure delivery scenarios. This flexibility comes from a range of plugins to integrate with other tools for steps such as build management, source code management and more. For example, a DevOps team building a multi-branch project can set up plugins for Atlassian Bitbucket and Artifactory for source code, then invoke Microsoft PowerShell scripts to run a build, and even trigger the software build to deploy to a testing environment in AWS. DevOps pipelines rely on this kind of tool integration to smoothly advance a project from build to test to delivery and deployment.

Jenkins also has a GUI that admins can use to manage infrastructure and jobs visually, with error checks.

Overview of Jenkins X

Jenkins X started as a Jenkins sub-project titled “Jenkins X: Jenkins for Kubernetes CD,” where CD means continuous delivery. It is geared toward managing the Kubernetes container orchestration system, but Jenkins X isn’t limited to only this task. Jenkins X can automate software builds comprehensively, atop the Jenkins engine, throughout the DevOps pipeline. To compare Jenkins vs. Jenkins X, DevOps teams should think of the former as a blank slate for continuous integration, and the latter as a preconfigured, ready-to-go toolkit.

DevOps teams use Jenkins X entirely on the command line, which is a big departure from the graphical option available with Jenkins. For example, IT admins or developers use the jx import my-app command in Jenkins X to perform a range of tasks, including to:

• build a pipeline that includes a number of Kubernetes-specific components, such as Helm;
• set up a project in GitHub; and
• deploy a software version to a staging environment.

This simple command — which does not require users to perform any manual changes or setup — demonstrates how Jenkins X works like a pre-configured tool out of the box, compared to Jenkins, which is a tool DevOps teams use to do the setup themselves.

Key points to compare Jenkins vs. Jenkins X

Between the two options for CI/CD automation, Jenkins is more flexible, which means DevOps teams can use it for a broader range of tasks, such as integrating disparate tools into a working pipeline.

When organizations opt for Jenkins X, they trade Jenkins’ flexibility — along with its many plugins — for the simplicity of ready-to-go templates. Jenkins can perform all the same tasks as Jenkins X, including in Kubernetes, but might require the user to create extensive configurations, as well as spend considerable time to learn and use all of the necessary plugins to make it happen.Ultimately, the choice of Jenkins vs. Jenkins X depends on the workloads.

Another big difference, as noted earlier, is the GUI vs. command-line management approach. Since teams use Jenkins X exclusively on the command line, they won’t have access to a graphical interface to configure parts of their environment as they would with Jenkins. In some cases, this GUI simplifies the process of configuring a pipeline, because it presents Jenkins configuration options and provides guidance in terms of validating those options. On the command line, users might only get an error message and have to figure out where they went wrong.

For DevOps teams not yet comfortable working solely from a command line, Jenkins X might present a steep learning curve.

Use cases for Jenkins X

Compared to Jenkins, Jenkins X is a preferable choice for two key use cases: Kubernetes implementations and support for multiple DevOps environments.

Organizations committed to Kubernetes don’t always want to spend time building out the toolchains and infrastructure necessary to support the container orchestration platform. Based on best practices from the open source community, Jenkins X provides default environments and configurations to get applications up and running quickly on Kubernetes. The tradeoff is that default Jenkins X setups are not always a perfect fit for an organization’s specific Kubernetes implementation. Developers and IT ops teams can customize these default settings to meet their specific needs, but that added work detracts from the appeal of Jenkins X — its opinionated approach to setups.

As for the second Jenkins X use case, a DevOps setup requires multiple environments to prevent the accidental deployment of non-working configurations or code. Jenkins X supports this model via Kubernetes Namespaces, which divide up cluster resources among multiple users. Teams store each environment configuration in a Git repository and can promote one environment over another.

Jenkins X subscribes to the idea of GitOps, which enables the tool’s support for multiple environments. GitOps is an approach in which IT teams use version-controlled code to handle infrastructure management and updates. This ensures that admins can easily revert back to a previous working state if something goes wrong with an upgrade or configuration change. Jenkins X manages the DevOps project’s application code and environments, standardizing everything into code. By comparison, a DevOps team might use Jenkins in concert with manual steps and external scripts to run the environments for an application, which means there are multiple sources of information for the project.

Decision time

Ultimately, the choice of Jenkins vs. Jenkins X depends on the workloads. Organizations that run Kubernetes or have it on their roadmaps are better off with Jenkins X. On the other hand, those with lots of legacy systems, or that work with different platforms, should consider Jenkins, as they can configure the tool to work best with their environment. If DevOps toolchains spring up in various groups within the IT organization, each with different tools and processes from code creation to production operations, the flexibility in Jenkins has more appeal than the opinionated approach of Jenkins X.