Jenkins - 1

Before going into Jenkins, first of all, let’s see what the deployment process looks like.

Developer pushes the code to the SCM tool such as Github, as soon as a new push is made we use maven build tool to create the package, after creating the package we do static-code analysis using sonarqube, now we push this build artifact to any of the artifactory repositories like jfrog/nexus, after storing the build artifact if its a traditional deployment we would deploy the artifact into the tomcat server, we will store the war/jar in tomcat webapps directory, but in case of containerized deployment then we will create a image for the war and push the image to Container Registries such as DockerHub / ECR / ACR, and from here on K8s will take over. This is the usual flow that we usually follow, but if all these steps are done manually, then it will be a big messup because if a developer pushes 100 changes in a day, then each time we need to,

Checkout the code → Create the package → Do static code analysis → Store the artifact → Create Image → Store the image

We need to do these steps 100 times if a developer pushes 100 times daily, so this is where Jenkins comes into the picture. Using Jenkins, we can automate this entire process, which would save everyone’s time, and also, there are high chances for manual errors in this scenario. Jenkins is a CI CD tool. CI stands for Continuos Integration, and CD stands for Continuos Deployment. Whatever we were doing manually before with the help of Jenkins, we can automate the entire process. Even if there are 200 pushes to the GitHub repository daily, Jenkins takes care of it.

Some of the benefits of CI are :

1. Immediate Bug Detection

2. Deployable System at any given point

3. Record of evolution of the project

We can integrate Jenkins with Version Control Systems like SVN, Github, and Bitbucket. Jenkins can generate the JUnit report as well, such as test cases and code coverage. We have JaCoCo plugin here, which goes with JavaCodeCoverage. We can even stop the deployment if the code coverage is less.

With Jenkins, we can push the builds to various artifact repositories and deploy the build to environments ( build, qa, prod ). Regarding build, we can notify the stakeholders via Slack and email.

Benefits of Jenkins :

1. Jenkins is an open-source tool with good community support.

2. Easy to install and with a good GUI, it makes the job easy.

3. Around 2000+ plugins, good documentation, and community support as well.

4. Not just for the CI we can also use it to schedule jobs for testing. It can also be used by automation engineers like this - if they write selenium test cases and to push to SCM they need to run it at midnight 12 everyday, we can create a job and configure the github SCM repo and rest jenkins will take care.

5. Even if we have DB queries and we need to run these queries in different environments (dev, QA, Prod), we can write a job in Jenkins and automate it. In this way, manual tasks can be automated.

Connecting Github with Jenkins :

To integrate our SCM with Jenkins, we need to have a plugin. After installing the plugin we need to give the Repository URL and give the credentials - username ( email ) and PAT. After this is done now our github repository will be linked with Jenkins, so whenever a commit is made, we can trigger the pipeline. This pipeline will run all the steps that we discussed before. While giving the repository we can also mention the branch. if our code is in the master branch then whenever a commit is made to this master branch, it will trigger the pipeline.

Build Steps :

For the Build process in the manual way we use “mvn clean package” command, but here we need to go to the build step and then Invoke top-level maven targets, but the best way to install maven is to add it as a global tool configuration. If we have 2 jobs and first one needs maven 3.8.2 and the other one needs 3.6.4, then if we go for Invoke top level targets, it would give the option to install one version only, so the recommended way is to add it as a global tool. We can add as many versions as we want. After adding maven, we need to give the command - clean package. no need to give mvn here.

And the build will be downloaded in /var/lib/jenkins/workspace/<war file>

Integrating Sonarqube Stage :

For static code analysis, we use SonarQube. In sonarqube the command is

mvn sonar:sonar, but when we add this stage in the jenkins we just give sonar:sonar.

Nexus Repository Integration :

How we did maven and sonarqube similarly here we integrate the nexus repository using deploy, we can give all these stages as

clean package sonar:sonar deploy

So here we are giving all the stages commands. First, it will execute maven build, which is a clean package, and next, sonarqube - sonar:sonar, and at last, nexus stage - deploy.

All these we need to modify it in the pom.xml and settings.xml in the maven, to push the sonarqube report we need to give the sonar server URL and login username, password. For Nexus, we have to configure the login details in the settings.xml and location in pom.xml,

Deployment to Tomcat Server :

Now, if we are deploying to the Tomcat server, we need to add the war file to the webapps directory. We will not have this in post-build action; only after installing the plugin - “deploy to container” we can see the option under post-build. Here we are moving war present in the /var/lib/jenkins to the tomcat webapps directory. We need to select the version, tomcat - URL, and Credentials.

If tomcat is configured in a new ec2 instance and if it’s running at http://18.12.54.100:8080/, we need to give this URL and the login details in the jenkins. Make sure the user has the permission to deploy the war file to the webapps directory for the user; we need to add the role “manager-script”

So after this, the build will be in the tomcat server, and our application is deployed successfully.

Right now, whatever we have seen is the process of doing it manually. We can automate the build trigger process, we don’t need to come to Jenkins every time and click on the build now option, but rather, whenever a developer pushes code to the github, we can trigger this process.

There are 3 options for this in Jenkins.

Automate the Build Trigger Process :

1. Build Periodically

2. Poll SCM

3. Github Webhook

In Poll SCM whenever there is a new change to the repository it will build automatically because it has got the current commit id, and if a new commit is made to the repo it will know the current commit ID is not same as the new one so it will do the build. Here, we need to give the time. If we give as 60 mins in the cron expression -

Every 60 mins it will check the commit ID, and if it doesn’t match, then it will do the build. In Poll SCM, we have to give what time to check the commit ID and if the commit ID differs, it will do the build

Whereas in Build Periodically, we need to give the time. For example, if we gave it 30 mins, then for every 30 mins, it will run the build process; irrespective of code changes, it will trigger the build.

Github Webhook is the most useful among other options, if a code change is made to the github repository it will only trigger the build. Here, there is no burden on Jenkins, so it doesn’t need to check for the changes in the repository every time. We have to go to the GitHub repository and add a webhook. Along with URL, we need to give a context path,

http://54.12.12.12:8080/github-webhook/. This is the URL, and we have to give it in the repository.

This is how things work in real time; whenever a developer pushes code to the GitHub, it will use the GitHub webhook and trigger the build process. It saves a lot of manual effort and is very useful if our developer is making many changes to the repository in a day.

Discard Old Builds:

Let’s say developer makes 200 changes in a week then we would left with 200 builds and for jenkins to keep all these 200 builds it would bulk up our server, if we don’t need to keep all the builds but rather store last 10 builds only, we can even do that here with Discard old builds option, here we can give 10 as the max# of builds to keep.

Apart from this, we can also add timestamps to the console output, we can delete the workspace before the build starts → Here, it will get only the updated code.