Industry Use Cases of Jenkins

QUICK OVERVIEW : WHAT IS JENKINS?

Jenkins is one of the leading open-source automation server which provides hundreds of plugins to support building, deploying and automating any project which in turns helps in continuous integration and build automation. The basic functionality of Jenkins is to execute a predefined list of tasks i.e. as soon as there is a change in repository, triggers a pipeline that executes different jobs and performs the tasks.

Every phase is monitored, and a notification will be triggered to the user if anything breaks. Even you have the privilege to stop the entire process in between. This process will be helpful for a large project where multiple teamwork on the same code without knowing what changes their colleagues are making due to which we get errors and bug when the codes are integrated into the branch. Here comes the role of Jenkins which detects the bug after every commit and notify the developers of the issue.

WHY DO WE USE JENKINS?

With Jenkins, organizations can accelerate the software development process through automation. Jenkins integrates development life-cycle processes of all kinds, including build, document, test, package, stage, deploy, static analysis, and much more.

Jenkins achieves Continuous Integration with the help of plugins. Plugins allow the integration of Various DevOps stages. If you want to integrate a particular tool, you need to install the plugins for that tool. For example Git, Maven 2 project, Amazon EC2, HTML publisher etc.

The image below depicts that Jenkins is integrating various DevOps stages:

Features of Jenkins:

1. Continuous Integration & 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. Easy Installation — Jenkins is a self-contained Java-based program, ready to run out-of-the-box, with packages for Windows, Mac, and other Unix operating systems.
3. Easy Configuration — Jenkins can be easily set up and configured via its web interface.
4. Plugins — Hundreds of plugins are available in its marketplace to easily integrate Jenkins with any tool.
5. Extensible — It can be extended via its plugin architecture, providing nearly infinite possibilities for what Jenkins can do.
6. Distributed — It can be easily distributed across multiple machines, helping drive builds, tests and deployments across multiple platforms faster.

Advantages of Jenkins include:

• It is an open-source tool with great community support.
• It is easy to install.
• It has 1000+ plugins to ease your work. If a plugin does not exist, you can code it and share it with the community.
• It is free of cost.
• It is built with Java and hence, it is portable to all the major platforms.

How Jenkins gives an upper hand compared to other Continuous Integration Tools

The following are some facts about Jenkins that makes it better than other Continuous Integration tools:

• Adoption: Jenkins is widespread, with more than 147,000 active installations and over 1 million users around the world.
• Plugins: Jenkins is interconnected with well over 1,000 plugins that allow it to integrate with most of the development, testing and deployment tools.

It is evident from the above points that Jenkins has a very high demand globally.

USE CASES OF JENKINS

1. CONTINUOUS INTEGRATION

Continuous integration is a software development method where members of the team can integrate their work at least once a day. In this method, every integration is checked by an automated build to search the error.

Continuous Integration Example: Nokia

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

Continuous Integration With Jenkins

Let us imagine a scenario where the complete source code of the application was built and then deployed on test server for testing. It sounds like a perfect way to develop software, but, this process has many flaws. I will try to explain them one by one:

• Developers have to wait until the complete software is developed for the test results.
• There is a high possibility that the test results might show multiple bugs. It was tough for developers to locate those bugs because they have to check the entire source code of the application.
• It slows the software delivery process.
• Continuous feedback pertaining to things like coding or architectural issues, build failures, test status and file release uploads was missing due to which the quality of software can go down.
• The whole process was manual which increases the risk of frequent failure.

It is evident from the above-stated problems that not only the software delivery process became slow but the quality of software also went down. This leads to customer dissatisfaction. So to overcome such chaos there was a dire need for a system to exist where developers can continuously trigger a build and test for every change made in the source code. This is what CI is all about. Jenkins is the most mature CI tool available so let us see how Continuous Integration with Jenkins overcame the above shortcomings.

I will first explain to you a generic flow diagram of Continuous Integration with Jenkins so that it becomes self-explanatory, how Jenkins overcomes the above shortcomings. This will help you in understanding how does Jenkins work.

The above diagram is depicting the following functions:

• First, a developer commits the code to the source code repository. Meanwhile, the Jenkins server checks the repository at regular intervals for changes.
• Soon after a commit occurs, the Jenkins server detects the changes that have occurred in the source code repository. Jenkins will pull those changes and will start preparing a new build.
• If the build fails, then the concerned team will be notified.
• If built is successful, then Jenkins deploys the built in the test server.
• After testing, Jenkins generates a feedback and then notifies the developers about the build and test results.
• It will continue to check the source code repository for changes made in the source code and the whole process keeps on repeating.

Jenkins-github

How does it work with GitHub?

Jenkins scans your entire GitHub organization and creates Pipeline jobs for each repository containing a Jenkinsfile — a text file that defines the process of building, testing, and deploying your project using Jenkins. Immediately after code is checked in or a new pull request is created, Jenkins will execute the Pipeline job and return the status to GitHub indicating whether it failed or succeeded. This process allows you to run a build and subsequent automated tests at every check in so only the best code gets merged. Catching bugs early and automatically reduces the number of problems introduced into production, so your team can build better, more efficient software.

Deployments that occur in Jenkins can also be recorded back into GitHub to audit the entire lifecycle.

2. CONTINUOUS DELIVERY

What Is Continuous Delivery?

It is a process where you build software in such a way that it can be released to production at any time. Consider the diagram below:

Let me explain the above diagram:

Automated build scripts will detect changes in Source Code Management (SCM) like Git.

