Jenkins with its Industry use cases

What Is Jenkins ?

Jenkins is an open-source automation tool written in Java with plugins built for Continuous Integration purposes. Jenkins is used to build and test your software projects continuously making it easier for developers to integrate changes to the project, and making it easier for users to obtain a fresh build. It also allows you to continuously deliver your software by integrating with a large number of testing and deployment technologies.

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:

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.

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

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

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.

Before and After Jenkins

Use Cases of Jenkins

with the uses of Jenkins, one can convert a command prompt code into a GUI button click. This can be done by wrapping up the script as a Jenkins job. Parameterized Jenkins jobs can be created for customization or to take user input. Thus, hundreds of lines of code writing can be saved.

Jenkins jobs are usually small tools. They serve small purposes and quite simple. Jenkins provides pipeline plugin using which multiple jobs can be combined. Pipelining provides such benefit which Linux users can understand more than anyone. Both sequential or parallel combination is possible.

A large team uses a centralized platform for communication. Slack is one such most popular platform. Slack integration can be done to Jenkins and thus communication such as activities have been triggered, its time, users name, results etc. can be shared with other people.

Jenkins jobs, when run, capture console output from stdout as well as stderr. Troubleshooting with the uses of Jenkins is also very clear. For performance tuning each individual job, run timing can be measured and slowest step can be identified using Time stamper plugin.

For project management, each activity is wrapped as a Jenkins job. For each Jenkins job, 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,
  • Naginator Plugin,
  • Git Plugin, and
  • GitHub pulls request builder plugin.

Sometimes things work great locally but fail when pushed on a central system. This happens because, by the time they push, things change. Continuous Integration tests the code against the current state of a code base and is done in the production-like environment.

CI servers such as Jenkins can check code for test coverage. Tests increases code coverage. This inspires transparency and accountability in team members. Results of tests are displayed on build pipeline which ensures team member follow required guild lines. Code coverage similar to code review ensures that testing is a transparent process among team members.

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. Changes before a merge activity can be made visible too. This can be done in a dynamic staging environment, and after they are merged it is deployed directly to a central staging system, pre-production system or even a production environment.

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.

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.

Conclusion

With great progress in software technologies, Companies requires development teams to produce and deliver high-quality software better and faster than their competition. Today, development teams are building scalable and efficient software delivery engines by creating repeatable processes which standardize development and its best practices. Automated testing is one such activity by which developer’s code is tested in the same standard way for every change and every cycle so that management and other users can trust that every change is well tested before it is moved to production.

Uses of Jenkins can save a lot of time for developers, improves code quality and coverage and provide management great control over software development. Thus, It is very well appreciated and a lot of companies uses it on a daily basis. It’s a great tool to learn for upcoming software developers too.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store