Intro to Jenkins

Jenkins is an open-source server that is written entirely in Java. It lets you execute a series of actions to achieve the continuous integration process, in an automated fashion.

This CI server runs in servlet containers such as Apache Tomcat. Jenkins facilitates continuous integration and continuous delivery in software projects by automating parts related to build, test, and deployment. This makes it easy for developers to continuously work on the betterment of the product by integrating changes to the project.

Jenkins automates the software builds in a continuous manner and lets the developers know about the errors at an early stage. A strong Jenkins community is one of the prime reasons for its popularity. Jenkins is not only extensible but also has a thriving plugin ecosystem.

Some of the possible steps that can be performed using Jenkins are:

• Software build using build systems such as Gradle, Maven, and more.
• Automation testing using test frameworks such as Nose2, PyTest, Robot, Selenium, and more.
• Execute test scripts (using Windows terminal, Linux shell, etc.
• Achieve test results and perform post actions such as printing test reports, and more.
• Execute test scenarios against different input combinations for obtaining improved test coverage.
• Continuous Integration (CI) where the artifacts are automatically created and tested. This aids in identification of issues in the product at an early stage of development.

Architecture Of Jenkins

Before we dive into how Jenkins work, we must understand the architecture of Jenkins. These are the series of steps that outlines the interaction between different elements in Jenkins:

1. Developers do the necessary modifications in the source code and commit the changes to the repository. A new version of that file will be created in the version control system that is used for maintaining the repository of source code.
2. The repository is continuously checked by Jenkins CI server for any changes (either in the form of code or libraries) and changes are pulled by the server.
3. In the next step, we ensure that the build with the ‘pulled changes’ is going through or not. The Build server performs a build with the code and an executable is generated if the build process is successful. In case of a build failure, an automated email with a link to build logs and other build artifacts is sent to the developer.
4. In case of a successful build, the built application (or executable) is deployed to the test server. This step helps in realizing continuous testing where the newly built executable goes through a series of automated tests. Developers are alerted in case the changes have caused any breakage in functionality.
5. If there are no build, integration, and testing issues with the checked-in code, the changes and tested application are automatically deployed to the Prod/Production server.

A single Jenkins server might not be sufficient to realize the following requirements:

• Testing needs to be performed on different environments (i.e. code written using different languages e.g. Java, Python, C, etc. are committed to the version control system), where a single server might not suffice the requirement.
• A single Jenkins server might not be sufficient to handle the load that comes with large-scale software projects.

In such scenarios, the distributed (or Master-Agent) architecture of Jenkins is used for continuous integration and testing. Diving deeper into how does Jenkins works, we take a look at the architecture of Jenkins.

Master- Agent Architecture In Jenkins

The master-agent (or distributed) architecture in Jenkins is used for managing distributed builds. The Master and Agent(s) communicate through the TCP/IP protocol.

These are the roles and responsibilities of the Jenkins Master and Agent(s):

Jenkins Master

The main server in Jenkins is the Master. Here are the jobs handled by Jenkins Master:

• Schedule build jobs
• Choosing the appropriate agent in the master-agent ecosystem for dispatching the builds.
• Monitor agents and take them online/offline as and when required.
• Presenting the build results (and reports) to the developer.

The Jenkins master can also execute the jobs directly but it is always recommended to select the appropriate agent(s) for build and execution-related tasks.

Jenkins Agent(s)

A agent is a remote machine that is connected to the Master. Depending on the project and build requirements, you could opt for ‘N’ number of agents. agents can run on different operating systems and depending on the ‘type of build request’, the appropriate Agent is chosen by the Master for build execution and testing.

Here are the jobs handled by the Jenkins Agent(s):

• Listen to commands from the Jenkins Master.
• Execute build jobs that are dispatched by the Master.
• Developers have the flexibility to run the build and execute tests on a particular agent or a particular type of Agent. The default option is Jenkins Master selecting the best-suited Agent for the job.