Once the change is detected, source code would be deployed to a dedicated build server to make sure build is not failing and all test classes and integration tests are running fine.

Then, the build application is deployed on the test servers (pre-production servers) for User Acceptance Test (UAT).

Finally, the application is manually deployed on the production servers for release.

Why We Need Continuous Delivery

Let us understand this with an example. Imagine there are 80 developers working on a large project. They are using Continuous Integration pipelines in order to facilitate automated builds. We know build includes Unit Testing as well. One day they decided to deploy the latest build that had passed the unit tests into a test environment.

This must be a lengthy but controlled approach to deployment that their environment specialists carried out. However, the system didn’t seem to work.

What Might Be the Obvious Cause of the Failure?

Well, the first reason that most of the people will think is that there is some problem with the configuration. Like most of the people even they thought so. They spent a lot of time trying to find what was wrong with the configuration of the environment, but they couldn’t find the problem.

One Perceptive Developer Took a Smart Approach

Then one of the senior developers tried the application on his development machine. It didn’t work there either.

He stepped back through earlier and earlier versions until he found that the system had stopped working three weeks earlier. A tiny, obscure bug had prevented the system from starting correctly. Although, the project had good unit test coverage. Despite this, 80 developers, who usually only ran the tests rather than the application itself, did not see the problem for three weeks.

Without running Acceptance Tests in a production-like environment, they know nothing about whether the application meets the customer’s specifications, nor whether it can be deployed and survive in the real world. If they want timely feedback on these topics, they must extend the range of their continuous integration process.

Let me summarize the lessons learned by looking at the above problems:

Unit tests only test a developer’s perspective of the solution to a problem. They have only a limited ability to prove that the application does what it is supposed to from a users perspective. They are not enough to identify the real functional problems.

Deploying the application to the test environment is a complex, manually intensive process that was quite prone to error. This meant that every attempt at deployment was a new experiment — a manual, error-prone process.

Solution — Continuous Delivery Pipeline (Automated Acceptance Test)

They took Continuous Integration (Continuous Delivery) to the next step and introduced a couple of simple, automated Acceptance Tests that proved that the application ran and could perform its most fundamental function.

Basically, they built a Continuous Delivery pipeline, in order to make sure that the application is seamlessly deployed on the production environment, by making sure that the application works fine when deployed on the test server which is a replica of the production server.

3. CONTINUOUS DEPLOYMENT

Linkedln’s Case Study of Continuous Deployment

LinkedIn is an employment-oriented service that is mainly used for professional networking. LinkedIn’s prior system before implementing Continuous Deployment was more traditional.

The system included various branches diverging from a single trunk developed in a parallel manner. A developer would write big batches of code for various features and then wait for this feature branch to be merged into the trunk, i.e. the master branch.

Once the feature was merged into the master branch, it had to be tested again to make sure that it did not break any other code of a different feature.

Since this system included several batches of code written in isolation by various teams then merged into a single branch, this system was known as a feature branch system. This kind of system limited the scope and number of features, thus slowing down the company’s development lifecycle.

Looking at the above conditions, Linkedln decided to move from its traditional feature-based development lifecycle to continuous deployment. This required migrating the old code and building automated tools to make the new system work, halting Linkedln’s development for months.

LinkedIn’s framework after using continuous deployment includes developers writing code in tidy, distinct chunks and checking each chunk into the trunk shared amongst all LinkedIn developers. The newly-added code is then subjected to a series of automated tests to remove bugs.

Once the code passes the tests, it is merged into the trunk and listed out in a system that shows managers what features are ready to go live on the site or in newer versions of LinkedIn’s apps.

Now, let me continue this discussion by telling you the basic benefits of continuous deployment.

Benefits of Continuous Deployment

Speed — Development does not pause for releases so code is developed really fast.

Security — Releases are less risky, as before releasing, testing is performed, and all bugs are resolved.

Continuous Improvements — Continuous deployment supports continuous improvements which are visible to customers.

Case Study: Jenkins for OMS Code Branch Management

Business Challenge

Jenkins is a popular open source Continuous Integration (CI) and Continuous Delivery (CD) solution. A customer was using Jenkins to manage their front-end eCommerce development, but was not using it to manage their IBM Order Management (OMS) development projects, instead they were using Rational Team Concert (RTC) as their code repository.

As a result, they were unable to run multiple Order Management development project simultaneously, because they didn’t have a good way to manage their code base, and deployment to different environments.

Solution

Bridge Solutions migrated the customer’s Order Management code base from RTC to Jenkins, and enabled integration between Jenkins and Bitbucket to enable an instance level code management and build mechanism. The project was completed in 2 months, which included testing. This allowed them to have multiple code branches, not just a single branch, so they could support multiple development projects simultaneously.

Key Benefits

1. The Jenkins platform will enable the retailer to have multiple branches of code base and do parallel development on multiple projects. This will ease and reduce risk in builds in different environments.

2. The customer was able to decommission RTC, and save money.

3. The ability to respond to build issues early. Jenkins sends emails to specified recipients whenever a certain important event occurs, such as:

• Failed build
• Unstable build
• Successful build after a failed build, indicating that a crisis is over
• Unstable build after a successful one, indicating that there’s a regression issue.

4. Jenkins is an open source tool with support from its community and has more than 1000 plug-ins to make improve development efficiency.

5. It is easy to create a new Jenkins plugin if one is not available for a specific use case.

6. Because Jenkins is written in Java, it can be portable to almost all major platforms.

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.

Reinventing travel with an inventive technology platform

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

Thanks for Reading!