Jenkins

As we know by doing anything manually in any technology there are lots of issues comes firstly its time consuming and there is a lot of probability of errors come. But instead of doing things manually by human beings if we can take help from some program or we can say some automation program that will run on some computer/o.s and do the things for us automatically then the things work fast and the chances of errors come to less.

So, there are lots of tools available in the market for automation but the most popular tool or program that we need to automate our development workflow so that we as human beings can focus on the work that matters most is Jenkins.

What is Jenkins?

Jenkins is an open-source continuous integration tool or automation server written in Java.

It gives us a faster and more robust way to integrate our entire chain of build, test, and deployment tools that we can easily build ourselves.

Today Jenkins is the leading open-source automation server with some 1,600 plugins to support the automation of all kinds of development tasks related to building, testing, and delivering or deploying software. so that humans can spend their time doing things machines cannot.

Jenkins is commonly used for:

1. Building projects
2. Running tests to detect bugs
3. Static code analysis
4. Deployment

Execute repetitive tasks, save time, and optimize our development process with Jenkins.

Jenkins can be installed through native system packages, Docker, or even run standalone by any machine with a Java Runtime Environment (JRE) installed.

What are Plugins?

A plugin is an enhancement to the Jenkins system. They help extend Jenkins capabilities and integrated Jenkins with other software

Plugins help to integrate other developer tools into the Jenkins environment, add new user interface elements to the Jenkins Web UI, help with the administration of Jenkins, and enhance Jenkins for build and source code management.

One of the more common uses of plugins is to provide integration points for CI/CD sources and destinations.

These include software version control systems (SVCs) such as Git and Atlassian BitBucket, container runtime systems — especially Docker, virtual machine hypervisors such as VMware vSphere, public cloud instances including Google Cloud Platform and Amazon AWS, and private cloud systems such as OpenStack. There are also plugins that assist in communicating with operating systems over FTP, CIFS, and SSH.

Jenkins Features:

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

1. Adoption: Jenkins is widespread, with more than 147,000 active installations and over 1 million users around the world.
2. 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. Before we dive into Jenkins it is important to know what is Continuous Integration and why it was introduced.

What is Continuous Integration?

Continuous Integration is a development practice in which the developers are required to commit changes to the source code in a shared repository several times a day or more frequently. Every commit made in the repository is then built. This allows the teams to detect the problems early. Apart from this, depending on the Continuous Integration tool, there are several other functions like deploying the build application on the test server, providing the concerned teams with the build and test results, etc.

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 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 the 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:

1. Developers have to wait until the complete software is developed for the test results.
2. 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.
3. It slows the software delivery process.
4. Continuous feedback pertaining to things like coding or architectural issues, build failures, test status and file release uploads were missing due to which the quality of software can go down.
5. 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 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 works.

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 the build is successful, then Jenkins deploys the built-in test server.
• After testing, Jenkins generates 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.

HP Case Study:

In 2006, HP’s LaserJet Firmware division built different products(printers, scanners, etc.). This entire project was led by the director of LaserJet Firmware, Gary.

He analyzed developers spent around 5% of their time developing and supporting new features while the rest went into planning, integration, and testing.

Problem

1. Gary’s team consisted of around 400+ developers distributed across countries like the USA, Brazil, and India but only made two software releases per year! This is because LaserJet models had separate code bases which developed enumerable inefficiencies.
2. Software bugs were detected via manual testing after 6 weeks of writing code. Fixing a bug that incurred within a code weeks ago, was labor-intensive and tiresome for the developers.
3. This is where the team needed a new approach to remove the bottleneck

Solution

The HP team adopted a Continuous Integration/Continuous Deployment (CI/CD) pipeline and test automation.

As we can see in the given figure below, their first step was to create a common platform to support all the products and models. This was called trunk-based development or Continuous Integration which eliminated toil caused by the integration of different code branches.

ETSY Case Study:

Etsy is one of the earliest Companies Using DevOps. It is an American e-commerce website focused on selling handmade and vintage supplies.

Problem

1. Initially, Etsy struggled with the development of its organization because it adopted the monolithic architecture.
2. Their deployment rate was about two times a week resulting in the isolation of departments. Etsy had to find a way out of this traditional system.

Solution

The new chief technology officer(CTO) brought in a team to adopt DevOps practices. As shown in the figure below, the CI/CD pipeline helped in deploying services about 50 to 100 times a day.

The first release of code is to a random set of users within the organization. After testing and feedback, it is then pushed on to the entire community of Etsy.

The Wrap-Up

I have done my best to give you all a basic idea about Jenkins and How it Works actually in the simplest way I can.

In the upcoming days I am going to publish lots of articles on different automation Tools and Technologies, So definitely follow me on Medium.

Here is my LinkedIn profile if u have any queries definitely comment below or DM me on Linkedin

Abhay Agarwal - Arth Technical volunteer - ARTH - The School of Technologies | LinkedIn