History of Jenkins
Just like we have so many interesting stories about the development of so many technologies and tools over the years, we have one for Jenkins, too. It goes back to 2004, Kohsuke Kawaguchi, the developer of Jenkins, was working with Sun Microsystems as a Java developer.
Little did Kawaguchi know that the future had something very special in store for him. At that time, Kawaguchi was involved in several development projects. He didn’t like breaking the builds due to code failure. This made him look for something that could help him know whether the code will work or not before it is committed to the repository.
This curiosity led the way to the development of an automation server named Hudson. In 2011, there was an infamous dispute between the independent Hudson open source community and Oracle, which now has Sun Microsystems under its umbrella.
This dispute led to a fork, which was named Jenkins. Both Jenkins and Hudson continued to exist for a long time; however, Jenkins was the more preferred choice. The Hudson project was shut down in January 2020. Jenkins is still active.
What is Jenkins?
Jenkins can be termed as an automation tool that is used by DevOps teams looking to bring continuous integration into their projects. It is open-source software that is built in Java. It is used through the lifecycle of software development.
Not just in development and testing, but in deployment as well. It allows developers to integrate changes much easily into their projects. Jenkins is also used for the continuous delivery of software projects.
How does continuous integration work?
Continuous integration (CI) is an integral part of the software development process. It can consist of a number of different tasks, including the use of unique functionality in the repository, feature development, and bug fixes amongst others.
A continuous integration tool, such as Jenkins, is great in identifying issues with current application sources and provides speedy response by checking the integration process with the help of automated build and test features.
Continuous integration has come from a programming model that is associated with the Agile methodology. However, the concept can still be applied to all those programming models that are iterative in nature.
The waterfall models and other such development approaches can also benefit from what continuous integration has to offer. CI often works in tandem with continuous delivery (CD) to deliver executable code to production at a much faster pace and in an automated way. Listed below are common CI practices:
- Regular code committing
- Build staging
- A build machine dedicated to the integration
- Continuous feedback
- Developer test categorization
Continuous integration can be released at whatever frequency you deem appropriate considering your project and company. So, companies that use CI have more regular releases than those that use traditional software development processes.
More and more companies have started using CI because of one simple fact — even the minutest of change in the code could give rise to a new build. CI can give continuous feedback during the development of software.
This helps DevOps teams to get rid of the errors in every stage of development. It also detects problems quite early in the development process. This makes these problems less disruptive, not too complex, and easy to handle.
What is Jenkins pipeline?
A Jenkins pipeline is a combination of jobs, tasks, or events that are connected to each other in a sequence. In other words, it is a group of plugins that enable continuous delivery pipelines to be easily integrated and implemented. Extendable automation works to support a pipeline in the creation of both complex and simple delivery pipelines in the form of code and with the help of domain-specific language or DSL.
Let us now discuss a little about continuous delivery pipelines and how they work. The basic characteristic of a Jenkins pipeline is that each event or task or job that it holds is dependent in one way or the other on one or more of these events, jobs, or tasks. Continuous delivery pipelines feature different states, such as build, test, deploy, release. All these states are connected to each other.
A continuous delivery pipeline is a sequence that events of each of these states work in. It is an automated expression that processes required for getting version control software. All the changes that are made to the software have to pass through several complex processes before the software is released. This process also ensures that the software is developed in a repeatable and reliable way and involves multiple testing and deployment stages, which the software progresses through.
JenkinsFile is a text file that is used to define Jenkins pipelines. JenkisFile is often used to implement pipelines in the form of code, and this entire process is defined using DSL. You can also use the JenkinsFile to write down the steps that need to be followed to run Jenkins pipelines. Mentioned below are some benefits of using JenkinsFile:
- It makes reviewing the code on the pipeline easy.
- It can help you execute pull requests for all the pipelines that you have created for different branches.
- It is the one and the only source for your pipelines that can be modified by different users.
- It can help you conduct an audit on your Jenkins pipeline.
Why should you use Jenkins pipeline?
Jenkins automates that software development process through its continuous integration capabilities. You can use different use cases to create a number of automation jobs and then use Jenkins pipeline to run all of them. Listed below are a few reasons for using Jenkins pipeline:
- As it is implemented in the form of a code, Jenkins pipeline can have a number of users who can edit and execute the process.
- It supports projects that are larger in size than usual. Running multiple projects at a time or using pipelines in a loop are all possible.
- They are robust. You don’t have to worry if your server restarts under unforeseen circumstances. Jenkins pipeline would resume automatically.
- The pipeline process can be paused and not resumed until you receive user input.
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.
Jenkins Distributed Architecture
Jenkins manages the builds with the help of master-slave architecture. Master and slave units communicate with each other using IP/TCP protocol. Here is a little download on how it all works.
Jenkins master
This is the primary server of Jenkins. It handles a number of tasks that include but are not limited to scheduling build jobs, recording and presenting build results, dispatching builds to slaves for execution, monitoring all the slaves offline as well as online, and others. Master Jenkins is capable of directly executing build jobs.
Jenkins slave
It runs on the remote server. The Jenkins server follows the requests of the Jenkins master and is compatible with all operating systems. Building jobs dispatched by the master are executed by the slave. The project can be suitably configured to choose a specific slave machine.
Benefits of Jenkins
1. Jenkins is an open-source tool that is extremely easy to install and use. You need no extra components to use it
2. It is free and available to be used with different platforms, such as Windows, Linux, macOS, and others
3. It is widely used, so finding support on online communities is not a big problem
4. Jenkins automates all integration work. Integration issues are scarce, and so, it helps in saving time and money over the project lifecycle.
5. It is easy to configure, extend, and modify. It allows the instant generation of tests and building, automation, and deployment of code on different platforms
6. Jenkins can be configured to run CI and CD concepts properly
7. It can easily detect and fix issues. The software is always ready for a sudden release
8. Supports a variety of plugins, which allows better flexibility
9. It helps in detecting errors very early, thus saving developers a lot of time and hard work
Jenkins Use-cases :
Jenkins, itself located on GitHub, has a number of plugins for integrating into GitHub. The primary avenues for integrating your Jenkins instance with GitHub are:
- “build integration” — using GitHub to trigger builds
- “authentication integration” — using GitHub as the source of authentication information to secure a Jenkins instance.
Build integration
With the help of the Git plugin Jenkins can easily pull source code from any Git repository that the Jenkins build node can access.
The GitHub plugins extends upon that integration further by providing improved bi-directional integration with GitHub. Allowing you to set up a Service Hook which will hit your Jenkins instance every time a change is pushed to GitHub.
Going the other direction, the GitHub plugin can also feed information back into GitHub via the commit ststus API.
Authenticating with GitHub
Using the GitHub authentication plugins it is possible to use GitHub’s own authentication scheme for implementing authentication in your Jenkins instance.
The setup guide will help walk you through configuring the GitHub OAuth side, and your Jenkins instance, to provide easy authentication/authorization for users.
