Blog
March 6, 2020
In almost any discussion about open source continuous integration or continuous delivery (CI/CD) tools, Jenkins will inevitably be brought up. But what is Jenkins used for, specifically, and how does it work?
In this blog, we give an overview of Jenkins, how it's used, and tips for teams ready to move forward with integrating this popular open source CI/CD tool.
What Is Jenkins Used For?
Jenkins is used to build and test your product continuously, so developers can continuously integrate changes into the build. Jenkins is the most popular open source CI/CD tool on the market today and is used in support of DevOps, alongside other cloud native tools.
Automation, including CI/CD and test automation, is one of the key practices that allow DevOps teams to deliver “faster, better, cheaper” technology solutions.
So, Jenkins has become an indispensable tool in helping them achieve those goals. Jenkins has been a key enabling technology that is increasingly helping DevOps practices gain widespread adoption in many organizations around the world.
How OpenLogic Supports Jenkins
Getting enterprise support for Jenkins can help you accelerate CI/CD.
OpenLogic does Jenkins support differently. Our approach enables teams to:
- Adopt continuous integration, deployment, and many other DevOps workflows.
- Navigate the cultural and procedural components of Jenkins integrations.
- Deploy Jenkins and related solutions free of vendor lock-in and at any scale.
- Get help directly from real experts 24 hours a day, 7 days a week.
Talk to a Jenkins expert today to learn how we can help you.
Is Jenkins a Continuous Integration/Continuous Delivery Tool?
Yes. Although Jenkins was originally developed to facilitate the continuous integration for Java applications, it has since evolved to orchestrate the entire software delivery pipeline for the most popular languages and technologies used by developers around the world today.
Written in Java, with extensibility at the core of its architecture, there are hundreds of plugins available that extend Jenkins to provide the flexibility to automate every aspect of the software delivery pipeline.
Back to topHistory of the Jenkins Project
Used by many advanced DevOps teams delivering cutting-edge, cloud-native applications, Jenkins has been around for quite a while. The project (originally called Hudson) was developed in 2004 by Kohsuke Kawaguchi while working at Sun Microsystems and released in 2005. After Oracle acquired Sun, the project was forked to remain open source and the fork was named Jenkins in 2011.
Before Jenkins, many development teams employed a nightly build as part of their software delivery process. The nightly build process required teams to commit their code to the source code repository at a certain cut-off time each day. This was even more of a challenge when working with geographically dispersed teams. A nightly build time of say, 11 pm PST would equate to 12:30 PM IST in India.
So, developers in India would be forced to commit their code in the middle of the day and then wait for the “nightly” build to run, affecting their productivity. Then, once the build completed, the development teams would often be faced with the question of, “Who broke the build?”. At this point, the development teams would scramble to determine who’s commit broke the build and the finger-pointing would begin. There had to be a better way.
Back to topHow Does Jenkins Work?
Jenkins triggers a build upon every commit to the source code repository, typically to a development branch.
Jenkins can be configured to run an initial suite of unit tests to ensure that the commit did not “break the build”. If the tests do not pass, the developer can be immediately notified to take corrective action. This puts to rest the question of “Who broke to build?” as it is easy to determine which commit caused the build to fail. If all the unit tests pass, then the build pipeline can proceed to the next phase with integration tests which typically take longer to run.
Jenkins provides the ability to run a build in parallel across multiple machines to minimize the total amount of time it takes to complete many of these activities. Finally, Jenkins can deploy the build to an environment that allows for any needed user acceptance testing (UAT) before releasing it into production. These simplified steps encompass the spirit of a continuous integration (CI) environment.
To reach the holy grail of continuous delivery (CD), these UAT tests can be automated as well using a tool like Selenium, where if those tests pass, the code can be merged into the master branch were a “golden” build can be created and deployed directly into production without manual intervention. Companies that have reached the continuous delivery milestone can deploy to production many times a day, such as Amazon, Facebook, and Google.
Back to topMoving Forward with Jenkins for DevOps
Looking towards the future, Jenkins has found a sweet spot in many DevOps environments. Some have even called it “the engine of DevOps”. the use of the cloud and containers. Jenkins can run in the cloud (AWS, Google, Azure, IBM, etc.), and leveraging technologies like Docker and Kubernetes give Jenkins additional flexibility, speed, and reliability to meet the demands of today’s modern cloud-native, microservices-based applications. The future looks very bright for Jenkins as a key enabling technology for CI/CD pipelines for companies around the world.
Additional Resources
- Datasheet - Jenkins Enterprise Support
- Blog - Jenkins + Selenium: How to Setup and Run Tests
- Video - How OpenLogic Supports Jenkins
Support for Jenkins and CI/CD Tools
OpenLogic Enterprise Architects have experience with large scale Jenkins deployments as well as other open source CI/CD tools like Ansible. We can help you adopt a more modern approach to SDLC — click the button below to learn how.