Jenkins is an open-source automation server that is used for continuous integration and continuous deployment (CI/CD) for software development processes such as code building, testing, and deploying. Jenkins has hundreds of plugins that help automate software building and deployment. Jenkins is a server-based automation tool that runs in servlet containers such as Apache Tomcat. It supports version control tools such as SVN and Git to automate the CI/CD.
What is Continuous Integration?
Continuous Integration is a practice in which one or more developers integrate their code changes into a central code-base repository as early as possible, and the resulting artifacts are automatically created and tested. This allows the developer to add code changes more frequently to a central repository system and helps to easily identify the code’s correctness and errors with the help of logs and messages.
Why Continuous Integration?
To understand why we need continuous integration, first we need to know what the problem is without CI. Below is a picture representing the code build and deployment process without CI.
In the above picture, we can see multiple developers committing frequent code changes at irregular time interval to a central source code repository (SVN or Git). This source code is then pulled to the next level for the build process with the help of build tools (ant, maven, or gradle), and once the build is successful, the source code is moved to the test environment for the testing. After the testing completes, if any bugs or any test failures are found, they will be notified to the developers with the help of email communication; otherwise, if everything is fine, it will be moved to release (DEV, QA, or PROD).
In the above approach, the developers who commit the code and the one who is integrating all the code changes have to wait a long time for the test result, and the one who is doing code testing has to check the entire source code and dig down into the code base for any test failure, as many developers may be working on a single file and committing the changes, which makes it very difficult to identify due to whose commits the test result is failing.
Continuous Integration
In continuous integration, multiple developers commit the changes to the source code repository (SVN or Git). Jenkins server checks the source code repository at regular intervals and pulls any newly added code to the continuous integration server, where all the required steps—build, compile, test, and deploy—happen. i.e., all the changes made to the source code are built continuously. At any time between code build and test, if any failure occurs, it will be immediately notified to the developers with the completed commit message and full error stack trace. If there are no issues detected, it will move on to the release, and whether the release is completed or failed will also be notified to the developers.
Comparison Before Continuous Integration and After Continuous Integration
| Before Continuous Integration | After Continuous Integration |
| The entire source code needs to be built and then tested. | Every commit made to the source code is built and tested. |
| The developers have to wait for the test result until the entire source is built and tested. | The developers get the test result of every commit made to the source code at runtime. |
| There is no feedback or error trace. | CI shows the feedback with a complete error stack trace. |
Features Of Jenkins
Following are the features of Jenkins:
- Easy Installation
- Jenkins is a Java-based open-source automation server that can be easily installed over various operating systems (Windows, Mac OS X, and Unix).
- Easy Configurations
- Jenkins provides a web interface that can be used to easily configure it and provides assistance in the build process and error checking.
- Plugins
- Jenkins supports hundreds of plugins and integrates with almost every tool in the continuous integration tool chain.
- Extensions
- Jenkins can be extended with the plugins, which opens the gate for infinite possibilities.
- Distributed Network
- Jenkins easily distribute the work across multiple machines which helps in faster continuous integrations server process across multiple platforms.
Architecture Of Jenkins
The Jenkins architecture can be broken down into two different sections: the first in which the developers commit the code to the source code repository, and the second in which the Jenkins CI Server checks the source code repository at regular intervals and pulls any code changes every time there is any commit, and then it will use the build server to build the codes into executable files (for example, Java code builds into jar files). After this, the executable build file is deployed to the test server for testing; if the builds fail at any stage, either on the build server or the test server, feedback is sent to the developers immediately. If there is no error at any stage, then the tested application is deployed to the production server.
Single Jenkins Server Architecture Problem
If we have multiple source codes in different files and programming languages, it will require multiple builds that need to be managed. A single Jenkins server does not allow multiple builds; it can be managed with a distributed Jenkins architecture with multiple servers running different versions of Jenkins.
Jenkins Master-Slave Architecture
In Jenkins Master-Slave Architecture, the Jenkins master server checks the source code repository at regular intervals, pulls any code changes every time there is a commit, and distributes the workloads on Jenkins slave servers and allows to run multiple builds simultaneously. The Jenkins slave servers with the configured requests from the master server carry out the builds, tests and produce the test reports.
Note: Jenkins is developed using the platform-independent language Java, which allows Jenkins servers to be configured on any platform, including Windows, Mac OS, and Linux.
The Jenkins master server performs the following operations:
- Configuring and scheduling the build jobs or projects
- Distribute the codes to the slave servers for the build and execution processes.
- Monitor the slave server.
- Requesting, recording and presenting the test reports of builds on slave servers.
The Jenkins slave server perform the following operations:
- Execute the builds, test and produce the test report on the requested configuration from the master server.
- Either we can configure Jenkins slave servers to run any particular job or project, or the Jenkins master server picks the available slave server.
Advantages of Jenkins
- Fast Feedback
- Quick results on code changes for rapid bug detection.
- Time Savings
- Automation reduces manual tasks, allowing focus on core development.
- Consistent Builds
- Standardized processes ensure reliable builds for all team members.
- Improved Collaboration
- Centralized platform for better communication and status sharing.
- Easy Bug Identification
- Faster identification of problematic code changes for quicker fixes.
- Support for Multiple Environments
- Code can be tested in various setups effortlessly.
- Faster Deployment
- Automated deployment leads to quicker release of new features.
- Easy Rollback
- Simple reverting to a known-good build in case of issues.
- Enhanced Testing
- Automated tests ensure more robust and stable software.
- Historical Build Data
- Insights from past data for performance analysis and optimization.
- Extensibility and Customization
- Flexibility to integrate with various tools and services.