Automatic Pipeline Flow using GIT, JENKINS, and DOCKER
By: Deepti Tiwari
Tags: Jenkins, Kubernetes, Github, Docker, DevOps

ABOUT

In today’s fast-paced world, automation provides us with the speed and accuracy we need. The greater all industries' access to Automation, the greater our lives become on the whole.

This project is about creating an automatic setup for an organization.

In this project, three aspects are considered which includes

how a developing team works on a central version controlling system

how a webpage is tested by the Quality Assurance Team, and then

how a webpage is deployed finally for the clients.

ACKNOWLEDGEMENT

I would like to express my sincere gratitude to Vimal Daga Sir, who has guided me in this project.

OBJECTIVE

Create a setup in which once the developer will commit the code, it will be pushed automatically to GitHub.

And then Jenkins will pull the codes. Code of MASTER BRANCH will be deployed in the webserver and the code of the DEVELOPER BRANCH will be displayed to the Quality and Assurance Team.

Once QA Team will approve the design in Developer Branch, it will be merged to Master Branch automatically.

WORK PROCESS:-

TOOLS USED

For Automation: JENKINS

For Containerization: DOCKER

For Repository Hosting: GitHub

For Version controlling: Git

________________________

AUTOMATIC PUSH IN GIT

Here, we can see initially both branches are at the same commit level.

Then the developer will clone the repository in his system using the following command.

In the following way, a post-commit file will be created which will automatically push the repository once a developer commits.

The following are the changes made by the developer.

RESULT OF POST COMMIT

In the above picture, as soon as the developer enters the command to commit the changes, it is also pushed and the changes are reflected in GitHub.

JENKINS JOB DESCRIPTION

Points To Remember:

You have already downloaded the GIT plugin in Jenkins.

Make sure to run the following command in RedHat Base OS to start Docker services.

__________________

There are three independent jobs (no job chaining).

__________________

The jobs are explained in detail as follows:

**JOB1**

This job will pull the code files from the MASTER BRANCH and then will launch a container using the httpd docker image for final production.

Link Jenkins with MASTER BRANCH to pull final files.

Poll SCM will keep checking every minute for any updates.

Remote Build is used, as JOB3 has to trigger JOB1.

Bash commands to launch a container for deploying webpage on httpd server for clients.

RESULT OF JOB 1

As we can see, this build successfully launched the “final_display” container which launches the webpage at port number 8084.

The webpage is showing initial commits.

**JOB2**

This job will pull the code files from the DEV BRANCH. Then docker will launch a container using the httpd docker image to a specific port number for the Quality Assurance Team to test the webpage.

Pulling files from DEVELOPER BRANCH.

Poll SCM will keep checking every minute for any updates.

We can also use GitHub hooks to inform Jenkins about any modifications.

Bash commands to launch a container for deploying webpage for QA Team on a different port.

RESULT OF JOB 2

This build successfully launched a “test_env” container which launches the webpage at port number 8085.

Also, there is no change in the previously launched final webpage at port number 8084 (top-right window).

**JOB3**

Once the Quality Assurance Team approves the web page, they will start the job. And this job will then merge the DEVELOPER BRANCH to MASTER BRANCH and will trigger Job1 which will deploy the updated final webpage in httpd webserver.

Link to DEV branch in GitHub.

Specify the “Pre-build actions”, for merging the branches in GitHub as shown in the above image.

There is no need for any build trigger as this job will be built manually by the QA Team.

Bash commands to trigger JOB1 and delete the already deployed final webpage.

RESULT OF JOB 3