In the era of automation, we execute software projects to achieve our objectives quickly. Still, due to the rapid deployment of new builds given by developers, it is essential to automate the build process. Whenever a new code commit occurs, it will automatically build, tested, and results will publish. Here Jenkins comes into the picture. Jenkins is one of the most important DevOps tools through which we can build, test, and publish test results, i.e., automate the overall delivery pipeline. In this article, we will learn the fundamental introductory aspects of Jenkins. Let's start with understanding the following details:

• What is Jenkins?
• How did Software Delivery change after Jenkins?
  • Traditional Process of Software Delivery.
  • Continuous Integration and Delivery with Jenkins.
• Understanding Jenkins Architecture.
  • What is Jenkins Master?
  • What is Jenkins Slave?
• Also, what does Jenkins provide unique features?

What is Jenkins?

Jenkins is one of the most famous open-source tools which, by automating parts of the software development pipeline such as building, testing, and deployment, helps in implementing the processes of Continuous Integration (CI ) and Continuous Deployment/ Continuous Delivery (CD ) of projects. It provides a centralized platform that helps in automating the complete build pipeline, starting from the code changes to automatic creation of new builds, auto-execution of all layers of tests(Unit, Integration, and End to End ), and finally, auto-deploying the successful build. This way, it gives freedom to the developers to have more frequent changes and gives freedom to the end-users by making them available the new features more frequently. The below figure provides a basic understanding of all the stages, where it can integrate and provide an automated way to deliver and deploy software:

Now, let's try to understand where we can incorporate in the development and the testing phase of SDLC:

• It can help to achieve version control during the lifetime of our project. It supports different types of version control tools like Git, SVN, Mercurial, CVS, etc. With the help of version control tools, it is effortless to maintain the changes in a file or set of files over time.
• We also use it to build and test our software projects automatically. Whenever a new build comes, it automatically triggers and gives the user a fresh build. So, we can add "perform build" functionality with the help of Jenkins.
• It can help to achieve continuous testing. Whatever scripts develop in any programming language, it can be quickly executed with the help of Jenkins to test the application and get results in various formats with the help of multiple plugins provided by Jenkins.
• It also supports configuration management using many popular tools like Chef/puppet. In Jenkins, we can manage the triggering of builds according to custom configuration management options via its web service.
• It can also support many continuous deployment tools. Through Jenkins, continuously releasing software projects in the production servers in an automated fashion can be achieved.
• It can be used for Continuous monitoring of either performance or deployment or triggering of any new build in an automated fashion.

So, in a nutshell, It can help automate any of the phases of SDLC, starting from development to deployment and even after deployment in the form of monitoring.

How did Software Delivery Change after Jenkins?

We know that Continuous Integration is a process through which once the developer commits their changes to some shared repository, they are built, tested, and deployed at a regular planned frequency. Jenkins is one of the tools that has eased the automation of all these phases of SDLC. The ultimate objective is:

“Whenever any code commit occurs from developers, the build should be triggered automatically and should provide feedback about the build.”

But, this was not always the case. In the traditional process of SDLC, the feedback loop was very long and slow. Let's quickly understand the conventional way of software development and delivery, before the tools such as Jenkins came into the picture. We will be able to understand the differences that these CI tools have brought in the delivery pipeline.

Traditional Process of Software Delivery

Let's understand the traditional process of software delivery with the help of the below diagram:

The complete functioning of the above process is as below:

• Generally, the entire source code will be at a shared repository.
• Every developer in the project commits their changes in the source code in the shared repository daily or at a predefined time.
• On the parallel, there will be a build server that is capable of pulling the code from the shared repository at a predefined time.
• Every night, a daily, or weekly, the development team pushes their code to a shared repository from where the build server pulls commits in the source code. The build frequency can be any pre-defined frequency.
• We test the Build on the build server, and results will appear either fail or pass.
• If we pass the build, it will deploy on the production server, and if it fails, developers need to fix the failure, and after fixing, they need to repeat the same process.

Continuous Integration and Delivery with Jenkins

In the above section, we saw the functioning of the traditional process, which needs lots of effort as every time a big chunk of code which, the build server needs to pull and then built. So, we need some automated process through which whenever a code-commit occurs, the build should trigger immediately and automatically. Let's understand how Jenkins has helped in implementing this automated process and has eased the process of implementing the Continuous Integration process:

Let's understand the functioning of the above process:

• Generally, we can have any no of developers, so developers need to commit or check-in their code in the shared repository.
• Jenkins server checks this shared repository frequently or at regular intervals of time. As soon as it detects the new commit, it will pull all those changes and start preparing the latest build.
• Here two possibilities will be present. Either build will fail, or it will be successful. If the build fails, then immediately, the notification will go to the team.
• If the build will be successful, Jenkins is now ready to deploy this successful build to the test server.
• After running the build on the test server, the team will get the notification of the test and build results.
• It will be an on-going process, and the teams will always have a deployable build with each of the successful commits.

Now that we have understood the traditional process of software deployment and the modern way using the Continuous Integration with Jenkins, Let's know the differences between these two approaches:

