Industries use cases of Jenkins

What is Jenkins?

Jenkins is an open source Continuous Integration server capable of orchestrating a chain of actions that help to achieve the Continuous Integration process (and not only) in an automated fashion.

Jenkins is free and is entirely written in Java. Jenkins is a widely used application around the world that has around 300k installations and growing day by day.

It is a server-based application and requires a web server like Apache Tomcat. The reason Jenkins became so popular is that of its monitoring of repeated tasks which arise during the development of a project. For example, if your team is developing a project, Jenkins will continuously test your project builds and show you the errors in early stages of your development.

By using Jenkins, software companies can accelerate their software development process, as Jenkins can automate build and test at a rapid rate. Jenkins supports the complete development lifecycle of software from building, testing, documenting the software, deploying and other stages of a software development lifecycle.

What is Continuous Integration?

In Continuous Integration after a code commit, the software is built and tested immediately. In a large project with many developers, commits are made many times during a day. With each commit code is built and tested. If the test is passed, build is tested for deployment. If deployment is a success, the code is pushed to production. This commit, build, test, and deploy is a continuous process and hence the name continuous integration/deployment.

A Continuous Integration Pipeline is a powerful instrument that consists of a set of tools designed to host, monitor, compile and test code, or code changes, like:

• Continuous Integration Server (Jenkins, Bamboo, CruiseControl, TeamCity, and others)
• Source Control Tool (e.g., CVS, SVN, GIT, Mercurial, Perforce, ClearCase and others)
• Build tool (Make, ANT, Maven, Ivy, Gradle, and others)
• Automation testing framework (Selenium, Appium, TestComplete, UFT, and others)

Why use 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.

Before Jenkins

1. Once all Developers had completed their assigned coding tasks, they used to commit their code all at same time. Later, Build is tested and deployed. Code commit built, and test cycle was very infrequent, and a single build was done after many days.
2. Since the code was built all at once, some developers would need to wait until other developers finish coding to check their build,
3. Code build and test process are entirely manual, so there are a lot of chances for failure.
4. The code is deployed once all the errors are fixed and tested.
5. Development Cycle is slow.

After Jenkins

1. The code is built and test as soon as Developer commits code. Jenkin will build and test code many times during the day. If the build is successful, then Jenkins will deploy the source into the test server and notifies the deployment team. If the build fails, then Jenkins will notify the errors to the developer team.
2. The code is built immediately after any of the Developer commits.
3. Since the code is built after each commit of a single developer, it's easy to detect whose code caused the built to fail
4. The code is deployed after every successful build and test.
5. The development cycle is fast. New features are more readily available to users. Increases profits.

Jenkins Architecture

In this section, we will focus our discussion on how Jenkins helps both developers and testers? Let’s discuss the Jenkins continuous integration to understand that.

In the beginning, developers make all the changes that they want in the source code. This code is stored in the Git repository. Modification is followed y committing those changes. Jenkins server is doing its job and tracking changes made to the files stored in the repository. The changes made by the developers are detected by the Jenkins server. Jenkins then pulls these changes and begins working on a new built of the software based on those changes, 

The concerned team receives a notification if the build fails. On the other hand, if the build is successful, Jenkins deploys it on the test server. Developers are notified about build development and testing results. This cycle continues to repeat. 

Now that we understand how Jenkins works, it will be easier for us to make out the difference in its working and that of the ways that were used for releasing and deployment before it. 

So before Jenkins came to the fore, the process involved the building and testing of the complete source code. Locating and fixing errors and bugs were not at all easy tasks that used to delay the delivery of software. Developers had to wait a long time for test results. Deployment used to happen manually.

After Jenkins, all the changes in the source code are tested once they are made. Developers are not required to go through the complete source code for locating errors and bugs. The launch of build releases is much more frequent now. Developers are informed about the test results of all the changes and commits. Once you commit the changes, the Jenkins server can start executing other processes. 

Real-world case study of Continuous Integration In Netflix

NETFLIX

Once a line of code has been built and tested locally using Nebula, it is ready for continuous integration and deployment. The first step is to push the updated source code to a git repository. Teams are free to find a git workflow that works for them.

Once the change is committed, a Jenkins job is triggered. Netflix use of Jenkins for continuous integration has evolved over the years. We started with a single massive Jenkins master in our datacenter and have evolved to running 25 Jenkins masters in AWS. Jenkins is used throughout Netflix for a variety of automation tasks above just simple continuous integration.

A Jenkins job is configured to invoke Nebula to build, test and package the application code. If the repository being built is a library, Nebula will publish the .jar to our artifact repository. If the repository is an application, then the Nebula OS package plugin will be executed. Using the Nebula OS package (short for “operating system package”) plugin, an application’s build artifact will be bundled into either a Debian or RPM package, whose contents are defined via a simple Gradle-based DSL. Nebula will then publish the Debian file to a package repository where it will be available for the next stage of the process, “baking”.

So in short Jenkins is use in Netflix for configuring to invoke Nebula to build, test and package the application code.

I hope you get some knowledge from this Artcle .

Thank you !!

Have a Nice day !!