Jenkins: Automation Server and its use case

What is Jenkins?

Jenkins is a self-contained, open-source automation server that is written in Java and contains a rich source library of plugins for Continuous Integration purposes. It is used to automate all sorts of tasks related to building, testing, and delivering or deploying software. Jenkins can be installed through native system packages, Docker, or even run standalone by any machine with a Java Runtime Environment (JRE) installed. It is a server-based application and thus requires a web server like Apache Tomcat. The reason Jenkins became so popular is that of its monitoring of repeated tasks that arise during the development of a project. Since it is a CI/CD tool it enables all the developers to integrate changes to their project and make it easier to deploy a fresh build and hence provides users a fresh build. It also promotes continuous delivery of the software by integrating with a large number of testing and deployment technologies. Jenkins supports the complete development lifecycle of software from building, testing, documenting the software, deploying, and other stages of the SDLC.

What is Continuous Integration?

Continuous integration (CI) is the practice of automating the integration of code changes from multiple contributors into a single software project. This makes sure the code individual developers work on doesn’t divert too much. When you combine the process with automated testing, continuous integration can enable your code to be dependable. The technical goal of CI is to establish a consistent and automated way to build, package, and test applications. With consistency in the integration process in place, teams are more likely to commit code changes more frequently, which leads to better collaboration and software quality.

What are Plugins?

Plugins are the primary means of enhancing the functionality of a Jenkins environment to fulfill organization-specific use-cases needs. The Jenkins CI tool has a lot of useful plugins which are developed by an active, and open source community, which has developed hundreds of useful plugins. These plugins eliminate the need to create fancy, half-tested logic to accomplish tasks, solving common problems with minimal pain, and also promote reusability across projects. A few of the Plugins are:

  • Build Flow
  • Delivery Pipeline
  • Build Monitor
  • Git
  • Build Pipeline
  • Email Extension
  • Build Name Setter
  • Heavy Job
  • Build Timeout
  • Join

Features of Jenkins

1. Jenkins lowers the Effort of repeated coding

With the help of Jenkins, a user can convert a code with some repetitive steps of instructions in a one-click task by wrapping up the whole script under Jenkins job.

2. Integration of Individual Jobs

The developers can group multiple Jenkins jobs with the help of a pipeline. The pipeline is a feature of Jenkins which enables us to group multiple jobs which is extremely helpful.

3. Effortless Auditing

Jenkins jobs capture console output from stdout as well as stderr. For performance tuning each job can be measured, and the slowest step can be identified using the Time stamper plugin.

4. Greater data support for project management

Activity is denoted as Job in Jenkins, and each job’s success or failure can be identified, and job completion time can be measured. Jenkins supports REST API or SDK to measure success, failure, or time.

Some useful Jenkins plugins are given below:

  • Pipeline Plugin,
  • Slack Plugin,
  • thinBackup,
  • Timestamper,
  • Dashboard View,
  • JobConfigHistory Plugin,
  • Build-timeout,
  • Navigator Plugin,
  • Git Plugin, and
  • GitHub pulls the request builder plugin.

5. Manual Tests option

Continuous Integration tests the code against the current state of a code base and is done in the production-like environment which avoids the situation of code working locally but not on a centralized system.

6. Increased Code Coverage

Code coverage can be tested by the code coverage tools and by integrating it with the CLI tool like Jenkins. This inspires transparency and accountability in team members. Results of tests are displayed on the build pipeline which ensures team members follow required guild lines.

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

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

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

Industry Use-Cases of Jenkins

There are more than 2833 companies that use Jenkins for CI/CD including Facebook, Netflix, and Udemy.

Continuous Integration of Facebook

For many years, the engineers at Facebook pushed the front-end code three times a day using a simple master and release branch strategy. Engineers would request cherry-picks — changes to the code that had passed a series of automated tests — to pull from the master branch into one of the daily pushes from the release branch.

But it took a certain amount of human effort in the form of release engineers, in addition to the tools and automated systems in place, to drive the daily and weekly pushes out the door. By 2016, they realized that the branch/cherry-pick model was reaching its limit. It came to notice they were ingesting more than 1,000 diffs a day to the master branch, and the weekly push was sometimes as many as 10,000 diffs. The amount of manual effort needed to coordinate and deliver such a large release every week was not sustainable. They decided to move to a quasi-continuous “push from master” system in April 2016. While a true continuous push system would deliver every individual change to production soon after it landed, the code velocity at Facebook required developing a system that pushes tens to hundreds of diffs every few hours. The changes that get made in this quasi-continuous delivery mode are generally small and incremental, and very few will have a visible effect on the actual user experience. Each release is rolled out to 100 percent of production in a tiered fashion over a few hours, so we can stop the push if we find any problems.

First, diffs that have passed a series of automated internal tests and land in the master are pushed out to Facebook employees.

This quasi-continuous release cycle comes with several advantages:

  • It eliminates the need for hotfixes. In the three-push-a-day system, if a critical change had to get out and it wasn’t during one of the scheduled push times, someone had to call for a hotfix.
  • It allows better support for a global engineering team. They tried to schedule the three daily pushes to accommodate our engineering offices around the world. The new quasi-continuous system means all engineers everywhere in the world can develop and deliver their code when it makes sense for them.
  • It provides a forcing function to develop the next generation of tools, automation, and processes necessary to allow the company to scale. These teams all came together because they wanted to see the main project of a faster push cycle succeed. The improvements we made will help ensure the company is ready for future growth.
  • It makes the user experience better, faster. When it takes days or weeks to see how code will behave, engineers may have already moved on to something new. With continuous delivery, engineers don’t have to wait a week or longer to get feedback about a change they made. They can learn more quickly what doesn’t work, and deliver small enhancements as soon as they are ready instead of waiting for the next big release.

Continuous integration with Jenkins

In the code lifecycle, firstly the developer commits the code to the source code repository and the Jenkins server keeps a check on the repository at regular intervals for changes. 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. Then If the build fails, then the concerned team will be notified and 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.

Thank you for reading!!!