Crash Course on Jenkins

Crash Course on Jenkins
Written by anjali

Crash Course on Jenkins

Continuous integration is possible with Jenkins, an open source automation tool created in the Java programming language.

Jenkins creates and tests our software projects, making it simpler for developers to incorporate changes into the project and for consumers to access a new version on a continuous basis.

What is Jenkins?

Continuous integration is possible with Jenkins, an open source automation tool created in the Java programming language.

Jenkins regularly builds and tests our software projects, making it simpler for developers to incorporate changes into the project and simpler for users to get a new build.

By integrating with a wide range of testing and deployment tools, it also enables us to provide our software continually.

Jenkins provides a simple method for automating other common development chores as well as setting up a continuous integration or continuous delivery environment for practically any collection of languages and source code repositories.

Organizations can use Jenkins to automate and accelerate the software development process. Jenkins offers a variety of development lifecycle operations, such as deploy static analysis, build, document, test, and more.

Jenkins uses plugins to achieve CI (Continuous Integration). The various DevOps steps can be integrated via plugins. Installing the utility’s plugins is necessary if you want to incorporate that tool. Maven 2 Project, Git, HTML Publisher, Amazon EC2, etc. are a few examples.

Explanation of Continuous Integration

As part of the continuous integration (CI) development process, developers must periodically submit updated versions of the source code to a shared repository. The repository is then generated for each commit that is made. This enables the development teams to find issues early on.

Regular builds are needed by the developers for continuous integration. The rule of thumb is that a build should start anytime there is a code commit.

How Jenkins works.

1.The code is first committed to the source code repository by a developer. Jenkins scans the repository for changes periodically in the meanwhile.
2.The Jenkins server quickly discovers the modifications made to the source code repository following a commit. Jenkins will make those modifications and begin setting up a fresh build.
3.Jenkins server deploys the built in the test server if the build is successful.
4.Jenkins server creates feedback following testing and then tells the developers of the build and test results.
5.The entire process keeps repeating as it keeps checking the source code repository for modifications made to the source code.

Also Read About:Jenkins

Advantage of Jenkins

1.The utility is open source.
2.It is completely free.
3.It doesn’t need any more installations or parts. implies that it is simple to instal.
4.Simple to configure
5.It supports at least 1000 plugins to make your work easier. If there is no plugin, you can create one and distribute the script to the community.
6.It is portable because it is built in Java.
7.It is independent of platforms. It supports all platforms and many operating systems. like Windows, Linux, or OS X.
8.Since it is extensively used and open source, support is simple.
9.Jenkins can be installed on cloud-based platforms since it supports cloud-based architecture.

Disadvantage of Jenkins

1.In comparison to modern user interface trends, its interface is outdated and not user friendly.
2.It is difficult to maintain because it runs on a server and requires server administration skills to keep track of its usage.
3.CI frequently fails as a result of a few minor setup adjustments. There will be a pause in CI, necessitating some developer team attention.

Architecture of Jenkins

Jenkins manages distributed builds using a Master-Slave architecture. TCP/IP protocol is used in this design for communication between the slave and master.

Jenkins architecture is composed of two parts:

  • Jenkins Master/Server
  • Jenkins Slave/Node/Build Server

Jenkins Master/Server

The Jenkins Master is the primary server for Jenkins. It is a web dashboard that is solely run by a war file. It operates on port 8080 by default. Dashboard allows us to configure jobs and projects, but Nodes and Slave are where the build happens. Jenkins server comes set up and operating with just one node (slave). Using the ssh, jnlp, or webstart protocols, we can add new nodes by providing their IP address, user name, and password.

1.Setting up build jobs.
2.Sending builds to the nodes or slaves so they can be executed.
3.Watch the slaves and nodes (possibly taking them online and offline as required).
4.Recording and displaying the outcomes of the build.

Jenkins Slave/Node/Build Server

The build jobs dispatched by the master are carried out by the Jenkins slave. We can set up a project such that it always uses a specific slave machine, a specific kind of slave machine, or we can just let Jenkins choose the next slave or node that becomes available.

Jenkins Master/Servers and Slave/Nodes can be configured in any servers including Linux, Windows, and Mac as we are aware of Java being platform independent.

Release Type

Based on the requirements of the company, Jenkins enables two types of releases:

1.Long-term maintenance release
2.Weekly release
LTS: Long-term support release Every 12 weeks, long-term support releases (LTS) are made available. They have been tried, tested, and are stable. Basically, end customers are the target audience for this release.

Weekly release: By correcting bugs in the previous version, this release is made available every week. Developers of plugins are the target audience for these releases.

Jenkins Pipeline

Jenkins supports the integration and implementation of continuous delivery pipelines utilising a collection of plugins.

Jenkins Pipeline is a group of tasks or activities that, via the use of automation tools, transfer software from version control into the hands of end users. It is used to the workflow of our software development process to accommodate continuous delivery.

An extensible automation server for a pipeline allows for the creation of basic or even complicated delivery pipelines using DSL and “code” (Domain-specific language).

Continuous Delivery Pipeline?

An automated expression that demonstrates your software acquisition procedure for version control is called a continuous delivery pipeline. As a result, every modification you make to your software must pass through a number of difficult steps before it can be made public. It also entails building the software in a repeatable and dependable manner and advancing it through various testing and deployment stages.


Read More:Crash Course on Springboot


About the author


Leave a Comment