Jenkins is an open source continuous integration/continuous delivery and deployment (CI/CD) automation software DevOps tool written in the Java programming language. It is used to implement CI/CD workflows called pipelines.
CI/CD pipelines automate testing and reporting on isolated changes in a larger codebase in real time. They also facilitate the integration of disparate branches of the code into a main branch. Pipelines rapidly detect defects in a codebase, build the software, automate testing of builds, prepare the codebase for deployment and delivery, and ultimately deploy code to containers and virtual machines (VMs), as well as to bare-metal and cloud servers.
There are several commercial versions of Jenkins; however, this definition focuses on the upstream open source Jenkins project.
History of Jenkins
Jenkins is a fork of a project called Hudson, which was trademarked by Oracle. Hudson was eventually donated to the Eclipse Foundation and is no longer under development. Jenkins development is now managed as an open source project under the governance of the CD Foundation, an organization within the Linux Foundation.
Continuous integration has evolved since its conception. Originally, a daily build was the standard. Now, the usual rule is for each team member to submit work, called a commit, on a daily or more frequent basis, and a build is conducted with each significant change. Continuous integration provides various benefits, such as constant feedback on the status of the software. Because CI detects deficiencies early on in development, defects are typically smaller, less complex and easier to resolve.
Jenkins and CI/CD
Jenkins uses the CI/CD pipeline methodology to streamline the work of DevOps teams. This pipeline can be broken down into two parts:
- Continuous integration. With the initial CI process, developers typically add new code on a regular basis to improve a software project. Continuous integration detects bugs and defects before integrating new code into an existing codebase.
- Continuous delivery and deployment. Continuous delivery comes after CI. It automates the building and packaging of code for deployment to test, staging and production environments. Finally, continuous deployment automates software delivery processes, deploying the code to its destination.
With Jenkins, in both CI and CD, automation reduces the number of errors that occur because the correct steps and best practices are encoded into software. Jenkins describes a desired state, and the automation server ensures it happens.
Other advantages Jenkins provides include increased release velocity because deployments aren’t bound to operator availability or other personnel limitations. It also reduces stress on software development and operations teams because it eliminates the need for overnight and weekend rollouts.
Over time, continuous delivery and deployment features were implemented in various Jenkins versions and projects. For example, the Jenkins X project was launched in 2018 with the goal of creating a modern, cloud-native version of Jenkins. Jenkins X was designed for Kubernetes and uses it in its own implementation. Its architecture, technology and pipeline language are different from those of Jenkins. Other cloud-native technologies that Jenkins X uses include Helm, for helping manage Kubernetes applications, and Tekton, a framework that further assists with creating CI/CD systems. Jenkins X is available under the guidance of the CD Foundation.
Jenkins’ CI/CD capabilities benefit other software projects through integrations. For example, Jenkins integrates with Docker to build software as containers and with Kubernetes to orchestrate these Docker containers into apps. Jenkins streamlines development through continuous building, testing and deployment. This workflow makes the work of developers more efficient.
How Jenkins works
Jenkins runs as a server on a variety of platforms including Windows, macOS, Unix variants and especially Linux. It requires a Java 8 VM or above, and is run on the Oracle Java Runtime Environment or OpenJDK. Usually, Jenkins runs as a Java servlet within a Jetty application server. It can run on other Java application servers such as Apache Tomcat.
Once Jenkins is installed on a server, all its projects share a common goal: to aid developers with a repeatable workflow that builds and tests new code, then deploys and releases new software into production. This workflow takes the form of a pipeline customized for each individual project. The pipeline is set up once and then used repeatedly.
A Jenkins pipeline automates various processes, including code testing, conducting a staged deployment to test how software features do in a production environment and deploying to a production environment.
The need for Jenkins becomes especially acute when deploying software to microservices architectures. Jenkins can integrate with Docker for containerization and Kubernetes for container orchestration. Since one of the goals of microservices is to frequently update applications and services, the ability to do so can’t be limited by release bandwidth. Jenkins provides the automation needed for more and smaller services with faster update intervals.
Jenkins pipeline
Once an organization installs Jenkins, the DevOps team creates a pipeline as a series of steps the Jenkins server will take to perform the required tasks of the CI/CD process. There are two types of Jenkins pipelines: scripted and declarative. A scripted pipeline gives developers more control over the script so that new code can be injected into the pipeline at any time to update and change tasks. A declarative pipeline uses predefined constructs for simpler coding, but that also makes it more rigid than scripted pipelines.
The contents of both declarative and scripted pipelines are stored in plain text Jenkinsfiles. A Jenkinsfile is a text file that describes a pipeline in the form of code, explaining its purpose and how it’s configured to suit a specific project’s needs. Developers usually code these directly. A Jenkinsfile uses a Groovy-based syntax so that the Jenkins server can read it and execute its commands.
Learn how to create a Jenkins project and run the resulting build job.
Jenkins plugins
A pipeline plugin is an enhancement to the Jenkins system. Plugins help extend Jenkins’ capabilities and integrate Jenkins with other software. They’re downloaded from the online Jenkins Plugins repository and loaded using the Jenkins web user interface (UI) or command-line interface. The Jenkins community claims that more than 1,900 plugins are available for a range of uses.
Plugins integrate other developer tools into the Jenkins environment, add new UI elements to the Jenkins web UI, help with administration of Jenkins, and enhance Jenkins for build and source code management.
A common use of plugins is to provide integration points for CI/CD sources and destinations. These include software version control systems, such as Git and Atlassian Bitbucket; container runtime systems, such as Docker; VM hypervisors, such as VMware vSphere; public cloud instances, including Google Cloud Platform and Amazon Web Services; and private cloud systems, such as OpenStack Cloud. There are also plugins that assist in communicating with operating systems over File Transfer Protocol, Common Internet File System and Secure Shell.
Plugins are written in Java. They use their own set of Java Annotations and design patterns that define how the plugin is instantiated, the extension points, the function of the plugin and the UI representation in the Jenkins web UI. Plugin development also makes use of Maven deployment to Jenkins.
Security in Jenkins
Jenkins security revolves around securing the server and the user. Server security is achieved in the same way that any other server is secured. Access to where it resides, such as a VM or bare-metal server, is configured to allow for the fewest number of processes to communicate with the server. This is accomplished through typical server operating system and networking security features.
Access to the server by way of the Jenkins UI is similarly limited to the fewest number of users through standard techniques such as multifactor authentication. This is accomplished by using the user security features of the HTTP server in use for the UI.
Jenkins also supports security for its internal user database. These features are accessed through the Jenkins web UI. Jenkins supports two security realms: the Security Realm and the Authorization Realm. The Security Realm lets an operator decide who has access to Jenkins, and the Authorization Realm determines what a person can do with that access.
Advantages and disadvantages of Jenkins
As with all software, there are pros and cons to Jenkins.
Advantages
One of the advantages of Jenkins is that it can be extended using plugins. This makes Jenkins adaptable to changes in IT environments.
Plugins also contribute to Jenkins’ flexibility, as do the rich scripting and declarative languages that allow for highly customized pipelines. Jenkins is highly unopinionated, so it fits well into most environments, including complex hybrid and multi-cloud systems.
Jenkins has been around much longer than other offerings in this space. This, plus its flexibility, has led to it being widely deployed. For this reason, Jenkins is well understood, with a broad knowledge base, extensive documentation and abundant community resources. These resources make it easier to install, manage and troubleshoot a Jenkins installation.
Finally, Jenkins and its plugins are built on Java. Java is a proven enterprise development language with a broad ecosystem. This places Jenkins on a solid base that can be extended using common design patterns and frameworks.
Jenkins isn’t perfect, however.
Disadvantages
While it’s easy to install and has simple-to-follow directions, production Jenkins can be difficult to implement. Developing production pipelines using Jenkinsfiles requires coding in either its declarative or scripting language. Complex pipelines can be especially difficult to code, debug and maintain.
The open source automation server is based on a single-server architecture. This makes Jenkins easy to install, but caps resources to those of a single computer, VM or container. Jenkins doesn’t allow federation across servers, and that can result in performance issues. Lack of federation can also lead to a proliferation of independent Jenkins servers that are difficult to manage across a large enterprise.
Jenkins relies on older Java architectures and technology, specifically servlets and Maven. Even the Jenkins Docker installation still requires packaging the Jenkins code and servlet middleware together in a container, maintaining its monolithic architecture. In addition, Jenkins isn’t designed to be implemented using newer Java technology such as Spring Boot or GraalVM.
DevOps teams have an abundance of resources for learning how to use Jenkins. Explore our Jenkins tutorial that provides all the basics for beginners.