“Jenkins” — What, Why, Who.
What is Jenkins Tool?
Jenkins is a software that allows continuous integration. Jenkins will be installed on a server where the central build will take place.
Conceived in Sun (now Oracle) as Hudson by Kohsuke Kawaguchi, Jenkins started life as an automated build server. Having developed and grown in both Oracle and the open-source community, Hudson forked in 2011 with the open-source branch becoming Jenkins.
Jenkins has a single master server with one or more slave agents, which can execute on other machines or on the local machine with the master. The elements that make Jenkins stand out from other automation servers are:
Very active open source solution. A strong developer community with good documentation
Extensive plugin library (c. 1400) providing integration with a huge range of tools and services
Groovy (a scripting form of Java) driven pipelines (processes)
REST API allowing pipelines to be driven remotely, and information to be fed back to Jenkins from external sources
The plugins enable integration with other software, e.g.:
With the GitHub plugin enabled, Jenkins can be triggered to run a pipeline when code is checked in. It can pull the code and deliver it to the build server and drive the build process.
With the SonarQube plugin enabled, it can check the quality of the delivered code as well.
With the Selenium plugin enabled, it can test the resulting web application and report the results
Pipelines are written in Groovy and can either be scripted directly into the pipeline or (better!) delivered in a file in the application SCM. This ensures that the build, test, and deployment Jenkins configuration is under coordinated code control with the application it represents.
Why 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.
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.
So far around 280 tickets are closed, and the project publishes stable release every three months.
As technology grows, so does Jenkins. So far Jenkins has around 320 plugins published in its plugins database. With plugins, Jenkins becomes even more powerful and feature rich.
Jenkins also supports cloud-based architecture so that you can deploy Jenkins in cloud-based platforms.
Who: Nokia case study
Real-world case study of Continuous Integration
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 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.
How Does Jenkins Work In Master-Agent Architecture?
Let’s look at exactly how does Jenkins works in the Master-Agent (or distributed) architecture:
In the Jenkins Master-Agent architecture shown below, there are three Agents, each running on a different operating system (i.e. Windows 10, Linux, and Mac OS).
- Developers check-in their respective code changes in ‘The Remote Source Code Repository’ that is depicted on the left-hand side.
- Only the Jenkins master is connected to the repository and it checks for code-changes (in the repository) at periodic intervals. All the Jenkins Agents are connected to the Jenkins Master.
- Jenkins master dispatches the request (for build and test) to the appropriate Jenkins Agent depending on the environment required for performing the build. This lets you perform builds and execute tests in different environments across the entire architecture.
- The Agent performs the testing, generates test reports, and sends the same to the Jenkins Master for monitoring.
As developers keep pushing code, Jenkins Agents can run different build versions of the code for different platforms. Jenkins Master (or Master Node) controls how the respective builds should operate.
FOR MORE ABOUT JENKINS: CLICK HERE
FOR, HOW TO INSTALL JENKINS: CLICK HERE
