!! Review & case study on JENKINS !!
🤩So guys this is my new article which give you some high level idea about JENKINS .
I Hope you will get knowledge from this article.
so ! why are you waiting ?
LOOK FOR WHAT’S AHEAD & IT WILL TAKE YOU FAR BEYOND
What is Jenkins?
Jenkins is an open source automation tool written in Java programming language that allows continuous integration.
Jenkins builds and tests our software projects which continuously making it easier for developers to integrate changes to the project, and making it easier for users to obtain a fresh build.
It also allows us to continuously deliver our software by integrating with a large number of testing and deployment technologies.
Jenkins offers a straightforward way to set up a continuous integration or continuous delivery environment for almost any combination of languages and source code repositories using pipelines, as well as automating other routine development tasks.
With the help of Jenkins, organizations can speed up the software development process through automation. Jenkins adds development life-cycle processes of all kinds, including build, document, test, package, stage, deploy static analysis and much more.
Jenkins achieves CI (Continuous Integration) with the help of plugins. Plugins is used to allow the integration of various DevOps stages. If you want to integrate a particular tool, you have to install the plugins for that tool. For example: Maven 2 Project, Git, HTML Publisher, Amazon EC2, etc.
For example: If any organization is developing a project, then Jenkins will continuously test your project builds and show you the errors in early stages of your development.
Possible steps executed by Jenkins are for example:
Perform a software build using a build system like Gradle or Maven ApacheExecute a shell scriptArchive a build resultRunning software tests
Work Flow:
History of Jenkins
Kohsuke Kawaguchi, who is a Java developer, working at SUN Microsystems, was tired of building the code and fixing errors repetitively. In 2004, he created an automation server called Hudson that automates build and test task.
In 2011, Oracle who owned Sun Microsystems had a dispute with Hudson open source community, so they forked Hudson and renamed it as Jenkins.
Both Hudson and Jenkins continued to operate independently. But in short span of time, Jenkins acquired a lot of contributors and projects while Hudson remained with only 32 projects. Then with time, Jenkins became more popular, and Hudson is not maintained anymore.
How Does Jenkins Work?
In this section of the What is Jenkins blog, we look at the internal functioning of Jenkins i.e. what happens once the developer commits changes to the repository and how CI/CD is realized in Jenkins. We also look at the Master-Agent architecture in Jenkins.
Architecture Of Jenkins
Before we dive into how does Jenkins work, we must understand the architecture of Jenkins. These are the series of steps that outlines the interaction between different elements in Jenkins:
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.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.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.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.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.
Here is the diagrammatic representation of the Jenkins architecture:
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.
What is Continuous Integration?
Continuous Integration (CI) is a development practice in which the developers are needs to commit changes to the source code in a shared repository at regular intervals. Every commit made in the repository is then built. This allows the development teams to detect the problems early.
Continuous integration requires the developers to have regular builds. The general practice is that whenever a code commit occurs, a build should be triggered.
Continuous Integration Example: Nokia
I am pretty sure you all have used Nokia phones at some point in your life. In a software product development project at Nokia, there was a process called Nightly builds. Nightly builds can be thought of as a predecessor to Continuous Integration. It means that every night an automated system pulls the code added to the shared repository throughout the day and builds that code. The idea is quite similar to Continuous Integration, but since the code that was built at night was quite large, locating and fixing of bugs was a real pain. Due to this, Nokia adopted Continuous Integration (CI). As a result, every commit made to the source code in the repository was built. If the build result shows that there is a bug in the code, then the developers only need to check that particular commit. This significantly reduced the time required to release new software.
Now is the correct time to understand how Jenkins achieves Continuous Integration.
Continuous Integration with Jenkins
Let’s consider a scenario where the complete source code of the application was built and then deployed on test server for testing. It sounds like a perfect way to develop software, but this process has many problems.
Developer teams have to wait till the complete software is developed for the test results.There is a high prospect that the test results might show multiple bugs. It was tough for developers to locate those bugs because they have to check the entire source code of the application.It slows the software delivery process.Continuous feedback pertaining to things like architectural or coding issues, build failures, test status and file release uploads was missing due to which the quality of software can go down.The whole process was manual which increases the threat of frequent failure.
It is obvious from the above stated problems that not only the software delivery process became slow but the quality of software also went down. This leads to customer dissatisfaction.
So to overcome such problem there was a need for a system to exist where developers can continuously trigger a build and test for every change made in the source code.
This is what Continuous Integration (CI) is all about. Jenkins is the most mature Continuous Integration tool available so let us see how Continuous Integration with Jenkins overcame the above shortcomings.
Let’s see a generic flow diagram of Continuous Integration with Jenkins:
Let’s see how Jenkins works. The above diagram is representing the following functions:
First of all, a developer commits the code to the source code repository. Meanwhile, the Jenkins checks the repository at regular intervals for changes.Soon after a commit occurs, the Jenkins server finds the changes that have occurred in the source code repository. Jenkins will draw those changes and will start preparing a new build.If the build fails, then the concerned team will be notified.If built is successful, then Jenkins server deploys the built in the test server.After testing, Jenkins server generates a feedback and then notifies the developers about the build and test results.It will continue to verify the source code repository for changes made in the source code and the whole process keeps on repeating.
Jenkins Master
The main server of Jenkins is the Jenkins Master. It is a web dashboard which is nothing but powered from a war file. By default it runs on 8080 port. With the help of Dashboard, we can configure the jobs/projects but the build takes place in Nodes/Slave. By default one node (slave) is configured and running in Jenkins server. We can add more nodes using IP address, user name and password using the ssh, jnlp or webstart methods.
The server’s job or master’s job is to handle:
Scheduling build jobs.Dispatching builds to the nodes/slaves for the actual execution.Monitor the nodes/slaves (possibly taking them online and offline as required).Recording and presenting the build results.A Master/Server instance of Jenkins can also execute build jobs directly.
Jenkins Slave
Jenkins slave is used to execute the build jobs dispatched by the master. We can configure a project to always run on a particular slave machine, or particular type of slave machine, or simple let the Jenkins to pick the next available slave/node.
As we know Jenkins is developed using Java is platform independent thus Jenkins Master/Servers and Slave/nodes can be configured in any servers including Linux, Windows, and Mac.
The above diagram is self explanatory. It consists of a Jenkins Master which is managing three Jenkins Slaves.
Top Industries that use Jenkins
Top Industries that use Jenkins
Looking at Jenkins customers by industry, we find that Computer Software (27%) and Information Technology and Services (11%) are the largest segments.
Top Countries that use Jenkins
Top Countries that use Jenkins
48% of Jenkins customers are in United States and 8% are in United Kingdom.
Distribution of companies that use Jenkins based on company size (Employees)
Distribution of companies that use Jenkins based on company size (Employees)
Of all the customers that are using Jenkins,35% are small (<50 employees), 45% are medium-sized and 21% are large (>1000 employees).
Distribution of companies that use Jenkins based on company size (Revenue)
Distribution of companies that use Jenkins based on company size (Revenue)
Of all the customers that are using Jenkins, a majority (64%) are small (<$50M), 18% are large (>$1000M) and 9% are medium-sized.
I tried to explain as much as possible. Hope You learned Something from here. Feel free to check out my LinkedIn profile and obviously feel free to comment.
LINKEDIN PROFILE LINK :- https://www.linkedin.com/in/jatin-lodhi-9230571a7/
MEDIUM PROFILE LINK :- https://jatinlodhi.medium.com/
