[Note]www.edureka.co/blog/what-i…Continuous integration is the most important part of DevOps, integrating the various DevOps phases. Jenkins is the best known continuous integration tool, and I know you’re wondering why Jenkins is so popular and how easy it is to learn. I’m sure all your questions will be answered by the end of this article.
What is Jenkins and why is it used?
Jenkins is an open source automation tool written in Java with plug-ins for continuous integration. Jenkins is used to continuously build and test your software projects, making it easier for developers to integrate changes into the project and for users to get new builds. It also allows you to continuously deliver software by integrating with a wide range of test and deployment technologies. With Jenkins, organizations can speed up the software development process through automation. Jenkins integrates a variety of development lifecycle processes, including build, documentation, testing, packaging, simulation, deployment, static analysis, and more. Jenkins implemented continuous integration with plug-ins. Plug-ins allow the integration of various DevOps phases. If you want to integrate a particular tool, you need to install a plug-in for that tool. Examples include Git, Maven 2 projects, Amazon EC2, HTML publishers, etc. The diagram below depicts Jenkins integrating the various DevOps phases:
Jenkins’ strengths include:
- Is an open source tool with strong community support.
- Easy to install.
- There are more than 1000 plug-ins to simplify your work. If no plug-in exists, it can be coded and shared with the community.
- It’s free.
- It is built in Java and therefore portable to all major platforms.
Some aspects of Jenkins set it apart from other continuous integration tools. Let’s look at these points.
The characteristics of Jenkins
Here are some facts about Jenkins that make it better than other continuous integration tools:
- **Jenkins is widely used, with over 147,000 active installs and over 1 million users worldwide.
- **Jenkins interconnects with more than 1000 plug-ins, making it possible to integrate with most development, test, and deployment tools.
As you can see from the above, Jenkins is in high demand worldwide. Before we dive into Jenkins, let’s understand what continuous integration is and why it’s important.
What is continuous integration?
Continuous integration is a development practice in which developers are required to commit changes to source code in a shared repository several or more times a day. Each commit made in the repository is then built. This allows the team to spot problems early. In addition, depending on the continuous integration tool, there are other capabilities, such as deploying build applications on test servers, providing build and test results to related teams, and so on. Let’s see how important it is through use cases.
Continuous integration example: Nokia
I’m sure you’ve used it at some point in your lifenokiaA mobile phone. In one of Nokia’s software product development projects, there is a process called Nightly Builds **. Nightly builds can be thought of as a precursor to continuous integration. This means that every night, the automated system pulls and builds code that has been added to the shared repository all day. The idea is very similar to continuous integration, but because of the size of the code built at night, finding and fixing errors can be cumbersome. Therefore, Nokia adopted continuous integration (CI). As a result, all commits to the source code in the repository are built. If the build results in an error in the code, the developer only needs to check that particular commit. This greatly reduces the time it takes to release new software.
Use Jenkins continuous integration
Let’s imagine a scenario where you build the complete source code for an application and then deploy it to a test server for testing. This sounds like an ideal way to develop software, but the process has many drawbacks. I will explain one by one:
- Developers have to wait until the complete software is developed to get test results.
- It is very likely that the test results will show multiple errors. These errors are difficult for developers to find because they must examine the entire source code of the application.
- This slows down the software delivery process.
- Constant feedback about coding or architectural issues, build failures, test status, and file release uploads can lead to software quality degradation.
- The whole process is manual, which increases the risk of frequent failures.
It is clear from the above that not only has the software delivery process slowed down, but the quality of the software has also deteriorated. This led to customer dissatisfaction. Therefore, to overcome this confusion, there is an urgent need for a system that allows developers to continuously trigger builds and test every change in the source code. That’s what CI is all about. Jenkins is the most mature CI tool available, so let’s see how running Continuous integration with Jenkins overcomes the above shortcomings. First, I’ll introduce you to a general flowchart for continuous integration using Jenkins so you can see at a glance how Jenkins overcomes the above shortcomings. It will also help you understand how Jenkins works.
- First, the developer submits the code to the source repository. At the same time, the Jenkins server periodically checks the repository for changes.
- Shortly after the commit, the Jenkins server detected a change in the source code repository. Jenkins will pull out the changes and begin preparing the new build.
- If the build fails, the relevant team is notified.
- If the build is successful, Jenkins will deploy the new version on the test server.
- After testing, Jenkins generates feedback and informs developers of build and test results.
- It continues to check for changes to the source code in the source code repository, and the process repeats itself.
You now know how Jenkins overcomes the shortcomings of traditional SDLC. The table below shows the comparison “before and after Jenkins”.
Before and after using Jenkins
| Before using the Jenkins | After using Jenkins |
|---|---|
| The entire source code was built and tested. Finding and fixing bugs in the event of build and test failures is difficult and time consuming, which in turn slows down the software delivery process. | Every commit made in the source code will be built and tested. As a result, developers don’t need to examine the entire source code, but just focus on specific commits. New software can be released frequently. |
| Developers must wait for test results | The developer knows the test results of each submission in the source code. |
| The whole process is manual | You just need to submit the changes to the source code and Jenkins will automate the rest for you. |