Jenkins is a continuous integration and continuous delivery (CI/CD) tool. It improves the development lifecycle by automating software building, testing, and deployment.

One of the largest benefits of Jenkins is its versatility. The original version of Jenkins is non-opinionated, making it an excellent tool for many uses. Jenkins 2 has since been released with increased usability, built-in support for delivery pipelines, and backwards compatibility with Jenkins installations. Jenkins X, a sub-project of Jenkins, was also created to make CI/CD easier for cloud-native Kubernetes or Docker users, improving developers' experience by eliminating the need for installation and configuration.

Before we can talk about why to use CI/CD, let's discuss what CI and CD are:

CI is a development practice that ensures each new proposed change does not break existing functionality. It works by monitoring a version control system (GitHub, GitLab, BitBucket, etc.) on an ongoing basis, with code being tested using a continuous integration tool each time so that no errors are merged to the codebase. This means a better experience for both developers and users of the product by making sure that errors don't make it to production. In addition, ongoing testing allows remote workers to contribute worry-free to a shared repository from wherever they are located.

CD is a development practice that reduces the work required to deploy new code. Code is tested in production-like environments on an ongoing basis, working in short sprints to make it easier to identify and fix bugs as they come up. When developers are ready to deploy code, it can be done with the push of a button.

Why is CI/CD important?

CI/CD is a key component of the DevOps culture that exists in many successful technology organizations, most notably places like Amazon, HP, and Netflix. Having a strong DevOps culture means that the engineering and operations teams communicate more often and more efficiently, and work collaboratively to ensure the best experience for everyone.

History of Jenkins

Jenkins originated in 2005 as a tool by the name of Hudson. Created by Kohsuke Kawaguchi, Hudson was one of the first commercially available CI tools that supported git (created the same year). In 2010, The Jenkins fork split ways from Hudson due to disagreements in how to manage the software, and the majority of the original core contributors joined the Jenkins team. Jenkins X was launched in 2018 as a sub-project of Jenkins to keep up with thriving innovation in the Kubernetes ecosystem.

How to Install Jenkins

Jenkins has download guides on its site, where you can find either the weekly or the monthly Long Term Support (LTS) release, with a version of the LTS chosen every 12 weeks as a baseline for the "stable but older" release. Downloads are offered for Docker, Linux, Windows, macOS, and several other Unix-like operating systems. Jenkins also has a vast plugin architecture — after installation, a number of plugins can be added to further increase functionality.

Jenkins Architecture

In an update to the Jenkins roadmap, Kohsuke Kawaguchi has described Jenkins as "a bucket of LEGO — you can build any car you want, but everyone first has to assemble their own car in order to drive one" There are thousands of Jenkins plugin options that add non-native functionality to Jenkins, allowing integration of a number of tools, including Gradle, Groovy, Maven, etc. Although there are many uses of Jenkins, it often looks fundamentally similar.

The process usually looks something like this:

• Developers commit code to a source code repository
• Jenkins checks the repository regularly
• When Jenkins registers changes, it compiles the code instantly
• If there is a failed build, an error message will be sent to the developer
• If the code is clean, it will be deployed to production

The single Jenkins server may not be enough to handle large or heavier builds, so many users utilize Jenkins' controller-agent architecture to manage distributed builds, in order to perform CI/CD efficiently.

The controller is in charge of:

• Organizing the agents.
• Dispatching builds to the agents.
• Executing the builds, if applicable.

If the controller can execute builds, why use agents?

• Executing builds using the controller may introduce a security concern because if the controller gets compromised then the attacker would have full access to all resources.
• If the controller is used to execute the build, then as the project scales, it is likely that it will at some point need more resources. At this point, the whole system will be unusable during the resource-increasing downtime, which is not ideal.
• Using agents allows for a distributed workload, meaning that the system as a whole can handle a heavier workload in less time than it otherwise would.

Each agent is a node that receives requests from the controller, to offload some of the work and ultimately host multiple build environments. Some characteristics of the agents include:

• Receiving requests from the controller.
• Ability to run on a number of operating systems: Windows, Linux, macOS, etc.
• Ability to be organized so that certain jobs run on certain nodes.

What are some ways to organize controllers? Three common ways that are outlined on the Jenkins website are by:

1. Environment: by assigning controllers by environment that they are deploying to, plugins can be catered to the functional group that they are in, and this allows access only to the people that must have access to that environment.
2. Org chart: when assigning controllers by company structure the result is similar to organization by environment.
3. Product line: by assigning a controller to each important product, the whole product cycle can be seen by members with access to the controller, and downtime for the controller will only affect a particular product.

Pros and Cons of Jenkins

Many of the excellent features of Jenkins have been touched on within this post, but to reiterate several of the pros of Jenkins:

• Cost: free. Can't find a better price than that!
• Plugin options: as previously mentioned, there are many plugins available. It is possible to find a plugin for practically anything, making your Jenkins pipelines easy to customize and integrate with other tools.
• Open-source: the community effort of Jenkins is admirable, and the active community provides a network of support, suggestions, and improvement from community members themselves.

While nothing is better than a great free product, sometimes there is a little bit of truth to the old adage, "you get what you pay for". Jenkins proves to be an excellent open-source platform, however, there are some drawbacks to using open-source tools, especially when running a developer team for a business.

• Missing documentation: because it is open-source, relying on community members for contributions, there are many areas where the documentation needs work.
• Self-serve: the self-serve nature of Jenkins means that there is no company-provided customer support — coupled with documentation that needs work, this can get particularly tricky. In addition, a hosting server is required, which can lead to tricky set-up and result in unpredictable pricing.
• User interface (UI): Jenkins' default UI leaves something to be desired, and could be much easier to navigate. However, there is still hope with Blue Ocean, a suite of plugins that can be used to easily create a set of visual tools and attractive UI.
• Complex pipelines: if using Jenkins extensively, many organizations require a full-time employee dedicated to handling their Jenkins pipelines. Despite the platform being free, costs rack up pretty quickly when considered the amount of developer hours dedicated to your Jenkins pipeline.
• Outdated plugins: Jenkins has a lot of plugins, but many are not well-maintained. At some point, the optionality begins to feel a little overwhelming. With an excess of plugins that need to be tested for functionality, it can take some time to figure out what to use to achieve your goals.

Interested in Checking out Jenkins Alternatives?

Looking for the best Jenkins alternative? We care about helping developer teams find the optimal way to set up their organization's CI/CD pipeline.

If you'd like Jenkins migration support, or are looking for the enterprise plan, feel free to email [email protected]. Want to try it out for yourself? Start a free trial of webapp.io here.