What is Jenkins? Why Use Continuous Integration (CI) Tool?
Thomas Hamilton
⚡ Smart Summary
Jenkins is the open-source automation server that builds and tests code every time a developer commits, turning Continuous Integration from a nightly chore into a process that runs continuously throughout the working day.
What is Jenkins?
Jenkins is an open-source Continuous Integration server written in Java for orchestrating a chain of actions to achieve the Continuous Integration process in an automated fashion. Jenkins supports the complete development life cycle of software from building, testing, documenting the software, deploying, and other stages of the software development life cycle.
Jenkins is a widely used application around the world, with hundreds of thousands of installations and growing day by day. By using Jenkins, software companies can accelerate their software development process, as Jenkins can automate build and test at a rapid rate.
It is a server-based application and requires a web server like Apache Tomcat. The reason Jenkins software became so popular is that of its monitoring of repeated tasks which arise during the development of a project. For example, if your team is developing a project, Jenkins will continuously test your project builds and show you the errors in early stages of your development.
Note: deploying the WAR into Apache Tomcat still works, but current releases ship an embedded servlet container, so Jenkins normally runs on its own. The 2.555.x LTS line requires Java 21.
What is Continuous Integration?
Continuous Integration is a process of integrating code changes from multiple developers in a single project many times. The software is tested immediately after a code commit. With each code commit, code is built and tested. If the test is passed, the build is tested for deployment. If the deployment is successful, the code is pushed to production.
This commit, build, test, and deploy is a continuous process and hence the name continuous integration/deployment.
How does Jenkins work?
Jenkins is a server-based application and requires a web server like Apache Tomcat to run on various platforms like Windows, Linux, macOS, Unix, etc. To use Jenkins, you need to create pipelines which are a series of steps that a Jenkins server will take. Jenkins Continuous Integration Pipeline is a powerful instrument that consists of a set of tools designed to host, monitor, compile and test code, or code changes, like:
- Continuous Integration Server (Jenkins, Bamboo, CruiseControl, TeamCity, and others)
- Source Control Tool (e.g., CVS, SVN, GIT, Mercurial, Perforce, ClearCase and others)
- Build tool (Make, ANT, Maven, Ivy, Gradle, and others)
- Automation testing framework (Selenium, Appium, TestComplete, UFT, and others)
In current versions those steps live in a Jenkinsfile committed beside the code. The Jenkins controller reads that file and hands each stage to an agent, which is the machine that actually runs the work.
Jenkins History
- Kohsuke Kawaguchi, a Java developer, working at SUN Microsystems, was tired of building the code and fixing errors repetitively. In 2004, created an automation server called Hudson that automates build and test task.
- In 2011, Oracle who owned Sun Microsystems had a dispute with Hudson open source community, so they forked Hudson and renamed it as Jenkins.
- Both Hudson and Jenkins continued to operate independently. But in short span of time, Jenkins acquired a lot of projects and contributors while Hudson remained with only 32 projects. With time, Jenkins became more popular, and Hudson is not maintained anymore.
Why use Continuous Integration with Jenkins?
Some people might think that the old-fashioned way of developing the software is the better way. Let’s understand the advantages of CI with Jenkins with the following example
Let us imagine, that there are around 10 developers who are working on a shared repository. Some developer completes their task in 25 days while others take 30 days to complete.
| Before Jenkins | After Jenkins |
|---|---|
|
Once all Developers had completed their assigned coding tasks, they used to commit their code all at same time. Later, Build is tested and deployed. Code commit built, and test cycle was very infrequent, and a single build was done after many days. |
The code is built and test as soon as Developer commits code. Jenkins will build and test code many times during the day If the build is successful, then Jenkins will deploy the source into the test server and notifies the deployment team. If the build fails, then Jenkins will notify the errors to the developer team. |
| Since the code was built all at once, some developers would need to wait until other developers finish coding to check their build | The code is built immediately after any of the Developer commits. |
| It is not an easy task to isolate, detect, and fix errors for multiple commits. | Since the code is built after each commit of a single developer, it’s easy to detect whose code caused the build to fail |
| Code build and test process are entirely manual, so there are a lot of chances for failure. | Automated build and test process saving timing and reducing defects. |
| The code is deployed once all the errors are fixed and tested. | The code is deployed after every successful build and test. |
| Development Cycle is slow | The development cycle is fast. New features are more readily available to users. Increases profits. |
Real-world case study of Continuous Integration
I am sure all of you aware of old phone Nokia. Nokia used to implement a procedure called nightly build. After multiple commits from diverse developers during the day, the software built every night. Since the software was built only once in a day, it’s a huge pain to isolate, identify, and fix the errors in a large code base.
Later, they adopted Continuous Integration approach, shown below. The software was built and tested as soon as a developer committed code. If any error is detected, the respective developer can quickly fix the defect.
Jenkins Plugins
By default, Jenkins comes with a limited set of features. If you want to integrate your Jenkins installation with version control tools like Git, then you need to install plugins related to Git. In fact, for integration with tools like Maven, Amazon EC2, you need to install respective plugins in your Jenkins, as the plugin manager below shows.
Advantages of using Jenkins
- Jenkins is being managed by the community which is very open. Every month, they hold public meetings and take inputs from the public for the development of Jenkins project.
- The project keeps a predictable release rhythm: a new Long-Term Support baseline is chosen every twelve weeks and then receives scheduled patch releases.
- As technology grows, so does Jenkins. The plugin database now holds over two thousand plugins. With plugins, Jenkins becomes even more powerful and feature rich.
- Jenkins tool also supports cloud-based architecture so that you can deploy Jenkins in cloud-based platforms.
- The reason why Jenkins became popular is that it was created by a developer for developers.
Disadvantages of using Jenkins
Though Jenkins is a very powerful tool, it has its flaws.
- Its interface is out dated and not user friendly compared to current UI trends, although recent releases have modernised much of the screen design.
- Though Jenkins is loved by many developers, it’s not that easy to maintain it because Jenkins runs on a server and requires some skills as server administrator to monitor its activity.
- One of the reasons why many people don’t implement Jenkins is due to its difficulty in installing and configuring Jenkins.
- Continuous integrations regularly break due to some small setting changes. Continuous integration will be paused and therefore requires some developer attention.
- Plugin dependency conflicts appear when many plugins are upgraded at different times, so plugin updates need their own maintenance window.
If those trade-offs matter to your team, compare the Best Jenkins Alternative tools and the wider list of top continuous integration tools before committing to a self-hosted server.
