Case Study of Jenkins

What is Jenkins?

Jenkins is a free and open source automation server. It helps automate the parts of software development related to building, testing, and deploying, facilitating continuous integration and continuous delivery. It is a server-based system that runs in servlet containers such as Apache Tomcat.

Jenkin 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.

Features of Jenkins

1.Continuous Integration and Continuous Delivery

As an extensible automation server, Jenkins can be used as a simple CI server or turned into the continuous delivery hub for any project.

2.Plugins

With hundreds of plugins in the Update Center, Jenkins integrates with practically every tool in the continuous integration and continuous delivery toolchain.

3.Extensible

Jenkins can be extended via its plugin architecture, providing nearly infinite possibilities for what Jenkins can do.

4.Distributed

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.

6.Easy installation

Jenkins is a self-contained Java-based program, ready to run out-of-the-box, with packages for Windows, Linux, macOS and other Unix-like operating systems.

Architecture Of Jenkins

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.

Uses of Jenkins

There are lots of use of Jenkins some of them are given below

1. Jenkins lowers the Effort of repeated coding

with the uses of Jenkins, one can convert a command prompt code into a GUI button click. This can be done by wrapping up the script as a Jenkins job. Parameterized Jenkins jobs can be created for customization or to take user input. Thus, hundreds of lines of code writing can be saved.

2. Synchronization with Slack

A large team uses a centralized platform for communication. Slack is one such most popular platform. Slack integration can be done to Jenkins and thus communication such as activities have been triggered, its time, users name, results etc. can be shared with other people.

3. Code deployment to Production

Jenkins or another CI system can deploy code to staging or production automatically if all the tests written for the same within a specific feature or release branch are green. This is formally known as Continuous Deployment as well. Changes before a merge activity can be made visible too. This can be done in a dynamic staging environment, and after they are merged it is deployed directly to a central staging system, pre-production system or even a production environment.

4. Avoid Broken Code during shipping

Continuous integration ensures that code coverage is good, it is tested well and only merged when all tests are successful. This makes sure that the master builds are not broken, and no broken code is shipped to a production environment. In case, the master build is broken, such systems can trigger a warning to all developers.

5. Decrease Code Review Time

CI systems such as Jenkins and Version Control System such as Git can communicate with each other and inform the users when a merge request is suitable for merge. This is usually when all the tests are passed, and all other requirements are met. In addition to that, the difference in code coverage can also be reported in the merge request itself. This dramatically reduces the time taken to review a merge request.

According to JetBrains 2018 edition of their The State of Developer Ecosystem Survey .

With 62%, Jenkins is the leading continuous integration tool, period! Even if you sum up the percentage of the next four followers (!), you don’t reach the level of Jenkins.

If you then split cloud vs. on-premise usage, the result is the same: Jenkins is the de facto continuous integration tool, well ahead of any competition.

According to One more Survey

Case Study

D4Science Amps Up Their Scientific Research Platform With CI/CD Powered By Jenkins​

D4Science, supporting scientific communities and promoting open science practices by serving 11,000+ registered users in 45 countries, introduced a new delivery pipeline replacing their pre-existing build platform.

CHALLENGE

D4Science needed a cost-effective way to build and release their software framework (gCube) able to support multi-project releases at scale.

SOLUTION

A Continuous Integration/Continuous Delivery (CI/CD) pipeline, scalable, easy to maintain and upgrade at a minimal cost, that represents an innovative approach to software delivering.

RESULTS

• Automation of all release activities
• Fast, incremental releases to quickly address user requirements
• Build and release software components from 200+ Git repositories within the same day

Done

Thanks for reading , hope you find this helpful

Please like, comment & Share

Bye Bye Signing off!!!