What is Jenkins?
Jenkins is an open-source automation tool used for continuous integration. Continuous Integration is a process, in that all developed work integrated as early as possible. Jenkins build in Java and Plugins provided for Continuous Integration. Jenkins used to build the software project as well as to test the software project continuously. Jenkins makes it easier for the developers to integrate changes to the project.
Jenkins also provide ‘Continuous Delivery of Software Project’ by
Jenkins = Continuous Integration + Continuous Delivery
integrating ‘large number of testing and deployment techniques.’
As Jenkins is an automation tool, organization accelerates the software development process through automation of Jenkins. Jenkins integrates all kinds of SDLC process such as build, test, document, static analysis and deploy. Plug-in plays an essential role in achieving continuous integration. If the user wants to add a particular tool in Jenkins then first need to install a plugin for that tool.
Jenkins integrates some of the stages of DevOps like Build, continuous testing, continuous monitoring, and continuous deployment. The following image shows the Jenkins combines the different stages of DevOps.
Key Metrics of Jenkins
There are multiple ‘Continuous Integration’ tools are available. But Jenkins is different from another Continuous Integration tool because of key metrics. Following are the key metrics of Jenkins:
Let us see key metrics in detail
Adoption is one most important key metrics of Jenkins. Because of that, Jenkin is widespread. Jenkin has 147000 active installations and 1 million users across the world.
The plugin is another crucial key metrics of Jenkins. Jenkins interconnected with 1000+ plugins, and that plugin allows the Jenkins to interconnect with most of the deployment tools.
What is Continuous Integration?
Continuous Integration is a process of software development practice. In software development practice, the developers need to commit after updation, modification, or changes in the source code in a ‘shared repository’ more frequently in a day. Every commit made to the source in the repository, build the software product/ application. The result of this, the problem can be detected early and quickly.
Apart from Continuous Integration, perform several functions like ‘deploying the build application to the test server’ and ‘to provide build application and test results to the concern team.’
Use Case: CI in Nokia
Let us see the importance of Continuous Integration through Nokia’s Use case.
For developing the software product, Nokia was using the process called ‘Nightly Builds.’ Continuous Integration is the successor to the nightly builds process. In a Nightly Builds process, at every night the automated system pulls all the code from a shared repository (code gathered throughout a day) and builds the code. The idea of Nightly Builds and continuous integration is quite the same. The source code at the repository is large, and that will create difficulty to detect and fix the problem. Due to limitations of nightly builds process, Nokia adopted the continuous integration process.
How does Jenkins work?
Let us see how Jenkins works: The Software developer commits the changes in the source code stored in the git repository. Jenkins Servers keeps on checking the repository regularly for changes.
When commits occur, Jenkins Server detects the changes happened in the repository and pulls those changes and start building the new application.
There is a possibility of build failed and if the build failed then the respective team notified mentioning the build fail message. If application built is successful then Jenkins server deploys built to the test server.
After testing the build, Jenkins generates feedback and notify to the developer regarding build and test results.
Again, the Jenkins Server keeps on checking the repository and Jenkins keeps on repeating the same process.
Traditional SDLC before Jenkins and after Jenkins
|SDLC before Jenkins||SDLC after Jenkins|
|Entire source code build and then tested.||After changes in the source code, commit occurs and after every commit, source code built and tested build application.|
|Locating the bug and fixing that bug is very difficult and time-consuming.||Locating and fixing the bug is easy because testing is done after every commit.|
|The software developer has to wait for test results.||The developer already know the test results.|
|The complete process is manual.||The developer only need to commit the changes and the rest of the process automated because of Jenkins.|
Jenkins has two architecture Jenkins standalone architecture, and Jenkins distributed architecture, and as per the requirement, Jenkins chooses one of the architecture.
Jenkins Standalone Architecture
Jenkins Standalone architecture uses a single Jenkins Server. In standalone architecture, Jenkins uses three kinds of server Jenkins Server, Test Server, and Production Server.
Following diagram shows the architecture of standalone architecture.
Jenkins follows the Continuous Integration and Continuous Delivery. Let us see how these processes follow the loop structure:
The software developer keeps on changing the code in progress to complete/ achieve the goals of the software application.
The developer ‘Commit’ the source code after every change — all the source code present in a shared repository.
Jenkins Server keeps on checking the updation in the repository, and when it finds any changes made in the source code, then it pulls changed source code and start the new application build.
There is a possibility of building successful or build unsuccessful. If the build application failed the Jenkins server notifies ‘application build failure.’ If application built is successful then Jenkins Server deploy the build application to the Test Server for testing.
After testing, the Jenkins server generates the ‘feedback’ and notify the software developer about test results and build with the help of the production server.
Jenkins continue checking the change made in the source code in the repository and keep on repeating the above process.
Limitations of Jenkins Standalone architecture:
The single Jenkins Server not capable of handling few requirements:
- Sometimes the user needs several different environments to test the build applications. This cannot be possible using a single Jenkins Server.
- If more massive project built on Jenkins then single Jenkins not capable of handling the load.
2. Jenkins Distributed Architecture
For the distributed environment, Jenkins follows the master-slave architecture. This architecture is useful to manage the distributed builds. Master-slave uses TCP/IP protocol for communication.
The Jenkins Master is the main Jenkins server. Jenkins Master handles the following tasks:
- To schedule the build jobs.
- To dispatch the build to the slaves for real execution.
- To monitor all the slaves, i.e. take the slave online and offline.
- To record the build results.
- To present the build results.
- Master Jenkins can execute the build job directly.
Jenkins Slave runs on the remote machine. Jenkins Slave has some characteristics:
- Jenkins server obeys the Jenkins Masters request.
- Slave can run on any operating system.
- Slave executes the build jobs dispatched by master instance.
- The user can configure the project for choosing the particular slave machine.
Advantages of Jenkins
- Jenkins is an open source tool with excellent community support.
- Easy to install
- It is free of cost
- Jenkins built on Java; hence, it is portable on all primary operating system.
- Jenkins has 1000+ plugins to ease the work.