Jenkins: Use cases
Jenkins is a popular open source automation server. It’s used to implement Continuous Integration (CI) and Continuous Delivery (CD) for any development project. CI/CD, a key component of a DevOps strategy, allows you to shorten the development lifecycle while maintaining quality by automating tasks like testing. In short, a successful implementation will help you test more often and deploy faster with high quality. Jenkins, as a Java-based CI server with strong community support and a huge plugin ecosystem, is a powerful tool for anyone looking to add CI/CD to their project.
What is Jenkins and why we use it?
Jenkins is an open-source automation tool written in Java with plugins built for Continuous Integration purposes. Jenkins is used to build and test your software projects continuously making it easier for developers to integrate changes to the project, and making it easier for users to obtain a fresh build. It also allows you to continuously deliver your software by integrating with a large number of testing and deployment technologies.
With Jenkins, organizations can accelerate the software development process through automation. Jenkins integrates development life-cycle processes of all kinds, including build, document, test, package, stage, deploy, static analysis, and much more.
Jenkins achieves Continuous Integration with the help of plugins. Plugins allow the integration of Various DevOps stages. If you want to integrate a particular tool, you need to install the plugins for that tool. For example Git, Maven 2 project, Amazon EC2, HTML publisher etc.
Advantages of Jenkins include:
- It is an open-source tool with great community support.
- It is easy to install.
- It has 1000+ plugins to ease your work. If a plugin does not exist, you can code it and share it with the community.
- It is free of cost.
- It is built with Java and hence, it is portable to all the major platforms
- Multiple hosting option
- Plug-in and integration
- Community support
- Easy to debug
Before Jenkins
The entire source code was built and then tested. Locating and fixing bugs in the event of build and test failure was difficult and time-consuming, which in turn slows the software delivery process. Developers have to wait for test results. The whole process is manual.
After Jenkins
Every commit made in the source code is built and tested. So, instead of checking the entire source code developers only need to focus on a particular commit. This leads to frequent new software releases. Developers know the test result of every commit made in the source code on the run. You only need to commit changes to the source code and Jenkins will automate the rest of the process for you.
Jenkins Features
The following are some facts about Jenkins that makes it better than other Continuous Integration tools:
- Adoption: Jenkins is widespread, with more than 147,000 active installations and over 1 million users around the world.
- Plugins: Jenkins is interconnected with well over 1,000 plugins that allow it to integrate with most of the development, testing and deployment tools.
1.Easy Installation & Configuration Jenkins is a self-contained Java-based program, it is available for almost all the popular operating systems such as Windows, different flavors of Unix, and Mac OS.
2. Open-Source: As it is open-source, it is free for use. There is a strong involvement of the community which makes it a powerful CI/CD tool.
3. Thriving Plugin Ecosystem: The backbone of Jenkins is the community and the community members have been instrumental in the development (and testing) of close to 1500+ plugins available in the Update Center. Jenkins integrates with practically every tool in the continuous integration and continuous delivery toolchain.
4. Easy Distribution: Jenkins can easily distribute work across multiple machines, helping drive builds, tests and deployments across multiple platforms faster.
5. Easy Configuration: Jenkins can be easily set up and configured via its web interface, which includes on-the-fly error checks and built-in help.
What is Continuous Integration?
Continuous Integration is a development practice in which the developers are required to commit changes to the source code in a shared repository several times a day or more frequently. Every commit made in the repository is then built. This allows the teams to detect the problems early. Apart from this, depending on the Continuous Integration tool, there are several other functions like deploying the build application on the test server, providing the concerned teams with the build and test results, etc.
Jenkins is used to build and test softwares continuously making it easier for developers to build software rapidly. It’s a plug and play as it can not do most work without respective plug-in’s. As continuous integration evolved, the industry created the notion of continuous delivery and continuous deployment to render production deployments a non-issue.
Architecture Of Jenkins
Before we dive into how does Jenkins work, we must understand the architecture of Jenkins. These are the series of steps that outlines the interaction between different elements in Jenkins:
- Developers do the necessary modifications in the source code and commit the changes to the repository. A new version of that file will be created in the version control system that is used for maintaining the repository of source code.
- The repository is continuously checked by Jenkins CI server for any changes (either in the form of code or libraries) and changes are pulled by the server.
- In the next step, we ensure that the build with the ‘pulled changes’ is going through or not. The Build server performs a build with the code and an executable is generated if the build process is successful. In case of a build failure, an automated email with a link to build logs and other build artifacts is sent to the developer.
- In case of a successful build, the built application (or executable) is deployed to the test server. This step helps in realizing continuous testing where the newly built executable goes through a series of automated tests. Developers are alerted in case the changes have caused any breakage in functionality.
- If there are no build, integration, and testing issues with the checked-in code, the changes and tested application are automatically deployed to the Prod/Production server.
Here is the diagrammatic representation of the Jenkins architecture:
A single Jenkins server might not be sufficient to realize the following requirements:
- Testing needs to be performed on different environments (i.e. code written using different languages e.g. Java, Python, C, etc. are committed to the version control system), where a single server might not suffice the requirement.
- A single Jenkins server might not be sufficient to handle the load that comes with large-scale software projects.
How popular is Jenkins?
2833 companies reportedly use Jenkins in their tech stacks, including Facebook, Netflix, and Udemy.
Here are the name of the companies which use Jenkins:
- Netflix
- Udemy
- Instacard
- Robinhood
- Twitch
- Lyft
- Delivery Hero
Industry use case:
Continuous integration on Nokia
I am pretty sure you all have used Nokia phones at some point in your life. In a software product development project at Nokia, there was a process called Nightly builds. Nightly builds can be thought of as a predecessor to Continuous Integration. It means that every night an automated system pulls the code added to the shared repository throughout the day and builds that code. The idea is quite similar to Continuous Integration, but since the code that was built at night was quite large, locating and fixing of bugs was a real pain. Due to this, Nokia adopted Continuous Integration (CI). As a result, every commit made to the source code in the repository was built. If the build result shows that there is a bug in the code, then the developers only need to check that particular commit. This significantly reduced the time required to release new software.
- Developers have to wait until the complete software is developed for the test results.
- There is a high possibility that the test results might show multiple bugs. It was tough for developers to locate those bugs because they have to check the entire source code of the application.
- It slows the software delivery process.
- Continuous feedback pertaining to things like coding or architectural issues, build failures, test status and file release uploads was missing due to which the quality of software can go down.
- The whole process was manual which increases the risk of frequent failure.
It is evident from the above-stated problems that not only the software delivery process became slow but the quality of software also went down. This leads to customer dissatisfaction. So to overcome such chaos there was a dire need for a system to exist where developers can continuously trigger a build and test for every change made in the source code. This is what CI is all about. Jenkins is the most mature CI tool available so let us see how Continuous Integration with Jenkins overcame the above shortcomings.
I will first explain to you a generic flow diagram of Continuous Integration with Jenkins so that it becomes self-explanatory, how Jenkins overcomes the above shortcomings. This will help you in understanding how does Jenkins work.
The above diagram is depicting the following functions:
- First, a developer commits the code to the source code repository. Meanwhile, the Jenkins server checks the repository at regular intervals for changes.
- Soon after a commit occurs, the Jenkins server detects the changes that have occurred in the source code repository. Jenkins will pull those changes and will start preparing a new build.
- If the build fails, then the concerned team will be notified.
- If built is successful, then Jenkins deploys the built in the test server.
- After testing, Jenkins generates a feedback and then notifies the developers about the build and test results.
- It will continue to check the source code repository for changes made in the source code and the whole process keeps on repeating.