++Traditional Process of Software Delivery++	++Continuous Integration Process of Software Delivery++
The entire source code will process, so it will take much time to produce the results. As a result, developers need to wait much longer, making the feedback loop too long.	The entire code base is compiled each time with the code-checkin since, in CI, code is committed in smaller chunks, so it is easy to diagnose issues.
If the build is successful, then it is fine, but if the build has some failure, it will be challenging for developers to fix those bugs, as the code in the build will have commits from multiple developers, and the size of changes will also be too large.	If builds fail, developers don`t need to see the entire code. They need to see only the last commit that they did in the source code. So, in this case, the bug fixing process will be much simpler.
If the customer wants early feedback on the product, then it is not possible in this case as we need to wait until the complete application develops.	If the customer is interested in early feedback of product or progress regarding product development, then the team can easily give this feedback because, in this case, we know the exact status of builds at an early stage.
The software delivery process will be slow in this case.	The quick bug fixes and regular deployments will make the software delivery much faster.
This process involves lots of manual efforts.	Almost the whole delivery process will be automated unless there is a specific ask or use case.

So, after reading all these benefits provided by the Continuous Integration and automation of the delivery process, let's understand the intricacies of Jenkins, so as we know the tool in a better way before start using the same.

Understanding Jenkins Architecture

Jenkins can automate the build process of projects in all the programming languages and on all the operating systems. It works in a distributed architecture, by using the client-server or master-slave architecture. The below figure shows a high-level architecture of Jenkins :

As the above diagram shows, there are two primary components of this architecture:

• Jenkins Master.
• Jenkins Slave.

Before proceeding towards the description of components, let's understand first that why distributed architecture is required:

• Suppose we are working on larger and heavier projects that get built regularly, so it`s not a good idea to put a complete load on the central Jenkins Server as it would not be efficient. So, here we need to configure different Jenkins machines as slave machines capable of taking the load from the master Jenkins server.
• Sometimes, we need to build or test the builds on different environments/operating systems, so in this case, the assignment of each Jenkins slave machine for each environment is the best idea to distribute the load as well as to get results soon.

I hope the above points justify the need for a distributed architecture. Now, Let's understand the details and tasks of the significant components of Jenkins :

What is Jenkins Master?

Jenkins Master is the central component of Jenkins's distributed system, and majorly performs the following tasks:

• Schedule and execute the builds, either on the master itself or on the slaves.
• Distributing and dispatching the builds to slaves.
• Gathering and displaying the results gathered from slaves.
• Monitor slaves, including switching on/off slaves on need basis.
• Monitor and pull codes from repositories.

What is Jenkins Slave?

Jenkins Slave is the slave machine/node where the actual builds run. Jenkins Master assigns jobs to Jenkins Slave that it runs and provides reports back to the Jenkins Master. The below points gives a basic gist of what all activities a Jenkins Slave can perform:

• Jenkins Slave is also called a Node or a slave agent.
• Jenkins Slave is a java executable that runs on a remote machine. All these nodes configure in any server like Windows, Mac OS, Linux, so it is clear that it is Platform independent.
• Jenkins Slaves keep an eye on Jenkins master for instructions regarding the build execution. As soon as Jenkins Master assigns some build to Jenkins slave, it immediately executes that build and gives results.
• If we configure any projects specifically on a particular Slave, then only that project will run on that specific slave; otherwise, Jenkins master will see the next available build automatically for execution.

What are the unique features provided by Jenkins?

Jenkins provides various unique features, which makes it a popular tool in the DevOps community. The below table list a few of those features:

++Feature++	++Description++
Operating  Systems	It is effortless to install Jenkins on different types of OS, like Windows, macOS, and Unix.
Easy to Upgrade	It has frequent release cycles, so it is effortless to upgrade Jenkins for new features.
Plugins Feature	It has more than 1000 third party plugins which we can associate for integration with any tool.
Open Source	It is the open-source tool with the wide support of the community. Therefore, it is straightforward to troubleshoot problems, if any.
Distributed Nature	It is easily distributable due to its master-slave architecture, which we saw in the above section. It can distribute work across multiple machines for efficiently handling the build processes, tests, and deployments.
Shell Scripts and Windows Commands	We can execute a shell script as well as windows commands using Jenkins to perform specific actions.
Notification Support	It has notification capability regarding the status of builds in the form of an email.
Parallel Execution	Parallel execution of builds in a single workflow is possible in Jenkins with the help of the Pipelines feature.
Easy User Interface	It has an easy user interface so anybody can easily understand and use it.

Considering all these features and benefits provided by Jenkins, no doubt, Jenkins is one of the top choices for all the teams who are moving/starting the journey of Continuous Integration.

Key Takeaways:

• Jenkins is one of the most popular open-source tools. It helps in implementing Continuous Integration(CI) and Continuous Deployment/ Continuous Delivery(CD) of projects.
• We can achieve a Version Control system, Build process, Continuous Testing, Continuous monitoring, Configuration management, and Continuous deployment.
• It has changed the traditional process of software delivery through its continuous integration and delivery functionality.
• Additionally, it provides distributed architecture to implement its scaling functionality. We do it through scheduling jobs by the master and running actual jobs on the slave machines.

Let's move to the next article, where we will kick off the Installation Process of Jenkins on different Operating systems.