Industry Use Cases of Jenkins

WHAT IS JENKINS?

Jenkins is an open source continuous integration tool written in Java. The project was forked from Hudson after a dispute with Oracle. Jenkins provides continuous integration services for software development.

WHY DO WE USE JENKINS?

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

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

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

📌Plugins

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

📌Extensible

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

📌Distributed

Jenkins can easily distribute work across multiple machines, helping drive builds, tests and deployments across multiple platforms faster.

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.

In such scenarios, the distributed (or Master-Agent) architecture of Jenkins is used for continuous integration and testing.

Master- Agent Architecture In Jenkins

The master-agent (or distributed) architecture in Jenkins is used for managing distributed builds. The Master and Agent(s) communicate through the TCP/IP protocol.

These are the roles and responsibilities of the Jenkins Master and Agent(s):

📌Jenkins Master

The main server in Jenkins is the Master. Here are the jobs handled by Jenkins Master:

• Schedule build jobs
• Choosing the appropriate agent in the master-agent ecosystem for dispatching the builds.
• Monitor agents and take them online/offline as and when required.
• Presenting the build results (and reports) to the developer.

The Jenkins master can also execute the jobs directly but it is always recommended to select the appropriate agent(s) for build and execution-related tasks.

📌Jenkins Agent(s)

A agent is a remote machine that is connected to the Master. Depending on the project and build requirements, you could opt for ’N’ number of agents. agents can run on different operating systems and depending on the ‘type of build request’, the appropriate Agent is chosen by the Master for build execution and testing.

Here are the jobs handled by the Jenkins Agent(s):

• Listen to commands from the Jenkins Master.
• Execute build jobs that are dispatched by the Master.
• Developers have the flexibility to run the build and execute tests on a particular agent or a particular type of Agent. The default option is Jenkins Master selecting the best-suited Agent for the job.

Here is a simple diagrammatic representation of how does Jenkins work, with multiple Jenkins Agents connected to the Jenkins Master:

How Does Jenkins Work In Master-Agent Architecture?

In the previous section of the What is Jenkins blog, we touched upon the brief responsibilities of Master and Agent(s) in Jenkins. 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 builds versions of the code for different platforms. Jenkins Master (or Master Node) controls how the respective builds should operate.

Advantages Of Using Jenkins Pipeline

Jenkins Pipeline is instrumental in adding a rich set of automation tools onto Jenkins. Hence, Jenkins can be used for simple continuous integration as well as for comprehensive CD pipelines.

📌These are some of the primary reasons for using the Jenkins Pipeline:

• As the Jenkins Pipeline is implemented as code, it can be checked in the source control repository. Teams can view, edit, as well as iterate upon the delivery pipeline.
• Jenkins Pipelines are robust. A Pipeline is automatically resumed in case the server witnesses an unplanned restart.
• Pipeline process can pause and wait for input for any input from the user.
• Pipelines are versatile as they can be used for realizing complex CD requirements, including performing work in parallel.
• Jenkins Pipelines are extensible by plugin developers and users with Pipeline Shared Libraries.

Jenkins Case Study: Avoris Travel

📌Challenge:

With over 200 developers relying on the company’s infrastructure, they needed a secure, easily customizable, and powerful CI/CD platform.

📌Solution:

Avoris Travel, a unique travel company seeking to reinvent the travel industry, relies on an equally inventive technology platform fueled by Jenkins.

📌Results:

reduced build times over 50% with the flexibility of Jenkins plugins

increased the speed of delivery with Jenkins Pipelines

Much less problematic and simple deployments for the team

scalable infrastructure supporting 675 agencies and over 2.8 million international consumers

Jenkins Case Study: Tymit

📌Challenge:

Create a solidly reliable CI/CD platform that provides the technology team with the agility and the flexibility needed to innovate while ensuring the security and scalability their fintech service requires.

📌Solution:

Tymit, a revolutionary credit card processing company, leveraged Jenkins to build a compliant, transparent and secure modern DevOps platform to drive product innovation, handle instant financial transactions and support thousands of users in real-time.

📌Results:

faster delivery of mobile, microservices and operational services

reduced software testing and release cycles by 50%

ability to support thousands of users for real-time transactions

created a secure, controlled and compliant fintech environment.

Thank you everyone for reading this article.

Hope you guys like it.

Keep Learning, Keep Sharing.

Thank you.