Devops Record

SIR C R REDDY COLLEGE OF ENGINEERING
ELURU
CERTIFICATE
This is to certify that this is the BONAFIDE RECORD of the work

done in CONTINUOUS INTEGRATION AND CONTINUOUS DELIVERY
USING DEVOPS Laboratory by Mr/Mrs
Bearing Regd. No: of III/IV B.E/B.TECH course during
the academic year 2022 - 2023
 Total number of experiments held : 12

 Total number of experiments done :
LAB-IN-CHARGE HEAD OF THE DEPARTMENT
EXTERNAL EXAMINER
DevOps Dept. of CSE
INDEX
S. No. Name of The Experiment Date Page Valued Grade

Get an understanding of the stages in
1
software development lifecycle, the process
models, values and principles of agility and
the need fragile software development.
This will enable you to work in projects
following an agile approach to software
development.
Get a working knowledge of using extreme

2
automation through XP programming
practices of test first development,
refactoring and automating test case
writing.
It is important to comprehend the need to

3
automate the software development
lifecycle stages through DevOps. Gain an
understanding of the capabilities required
to implement DevOps, continuous
integration and continuous delivery
practices.
4 Configure the web application and Version

control using Git using Git commands and
version control operations.
Sir C.R. Reddy College of Engineering Page No: I

DevOps Dept. of CSE
Configure a static code analyzer which will

5
perform static analysis of the web
application code and identify the coding
practices that are not appropriate. Configure
the profiles and dashboard of the static
code analysis tool.
6 Write a build script to build the application
using a build automation tool like Maven.
Create a folder structure that will run the
build script and invoke the various software
development build stages. This script
should invoke the static analysis tool and
unit test cases and deploy the application to
a web application server like Tomcat.
Configure the Jenkins tool with the

7
required paths, path users and pipeline
views.
8 Configure the Jenkins pipeline to call the
build script jobs and configure to run it
whenever there is a change made to an
application in the version control system.
Make a change to the background colour of
the landing page of the web application
and check if the configured pipeline runs.
Sir C.R. Reddy College of Engineering Page No: II

DevOps Dept. of CSE
9
Create a pipeline view of the Jenkins
pipeline used in Exercise 8. Configure it
with user defined messages.
In the configured Jenkins pipeline created in

10
Exercise 8 and 9, implement quality gates
for static analysis of code
In the configured Jenkins pipeline created in

11
Exercise 8 and 9, implement quality gates for
static unit testing.
12 In the configured Jenkins pipeline created in

Exercise 8 and 9, implement quality gates
for code coverage.
Sir C.R. Reddy College of Engineering Page No: III

DevOps Dept. of CSE
Skill Oriented Course- III

Continuous Integration and Continuous
Delivery (CICD) using DevOps
EXERCISE - 1
Reference course name: Software Engineering and Agile Software Development
Get an understanding of the stages in software development lifecycle the process models,
values and principles of agility and the need for agile software development. This will enable
you to work in projects following an agile approach to software development.
Introduction
DevOps is not a new tool or new technology in the market. It is a new philosophy or culture or
process to develop, release and maintenance of software or application or product with higher
quality in very faster way.
Development Group
The people who are involving in

Planning
Coding
Build
Testing are considered as Development Group
Ex:
Business Analyst
System Analysis
Design Architect
Sir C.R. Reddy College of Engineering Page No: 1

DevOps Dept. of CSE
Operations Group
The people who are involving in
Release
Deployment
Operate
Monitoring are considered as Operations Group
Ex:
Release Engineers
Configuration Engineers
System Admin
Fig: DevOps
To understand this new DevOps culture, we have to aware already existing Software
Development Life Cycle (SDLC) Models.
Waterfall Model
Prototype Model
Incremental or Iterative Model

DevOps Dept. of CSE
Waterfall Model
Waterfall refers to the linear or sequential approach of developing software.
Under the Waterfall model, Software Development Life Cycle (SDLC) is divided into
different phases like requirements gathering, analysis, coding, testing, and delivery.
Fig: Water Fall Model
Advantages of Waterfall Methods

 It is very simple and easy to implement.
 Best suitable if requirements are fixed.
Disadvantages of Waterfall Methods

 It is not ideal for the large scale projects.
 It has a very rigid structure and you can’t be moved back and front easily.
Agile Model
It is teamwork-based software development where continuous iteration is possible

and focuses on customer satisfaction. Here both development and testing are done
simultaneously. The development cycle is divided different sprint, which is usually two
weeks.

DevOps Dept. of CSE
Fig: Agile Methodology
Advantages of Agile Methodology

 Client satisfaction is possible as he oversees every stage.
 It assures a better quality of development
Disadvantages of Agile Methodology

 It is a client process focused, thus the client needs to be continuously involved in
theproject.
 Co-location of the team and client is required for efficient communication which is
not always possible.
DevOps
 DevOps is a combination of development (Dev) and operations (Ops) used to shorten

the systems development life cycle and to manage end to end processes which
emphasizing communication, integration, and collaboration.
 It promotes a fully automated CI/CD (Continuous integration & Continuous

deployment) pipeline to enable quick and frequent releases.

DevOps Dept. of CSE
DevOps Vs Agile:
DevOps and Agile both are different models.
Similarities:
 Both are software development methodologies.

 Both models concentrating on rapid software development with team collaboration.
Differences:
⮧ Agile model talks about only development but not operations.

- DevOps model talks about complete product life cycle like development and
operations.
⮧ - In Agile model, separate people are responsible for development, testing,
deployment etc.
⮧ -In agile client is responsible to give the feedback for the sprint.
- But in DevOps, immediate feedback is available from the monitoring tools.

DevOps Dept. of CSE
QUIZ-1
Q1. Which of the following benefits does Agile NOT offer in comparison to Waterfall
approach?
A) Changes are easy to make in Agile method of software development
B) Final product is visible at the end of the project only in Agile method of software
Development.
C) Testing after each iteration ensures that bugs are caught early in Agile method of
Software development.
D) There is lot of focus on documentation in Agile in Agile method of software
development.
B and D
A and B
B, C and D
A, B and D
Q2. In Scrum, I am responsible for the return on investment, goals and the vision of the
project. I am responsible for the product backlog and the release date. Who am I?
Product owner
Scrum master
Dev team member
Project manager

DevOps Dept. of CSE
Q3. The MOST efficient and effective method of conveying information to and within a
development team is .
Face to face conversation
Phone call
email
Weekly Status reporting through presentation(ppt) shared via email
Q4. Which core practice of Kanban helps understand the activities being done and the
various stages that lead to completion?
Visualize the workflow
Manage the workflow
Set WIP
Get early feedback
Q5. Consider the following scenario and choose the statement which you think are
TRUE.
The IT team management at Pura Vida company has decided to adopt DevOps and has drawn
a roadmap for the journey. This information is communicated to all the team members
(developers, testers, architects, operations team, (includes infrastructure, system
administration and deployment). Choose the option(s) which is/are TRUE.
The implementation is the responsibility of the managers who should drive this.
Managers express that the buy-in should be there from the business(customers) and the top
management in Pura Vida.
IT Management team members feel that additional roles will be required (other than Scrum
master, Product owner and Dev team) to execute this

DevOps Dept. of CSE
The development and test teams feel that this is the responsibility of Operations and they
have no role to play here
Q6. Which of the following statement(s) are CORRECT about Continuous Integration
(CI)?
Code needs to be frequently checked in
Code needs to be frequently checked in
CI helps to identify integration defects in the early stages of the project
All the given options
Q7. Tom, a Dev team member, has mentioned in a daily scrum meeting that he is unable
to proceed with his work due to unavailability of a software library. He also stated that
the library is available in another project team within the company. What would be the
most appropriate corrective action in this scenario?
Product Owner should speak to peer project team to make the software library available
Team should use internet and try to download a free version of the software library
Team should use internet and try to download a free version of the software library
Scrum Master should get the issue resolved by speaking to the other project team and
make the software library available
Q8. Which of the following XP practice ensures 100% code coverage, review and
ensures that no extra line of code is written.
Refactoring
Continuous integration
Test driven development

DevOps Dept. of CSE
Following Simple design principles
Q9. Which of the following statements are TRUE with respect to Kanban?
A) Kanban is a PULL based method
B) WIP limit ensures that the team does not commit beyond capacity
C) Kanban is used when Scrum does not work for teams
D) Kanban is based on the philosophy "Stop finishing, start working"
Q10.Identify the activities(build) that can be automated to create a continuous

integration pipeline.
A) Static code analysis
B) Unit testing
C) Code coverage
D) Deployment to production

DevOps Dept. of CSE
EXERCISE-2
Reference Course name:Development & Testing with Agile: ExtremeProgramming.
Get a Working Knowledge of using extreme automation through XP programming

practicesoftest first development, refactoring and automating test case writing.
QUIZ-2
Q1. What are some good use cases for extreme programming?
A) When there are no customer requirements
B) When resilience during change is needed
C) When releases can be iterative
D) When teams need to get away from meetings and “just code”
Q2. What are some of the phases of iteration planning?
A)Exploration
B)Promotion
C)Steering
D)Release
Q3What are some benefits of pair programming?
A) It does not require active participation from all parties
B) It reduces risk
C) It reduces coordination efforts
D) It reduces the time to code

DevOps Dept. of CSE
Question 4
Which pair programming strategy involves one developer creating a test and the other
developer creating code to satisfy the test?
A)Unstructured pairing
B)Driver/navigator pairing
C) Distributed pairing
D)Ping-pong pairing
Question 5
What are some benefits of test-driven development?
Reduces testing to just the key parts of the system
Early bug notification
Increased confidence during refactoring
Automated tests are created by the customer
Question 6
What is the second phase of the test-driven development cycle?
Confirm test fails
Refactor
Confirm test passes
Write the code
Question 7
Which statement best describes the importance of the customer role in XP?
Only the customer knows the budget
Only the customer can set the timeline for releases
Only the customer can approve code

DevOps Dept. of CSE
Only the customer knows what needs to be done and why
Question 8
Which statement best describes the difference between source control and version
control?
A) Source control specifically manages code, while version control applies versioning
B) Version control specifically manages code, while source control includes other types
of files like binaries
C) Version control specifically manages code, while source control applies versioning
D) Source control specifically manages code, while version control includes other types
of files like binaries
Question 9
Which operation is used to merge code from one branch to another?
a. Push
b. Clone
c. Branch
d. Pull
Question 10
Which statement best describes the difference between continuous integration (CI) and
continuous deployment (CD)?
CD manages automated builds and deployments, while CI is a process for customer

feedback
CI manages compilation, testing, and packaging, while CD manages the
distribution
CD manages compilation, testing, and packaging, while CI manages the

DevOps Dept. of CSE
distribution
CI manages automated builds and deployments, while CD is a process for customer
feedback
Question 11
Which operations are used to implement continuous integration in GitHub?
A) Actions
B) Releases
C)Builds
D)Pull requests
Question 12
Which category of coding standards can be left in violation if there are agreed upon
reasons to do so?
A) Recommendation
B) Guideline
C) Optional
D) Mandatory
Question 13
What are some potential negatives to collective code ownership?
Slower learning
Reliance on team expertise
Decreased motivation
Increased costs

DevOps Dept. of CSE
Question 14
What are some benefits of code refactoring?
A) Increases performance
B)Increases maintainability
C)Reduces costs
D)Increases extensibility
Question 15
What are some effective refactoring strategies?
a.Reduce duplication
b.Reduce method l
c. Add logging to detect issue locations
d. Add explanatory comments
Question 16
What is the maximum amount of time recommended between small releases in Agile
software development?
One day
Two weeks
There is no maximum
One week

DevOps Dept. of CSE
Question 17
What are some benefits of system metaphors?
a. Give everyone a shared understanding of the vision
b. Allow everyone to share the same vocabulary
c. Allow for fun “code names” for projects
d. Eliminate issues with political correctness
Question 18
What should be the first step when implementing a 40-hour work week?
A) Collect metrics
B)Experiment
C) Inform the customer of potential delays
D) Offer overtime pay for anyone that works more than 40 hours

DevOps Dept. of CSE
EXERCISE-3
Module name: DEVOPS ADOPTION IN PROJECTS.

It is important to comprehend the need to automate the software development lifecycle
stages through DevOps. Gain an understanding of the capabilities required to implement
DevOps, continuous integration and continuous delivery practices. Solve the questions given
in Quiz1, Quiz2, Quiz 3
DevOps adoption in projects

It is important to comprehend the need to automate the software development
lifecycle stages through DevOps
DevOps lifecycle & Working
 DevOps lifecycle is a series of automated development processes or workflows within

an iterative development lifecycle.
 It follows a continuous approach. hence its lifecycle is symbolized in the form of an
infinity loop.
How the DevOps lifecycle works at every stage

Plan
 In this stage, teams identify the business requirement and collect end-user feedback.

DevOps Dept. of CSE
Code
 The development teams use some tools and plugins like Git to streamline the
development process
Build
 In this stage, once developers finish their task, they commit the code to the shared
code repository using build tools like Maven and Gradle.
Test
 Once the build is ready, it is deployed to the test environment first to perform several
types of testing like user acceptance test, security test, integration testing,
performance testing, etc., using tools like JUnit, Selenium, etc., to ensure software
quality.
Release:
 Once the build passes all tests, the operations team schedules the releases or deploys
multiple releases to production, depending on the organizational needs.
Deploy
 In this stage, Infrastructure-as-Code helps build the production environment and then
releases the build with the help of different tools like ansible, puppet, chef, docker,
kubernetes etc.
Operate
 The release is live now to use by customers.
 The operations team at this stage takes care of server configuring and provisioning
using tools like Chef.

DevOps Dept. of CSE
Monitor
 In this stage, the DevOps pipeline is monitored based on data collected from customer
behavior, application performance, etc.
DevOps lifecycle phases:

The 7Cs of DevOps lifecycle
In DevOps everything is continuous from planning to monitoring.
Continuous Development
🞂 This phase focuses on project planning and coding.
🞂 Project requirements are gathered and discussed with stakeholders.
Tools
🞂 There are no specific tools for planning
🞂 The development team requires some tools like GitLab, GIT, TFS, SVN, Mercurial,
Jira, Bit Bucket, Confluence, and Subversion are a few tools used for version control.
Continuous Integration
🞂 In this phase, updated code or add-on functionalities and features are developed and
integrated into existing code.

DevOps Dept. of CSE
🞂 Bugs are detected and identified in the code during this phase at every step
through unit testing, and then the source code is modified accordingly.
Tools:
🞂 Jenkin, Bamboo, GitLab CI, Buddy, TeamCity, Travis, and Circle CI are a few
DevOps tools used to make the project workflow smooth and more productive.
Continuous Testing
🞂 Quality analysts continuously test the software for bugs and issues during this stage
using Docker containers.
🞂 In case of a bug or an error, the code is sent back to the integration phase for
modification.
Tools
🞂 JUnit, Selenium, TestNG, and TestSigma are a few DevOps tools for continuous
testing.
🞂 Selenium is the most popular open-source automation testing tool that supports
multiple platforms and browsers.
Continuous deployment
🞂 The final code is deployed on production servers.

DevOps Dept. of CSE
QUIZ-3
Part A
Q1 of 4
Choose the aspects considered by Infosys for DevOps adoption
a) People
b) Process
c) Technology
1) a, b and c
2)only a
3)only b
4)b and c only
Q2 of 4
Choose the business drivers for adoption of DevOps (multiple response question)
A) Early time to market

B) Quick deployments with good quality
C)Maintenance of Service levels
D)Adoption of Agility
Q3 of 4
Match the scenarios with the feature/capability that can be applied.

DevOps Dept. of CSE
Capability:
a. Feature toggle
b. Micro services
c. Big room planning
d. Service virtualization
e. Infrastructure as code
Scenarios
A bank is introducing the online fixed deposit scheme. If this feature has to be deployed
in production, the accounts service module which provides the customer account details
online would need to be used and also updated. The updating would disrupt the account
service module. This cannot be afforded by the bank. However, the new feature needs to be
tested
An online audio and video steaming company receives a million calls every day from
different types of devices for different services. They need an architectural style which
consists of lightweight components
A support team receives a ticket from the customer that a specific server is not
reachable. The support staff try out quick fixes, but is not working and the server crashes. It
needs to now be reconfigured. The support staff face this situation very often and are wasting
a lot of time doing reconfiguration manually all the time
Team A has completed working on a feature. However, they are waiting for some
related features from B and C so that deployment can be done together. Customer is keen on
having feature A urgently
A software services company brings all its stakeholders right from developers to
supportteams together for effective execution of projects
A) a3, b2, c1, d4, e5

B) a4, b2, c5, d1, e3
C)a4, b5, c2, d1, e3

DevOps Dept. of CSE
D)a3, b2, c1, d4, e5
Q4 of 4
Match the stakeholder and what capabilities they need to build while embarking on the
DevOps implementation journey.
a. Business
b. Dev Team
c. Testing Team
d. Infra team
e. Ops team
f. Organization
1. Continuous integration
2. Automated environment management
3.Progressive test automation

4.Policies to support merging of Dev and Ops teams
5.Big room planning
A) a2, b1, c5, d4, e2

B) a3, b2, c4, d5, e1
C) a5, b1, c3, d2, e4
D) a1, b3, c4, d5, e2

DevOps Dept. of CSE
Part-B
Q1 of 4
The customer insists a Dev team to use Jenkins and construct an automated continuous
integration pipeline. The team accepts this request and constructs a CI pipeline orchestrated
by Jenkins. They schedule daily integration. After a month of implementation, the customer
finds that the bugs that are released to production are increasing. When they inspect the
pipeline stages they find the following stages-
Version control -> build automation -> baseline in artifact repository
What is the team missing here?
A) The automated pipeline should have in-built quality with static code analysis included
with a good number of quality rules and gating conditions for quality
B) Unit tests should be automated and included so that they can be repeatedly invoked
C) Team should have constructed the pipeline with a proprietary orchestration tool
D) The integration frequency should be reduced further to an hourly integration
E) The integration frequency should be increased to weekly integration

DevOps Dept. of CSE
Q2 of 4
A development team which is implementing CI using an orchestration tool are doing the
following activities. Choose the ones which may not be good practices.
A) If the QA tests fail, the developers make the changes in the server where the QA tests run,
compile and run the tests again
B) The team auto-trigger the CI pipeline whenever a team member completes the work and
push code to the central version control repository
C) If the CI pipeline is broken, the teams continue with the features they planned during that
day instead of fixing the pipeline as it might take a long time to do it
D) The development team run the code quality tests and unit tests locally before pushing
them to the central CI pipeline
Q3 of 4
Choose the statement(s) that are TRUE with respect to choosing tool stack for
automating the CICD pipeline
1)Based on appetite of customer for automation of tasks
2)Based on budget availability
3)Based on domain and project requirements
4)After consultation with a tool expert/coach
5)Based on popular tools available in the market
6)Based on free tools available in the market

DevOps Dept. of CSE
Q4 of 4
Choose the statement(s) that are TRUE with respect to choosing tool stack for
automating the CICD pipeline.
A) All open source tools are free of cost
B) Open source tools need to be OSS compliant
C) Tooling and infrastructure budget for automation should be upfront communicated to

customers
D) Binary repository tool is not required and is optional in a CI pipeline

DevOps Dept. of CSE
EXERCISE-4
Module name: Implementation of CICD with Java and open-source stack.
Configure the web application and Version control using Git using Git commands and
version control operations.
Need of Version Control System
🞂 Overwriting of the code should not be happened.
🞂 Maintaining multiple versions manually is very complex activity.
🞂 Every change should be tracked
- who did the change
- when he did the change
- which changes he did etc.
VCS improves the following factors:

🞂 Collaboration
🞂 Storing Versions
Version Control System
🞂 Version control system is used to maintain the changes made to an artifact over time.
🞂 Artifacts can be documents, code files or any kind of executable.
Working of Version Control System

🞂 Version Control System always talks about files which contain source code.
- Tester related to  test script
- Architect related to  Documents
- Project manager related to  MS Excel Sheets

DevOps Dept. of CSE
Basic Version Control System Terminology:
Working Directory
🞂 Where developers are required to create/modify files.
🞂 Here version control system is not applicable. Here we won’t use the work like
version-1,version-2 etc.
Repository:
🞂 Where we have to store files and metadata.
🞂 Here Version Control System is applicable.
Commit
The process of sending files from working directory to the repository.
Checkout
The process of sending files from repository to working directory.
Benefits of Version Control System

🞂 We can different versions and we can choose any version based on client requirement.
🞂 With every version/commit we can maintain metadata like - commit message, who
did changes, when he did change, what changes he did etc.
Types of Version Control System

🞂 Centralized Version Control Systems (CVCS)
🞂 Distributed or Decentralized Version Control Systems (DVCS)
Centralized Version Control System (CVCS)

🞂 In CVCS, the central server stores all the data.
🞂 This central server enables team collaboration.

DevOps Dept. of CSE
Benefits of CVCS
🞂 Easy to learn and manage
🞂 More control over users and their access.
Examples:
🞂 CVS
🞂 SVN
🞂 TFS etc.
Drawbacks of CVCS
🞂 It is not locally available, which means we must connect to the network to perform
operations.
🞂 During the operations, if the central server gets crashed, there is a high chance of
losing the data.
Distributed Version Control System (DVCS)
🞂 In DVCS, there is no need to store the entire data on our local repository.
🞂 The User needs to update for the changes to be reflected in the local repository.

DevOps Dept. of CSE
Benefits of DVCS
🞂 Except for pushing and pulling the code, the user can work offline in DVCS
🞂 DVCS is fast compared to CVCS because you don't have to contact the central server
for every command
🞂 Merging and branching the changes in DVCS is very easy
GIT
Introduction
🞂 Git is a DevOps tool used for source code management.
🞂 It is a free and open-source version control system used to handle small to very large
projects efficiently.
Before Git
🞂 Developers used to submit their codes to the central server without having copies of
their own.
🞂 There was no communication between any of the developers.
After Git
🞂 Every developer has an entire copy of the code on their local systems.
🞂 Any changes made to the source code can be tracked by others.
🞂 There is regular communication between the developers.

DevOps Dept. of CSE
Download & Installation of GIT in windows OS
🞂 Visit the following link

https://git-scm.com/download/win
🞂 Click here to download the latest (2.37.2) 64-bit/32-bit version of Git for Windows.
🞂 Save the downloaded software in any drive
🞂 Double click that software and install.
Basic Git Commands
🞂 config
🞂 init Git clone command
🞂 add
🞂 commit
🞂 status
🞂 push
🞂 pull
🞂 branch
🞂 merge
🞂 log
🞂 remote
Git config command
🞂 This command configures the user.

DevOps Dept. of CSE
🞂 The Git config command is the first and necessary command used on the Git
command line.
🞂 This command sets the author’s name and email address to be used with your
commits.
Syntax
$ git config --global user.name “Abcde"
$ git config --global user. Email “[email protected]"
Git Init command

🞂 This command is used to create a local repository.
🞂 The init command will initialize an empty repository.
Syntax: $ git init Demo
Git add command

🞂 This command is used to add one or more files to staging (Index) area.
Syntax
🞂 To add one file
$ git add Filename
🞂 To add more than one file
$ git add* (or) $ git add.
Git commit command

Git Commit command is used in two scenarios. They are as follows.
Git commit –m
This command changes the head. It records or snapshots the file permanently in the
version history with a message.
Syntax
$ git commit -m " Commit Message"

DevOps Dept. of CSE
Git commit –a
This command commits any files added in the repository with git add and also
commits any files you've changed since then.
Syntax
$ git commit -a
Git status command
🞂 It is used to display the state of the working directory and the staging area.
🞂 It allows you to see
- which changes have been staged,
- which haven't, and
- which files aren’t being tracked by Git.
Syntax
$ git status
Git push Command
🞂 It is used to upload local repository content to a remote repository.

🞂 Remote branches are configured by using the git remote command.
Git push origin master
Syntax
$ git push [variable name] master
Git pull command
🞂 Pull command is used to receive data from GitHub.
Syntax
$ git pull URL

DevOps Dept. of CSE
Git Branch Command

This command lists all the branches available in the repository.
Syntax
$ git branch
Git Merge Command
This command is used to merge the specified branches history into the current branch.
Syntax
$ git merge Branch name
Git log Command

This command is used to check the commit history.
Syntax
$ git log
Git clone command
🞂 This command is used to make a copy of a repository from an existing URL.
Syntax
$ git clone URL
Git remote Command

🞂 It is used to connect your local repository to the remote server.
Syntax
$ git remote add origin URL
Ex:

DevOps Dept. of CSE
$ git remote add origin https://github.com/DevOps/Project1
Git checkout command
This command is used to switch from one branch to another.
Syntax:
git checkout [branch name]
This command creates a new branch and also switches to it.
Syntax:
git checkout –b [branch name]

DevOps Dept. of CSE
EXERCISE-5
Module Name: Implementation of CICD with Java and open-source stack
Configure a static code analyzer which will perform static analysis of the web application
code and identify the coding practices that are not appropriate. Configure the profiles and
dashboard of the static code analysis tool.
Analysis of source code for quality

What is static and dynamic code analysis?
Analyzing the code without executing it is known as static code analysis. If it is

executed andanalyzed for performance is called dynamic code analysis. This helps detects
issues like coding standard violation, design principles violation, redundant code which are
referred as Technical Debt. If such technical debt is not repaid then it can accumulate,
making it harder to make changes in the code at later time.
Technical debt
● Is a metaphor developed by Ward Cunningham (similar to financial debt)
● Is incurred by doing development quick and dirty
● Would need extra effort to fix the “dirty” parts in future (similar to interest payments)
● Team can choose to continue putting in extra effort due to the dirty pieces or refactor
the code for better design and clean code
SonarQube features
SonarQube is a web based open-source tool to manage code quality.

It has the following features
Can check the source code for –
● standard architecture and design principles
o comments
o coding rules

DevOps Dept. of CSE
o code complexity
o duplication in code
● Covers many languages like Java, C,C++
● Has rules, thresholds and alerts can be configured online
Working of SonarQube
1. SonarQube has a list of built-in rules for different languages
2. There are three ways to execute SonarQube
o Sonar runner (command line)
o Build script
o Sonar Lint (plugin to Eclipse)
3. When these profiles are applied to a project, analysis is performed and a dashboard is
created
4. The dashboard provides the following details:
o Code demographics – no. of lines of code, files etc
o Bugs in code
o Code smells
5. Quality gates can be applied to ensure that code that does not pass the quality
conditions do not move forward to the next stage.
Calculation of technical debt:

Technical debt = Total rework effort in minutes / Total original effort
Let us understand the formula.
Total rework effort in minutes:

● Each rule is associated with rework effort. If the rule is violated it adds to the rework
effort.
Total original effort:

DevOps Dept. of CSE
● The original number of lines of code is multiplied with original effort. Sonar considers
the original effort as 30 minutes for each line of code to flow through the entire SDLC
The equation provides a percentage which is graded from A to E as a SQALE rating. D

and E indicate that code quality is very bad. A and B indicates good quality and C indicates
deterioration of code. SQALE is a methodology that was developed by in spear it and then
open sourced. Yes, the SonarQube implementation of SQALE is based solely on rules and
issues.
Practical tips
● Create profiles with increasing number of rules so that teams are not overwhelmed with
too many rules in the beginning
● A mix of tools can be used to check quality
The development team at "Pura Vida" will have their challenges mitigated with SonarQube for
the following reasons:
● Code quality will be ensured from design and clean coding perspectives which will go a
long way in ensuring that code is maintainable and able to adapt to changes quickly
● This will go a long way in ensuring code quality with speed

DevOps Dept. of CSE
EXERCISE-6
Module Name: Implementation of CICD with Java and open-source stack

Write a build script to build the application using a build automation tool like Maven.
Create a folder structure that will run the build script and invoke the various software
development build stages. This script should invoke the static analysis tool and unit test cases
and deploy the application to a web application server like Tomcat.
Maven tool:
Maven is a popular open-source build tool developed by the Apache Group to build,
publish, and deploy several projects at once for better project management.
USE OF MAVEN TOOL:

Maven is chiefly used for Java-based projects, helping to download Dependencies,
which refers to the libraries or JAR files. ds
Maven Commands
1. maven clean
This command cleans the maven project by deleting the target directory. The command
output relevant messages are shown below.
$ mvn clean
...
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ maven-example-jar ---
[INFO] Deleting /Users/pankaj/Desktop/maven-examples/maven-example-jar/target
...
2. maven compiler:compile
This command compiles the java source classes of the maven project.

DevOps Dept. of CSE
$ mvncompiler:compile
...
[INFO] --- maven-compiler-plugin:3.8.1:compile (default-cli) @ maven-example-jar -

--
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 1 source file to /Users/pankaj/Desktop/maven-examples/maven-

example-jar/target/classes
...
3. maven compiler:testCompile
This command compiles the test classes of the maven project.
$ mvncompiler:testCompile
...
[INFO] --- maven-compiler-plugin:3.8.1:testCompile (default-cli) @ maven-example-

jar ---

example-jar/target/test-classes
...
4. maven package
This command builds the maven project and packages them into a JAR, WAR, etc.
$ mvn package

DevOps Dept. of CSE
...
[INFO] --- maven-compiler-plugin:3.8.1:compile (default-compile) @ maven-

example-jar ---

example-jar/target/classes
...
[INFO] --- maven-compiler-plugin:3.8.1:testCompile (default-testCompile) @ maven-

example-jar ---

example-jar/target/test-classes
[INFO]
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ maven-example-jar ---
[INFO] Surefire report directory: /Users/pankaj/Desktop/maven-examples/maven-

example-jar/target/surefire-reports
TESTS
Running com.journaldev.maven.classes.AppTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec
Results :
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
[INFO]

DevOps Dept. of CSE
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ maven-example-jar ---
[INFO] Building jar: /Users/pankaj/Desktop/maven-examples/maven-example-

jar/target/maven-example-jar-0.0.1-SNAPSHOT.jar
[INFO] -
[INFO] BUILD SUCCESS

...
The output shows the location of the JAR file just before the “BUILD SUCCESS” message.
Notice the package goal executes compile, testCompile, and test goals before packaging the
build.
5. maven install
This command builds the maven project and installs the project files (JAR, WAR, pom.xml,
etc) to the local repository.
$ mvn install
...
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ maven-

example-jar ---
...
[INFO] --- maven-compiler-plugin:3.8.1:compile (default-compile) @ maven-

example-jar ---
...
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @

maven-example-jar ---
...
[INFO] --- maven-compiler-plugin:3.8.1:testCompile (default-testCompile) @ maven-

example-jar ---
...

DevOps Dept. of CSE
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ maven-example-jar ---
...
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ maven-example-jar ---
...
[INFO] --- maven-install-plugin:2.4:install (default-install) @ maven-example-jar ---
[INFO] Installing /Users/pankaj/Desktop/maven-examples/maven-example-

jar/target/maven-example-jar-0.0.1-SNAPSHOT.jar to
/Users/pankaj/.m2/repository/com/journaldev/maven/maven-example-jar/0.0.1-
SNAPSHOT/maven-example-jar-0.0.1-SNAPSHOT.jar
[INFO] Installing /Users/pankaj/Desktop/maven-examples/maven-example-

jar/pom.xml to /Users/pankaj/.m2/repository/com/journaldev/maven/maven-example-
jar/0.0.1-SNAPSHOT/maven-example-jar-0.0.1-SNAPSHOT.pom
...
6. maven deploy
This command is used to deploy the artifact to the remote repository. The remote repository
should be configured properly in the project pom.xml file distributionManagement tag
7. maven validate
This command validates the maven project that everything is correct and all the necessary
information is available.
8. maven Dependency: tree

This command generates the dependency tree of the maven project.
$ mvndependency:tree
...
[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ Mockito-Examples ---
[INFO] com.journaldev.mockito:Mockito-Examples:jar:1.0-SNAPSHOT
[INFO] +- org.junit.platform:junit-platform-runner:jar:1.2.0:test

DevOps Dept. of CSE
[INFO] | +- org.apiguardian:apiguardian-api:jar:1.0.0:test
[INFO] | +- org.junit.platform:junit-platform-launcher:jar:1.2.0:test
[INFO] | \- org.junit.platform:junit-platform-suite-api:jar:1.2.0:test
[INFO] | \- org.junit.platform:junit-platform-commons:jar:1.2.0:test
[INFO] +- org.junit.jupiter:junit-jupiter-engine:jar:5.2.0:test
[INFO] | +- org.junit.platform:junit-platform-engine:jar:1.2.0:test
[INFO] | | \- org.opentest4j:opentest4j:jar:1.1.0:test
[INFO] | \- org.junit.jupiter:junit-jupiter-api:jar:5.2.0:test
[INFO] +- org.mockito:mockito-junit-jupiter:jar:2.19.0:test
[INFO] | \- org.mockito:mockito-core:jar:2.19.0:test
[INFO] | +- net.bytebuddy:byte-buddy:jar:1.8.10:test
[INFO] | +- net.bytebuddy:byte-buddy-agent:jar:1.8.10:test
[INFO] | \- org.objenesis:objenesis:jar:2.6:test
[INFO] \- org.testng:testng:jar:6.14.3:test
[INFO] +- com.beust:jcommander:jar:1.72:test
[INFO]
mvndepen\- org.apache-extras.beanshell:bsh:jar:2.0b6:test
9. maven dependency:analyze
This command analyses the maven project to identify the unused declared and used
undeclared dependencies. It’s useful in reducing the build size by identifying the unused
dependencies and then remove it from the pom.xml file.
$ mvndependency:analyze
...

DevOps Dept. of CSE
[INFO] --- maven-dependency-plugin:2.8:analyze (default-cli) @ Mockito-Examples -

--
[WARNING] Used undeclared dependencies found:
[WARNING] org.junit.jupiter:junit-jupiter-api:jar:5.2.0:test
[WARNING] org.mockito:mockito-core:jar:2.19.0:test
[WARNING] Unused declared dependencies found:
[WARNING] org.junit.platform:junit-platform-runner:jar:1.2.0:test
[WARNING] org.junit.jupiter:junit-jupiter-engine:jar:5.2.0:test
[WARNING] org.mockito:mockito-junit-jupiter:jar:2.19.0:test
...
$
10. mvnarchetype:generate
Maven archetypes is a maven project templating toolkit. We can use this command to
generate a skeleton maven project of different types, such as JAR, web application, maven
site, etc. Recommended Reading: Creating a Java Project using Maven Archetypes
11. mvnsite:site
This command generates a site for the project. You will notice a “site” directory in the target
after executing this command. There will be multiple HTML files inside the site directory
that provides information related to the project.

DevOps Dept. of CSE
EXERCISE-7
Module Name: Implementation of CICD with Java and open-source stack.

Configure the Jenkins tool with the required paths, path variables, users and pipeline views.
What is Jenkins?
Jenkins is an opensource 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 workflow
1. A build script containing the various targets for executing the build cycle activities is
available (pl. refer earlier section on build automation)
2. These targets are used by Jenkins for orchestration
3. Jenkins is configured -
4. Paths to the executables of tools are provided
o Users are created with permissions
o Environmental variables are set (ex. Java_ HOME, MVN_ Home)
o Plugins for the required tools are uploaded
o Email configurations are done
5. The frequency interval for integration (i.e. start of orchestration) is configured
6. The repository from which the code and test cases are to be pulled is configured
7. The jobs (upstream and downstream) (invoker and invoked respectively) are configured
as per the build lifecycle
8. Gating conditions are configured
9. Mailer configuration (to list, mail body and when) is done so that notifications can be
made (ex. when build is broken)

DevOps Dept. of CSE
10. A pipeline view is created to see the status of the builds

11. Reports of unit testing and coverage are configured to view on Jenkins dashboard itself
History of Jenkins
Kosuke 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.
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.
o Developer teams have to wait till the complete software is developed for the test
results.
o 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.
o It slows the software delivery process.
o 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.
o The whole process was manual which increases the threat of frequent failure.

DevOps Dept. of CSE
Advantages and Disadvantages of using Jenkins
Advantages of Jenkins
o It is an opensource tool.
o It is free of cost.
o It does not require additional installations or components. Means it is easy to install.
o Easily configurable.
o It supports 1000 or more plugins to ease your work. If a plugin does not exist, you can
write the script for it and share with community.
Disadvantages of Jenkins
o Its interface is out dated and not user friendly compared to current user interface
trends.
o Not easy to maintain it because it runs on a server and requires some skills as server
administrator to monitor its activity.
o CI regularly breaks due to some small setting changes. CI will be paused and
therefore requires some developer's team attention.

DevOps Dept. of CSE
Installing Jenkins on Windows
Hardware Requirements
Memory 2 GB RAM (Recommended)
Disk Space We need at least 1 GB of space in our hard drive for Jenkins
Software Requirements
JDK We need either Java Development (JDK) or Java Runtime Environment (JRE)
Operating Jenkins can be installed on Windows, Mac OS X, Ubuntu/Debian, Red

System Hat/Fedora/CentOS, openSUSE, FreeBSD, OpenBSD, Gentoo.
Java The WAR (Web Application Resource) file can be run in any container that
Container supports Servlet 2.4/JSP 2.0 or later. (For example Tomcat 5).
Install Java Version 8
Since Jenkins is a Java based application, therefore Java is a must.
To download the Java Click here. Select file according to your platform.

DevOps Dept. of CSE
Then install the Java as follows:

DevOps Dept. of CSE

DevOps Dept. of CSE

DevOps Dept. of CSE
Download Jenkins war File
This war is required to install Jenkins.
The official website for Jenkins is https://jenkins.io/
When you click the given link, you will get the home page of the Jenkins official website as
given below:

DevOps Dept. of CSE
Starting Jenkins
Open the command prompt and go to the directory where the Jenkins. war file is located. And
then run the following command:
C:/Java -jar Jenkins.war
When you run this command, various tasks will run, one of which is the extraction of the war
file which is done by an embedded webserver called winstone.
When you run this command, various tasks will run, one of which is the extraction of the war
file which is done by an embedded webserver called winstone.

DevOps Dept. of CSE
Click on Allow access button to allow the access.

DevOps Dept. of CSE
Accessing Jenkins
Now you can access the Jenkins. Open your browser and type the following url on your
browser:
1. http://localhost:8080
This URL will bring up the Jenkins dashboard.

DevOps Dept. of CSE
EXERCISE-8

Configure the Jenkins pipeline to call the build script jobs and configure to run it whenever
there is a change made to an application in the version control system. Make a change to the
background colour of the landing page of the web application and check if the configured
pipeline runs.
1. Configuring Jenkins
Although we have configured Jenkins to communicate with our repository on GitHub, we

still have to manually start the build from Jenkins. To automatically run builds, Jenkins
listens for POST requests at a Hook URL. We need to give this URL to the repository on
GitHub. Then, whenever code is pushed to that repository, GitHub will send a POST request
to the Hook URL and Jenkins will run the build.
To get the Hook URL of Jenkins, Open the Jenkins Dashboard.
Go to: Manage Jenkins > Configure System
Under GitHub Plugin Configuration, Click on ‘Advanced…’
Check ‘Specify another hook url for GitHub configuration’
A textbox will appear with a hook URL. This is the Hook URL at which Jenkins will listen
for POST requests. Copy this URL and go to the next step.

DevOps Dept. of CSE
2. Configuring GitHub Repository
We now have to provide the Hook URL we got from Jenkins in the previous step.
Open your repository on GitHub.
Click ‘Settings’ on the navigation bar on the right-hand side of the screen.
Click ‘Webhooks & services’ on the navigation bar on the left-hand side of the screen.
Paste the URL you copied in the previous step as the ‘Payload URL’.
You can select the events for which you want the Jenkins build to be triggered. We will select
‘Just the push event’ because we want to run the build when we push our code to the
repository.

DevOps Dept. of CSE
Alternatively, you can click on ‘Let me select individual events’ to get a list of all the events
that you can select to trigger your Jenkins build.
Click ‘Add webhook’ to add the webhook.
You should now see the webhook you just added in the list of Webhooks for that repository
like this.
3. Configuring Jenkins Project
We now have Jenkins configured to run builds automatically when code is pushed to central
repositories. However, Jenkins doesn’t run all builds for all projects. To specify which project
builds, need to run, we have to modify the project configuration.
In Jenkins, go to the project configuration of the project for which you want to run an
automated build.
In the ‘Build Triggers’ section, select ‘Build when a change is pushed to GitHub’.

DevOps Dept. of CSE
Save your project.
Jenkins will now run the build when you push your code to the GitHub repository.
Code to run in GitHub:
<template>
<div>
<b-row class="header-row">
<b-col co1s="6"><h1>logo</h1><lb-co1>
<b-col co1s="6" class="controls">
<b-btn class="login-btn"variant="primary">login</b-btn>
<b-btn class="signup-btn" varient="primary">signup</bn-btn>
<b-col>
</brow></div>
</twmplate>
<br/><b-container>
<b-carouse1
id="carouse-1"
v-model="slide"

DevOps Dept. of CSE
interval="4000"
controls
indicators
background="#ababab"
img-width="1024"
img-height="480"
style="text-shadow:1px 1px 2px#333;"
@sliding-start="one slide start"
@sliding-end="one slide end'>

<b-carouses-slide
caption="first slide"
text="null a vitae elit libero,apharetra argue molllsinterdum"
img-src="https://picsum.photos/1024/4801?image=52">
</b-carousel-slide>

<b-carousel-slide img-ssrc="https://picsum,photos/1024/4801image=54"
<h1>hello world1</h1>
<b-carouse-slide>
<1-slides with image only-->
<b-carousre-slide imh-scr="https://picsum,photos/1024/480/image=58"


<b-carousel-slide>

DevOps Dept. of CSE
<img
slot="img"
class="d-b;ockimg-fluid w-100"
width="1024"
height="480"
src="https://picsum.photos/1024/48-/?img=55"
alt="image slot">
</b-carousel-slides>

<b-carousel-slide caption="blank image" image-blank image-alt="blank image">
<p>
lorem ipsum dolor sit amet,consectetur a disiscingelitsuspendisse eros feil,rincidunt a

tincidunteget,connvallisvelset.utpellentesqueutpellentesqueutlacusvelinterdum
</p>
</b=carousel-slide>
</b-carousel>
<br/>
<b-row>
<b-col>
<b-card
titel="card title"
img-src="https://picsum.photos/680/300/?image=35"
img-art="image"
img-top
tag="article"

DevOps Dept. of CSE
style="max-width:20 rem;"
class="mb-2">
<b-card-text>
some quick example text to build on the card title and make up the bulk of card's content
</b-card-text>
<b-button href="#"variant="primary">go some where</b-button>
</b-card>
</b-col>
<b-card
title="card title"
img-src="https://picsum.photos/680/300/?image=25"
img-alt="image"
img-top
tag="article"
class="mb-2">
<b-card-text>
some quick example text to biuld on the card title and make up the bulk of card's content
</b-cardd-text>
<b-button href="#"variant="primary">go somewhwrwe</b-button>
</b-card>
</b-col>
<b-col>
<b-card

DevOps Dept. of CSE
title="card title"
img-src="https:://pucsum,phots/600/300/?image=25"
img-alt="image"
img-top
tag="article"
class="mb-2">
<b-card-text>
some quick example text to build on the card title and make up the bulk of card's content
</b-card-text>
<b-button href="#" variant="primary">gp somewhere</b-button>
</b-card>
</b-col>

DevOps Dept. of CSE
EXERCISE-9
Create a pipeline view of the Jenkins pipeline used in Exercise 8. Configure it with user
defined messages
Building CI CD Pipeline Using Jenkins and dockers
Step 1: In your Terminal or CLI, Start and enable Jenkins and docker
systemctl start Jenkins

systemctl enable Jenkins
systemctlstart docker
Step 2: In your Jenkins console click on New Item from where you will create your first job.
Step 3: After you click on New Item, You need to choose an option freestyle project with
name and save
Step 4: In the configuration section select SCM and you will add the git repo link and save it.

DevOps Dept. of CSE
Step 5: Then you will select Build option and choose to Execute shell
Step 6: Provide the shell commands. Here it’ll build the archive file to induce a war file. After
that, it’ll get the code that already forces then it uses wiz to put in the package. So, it merely
installs the dependencies and compiles the applying.
Step 7: Similarly, you will create a new job as before.
Step 8: Click on the. freestyle project and save it with the proper name.
Step 9: Again, repeat step 4, In the configuration section select SCM and you will add the Git
repo link and save it.

DevOps Dept. of CSE
Step 10: Repeat step 5, You will select Build option and choose to Execute shell
Step 11: You will now write the shell module commands as for int phase and build the
container.

DevOps Dept. of CSE
Step 12: Again, you will create a new job as before in previous steps.
Step 13: Select freestyle project and provide the item name (here I have given Job3) and click
on OK.

DevOps Dept. of CSE
Step 14: Again, repeat step 4, In the configuration section select SCM and you will add
the Git repo link and save it.
Step 15: Repeat step 10, You will select Build option and choose to Execute shell.

DevOps Dept. of CSE
Step 16: Write the shell commands, now it will verify the container files and the deployment
will be doe on port 8180, save it
Step 17: Now, you will choose job 1 and click to configure.

DevOps Dept. of CSE
Step 18: From the build actions, you will choose post-build and click on build other projects
Step 19: You will need to provide the name of the project to build after the job 1 and then
click save

DevOps Dept. of CSE
Step 20: Now, you will choose job 2 and click to configure.

DevOps Dept. of CSE
Step 21: From the build actions, you will choose post-build and click on build other projects
Step 22: You will need to provide the name of the project to build after the job 2 and then
click save

DevOps Dept. of CSE
Step 23: let's create a pipeline, by adding to + sign
Step 24: Now, you will choose and select a build Pipeline view and add the name.

DevOps Dept. of CSE
Step 25: Choose the Job 1 and save OK
Step 26: let's RUN it and start the CICD process now

DevOps Dept. of CSE
Step 27: After you build the job, to verify open the link in your browser cal host: 8180/sample.
text, This is the port where your app is running

DevOps Dept. of CSE
EXERCISE-10
In the configured Jenkins pipeline created in Exercise 8 and 9, implement quality

gates forstatic analysis of code.
smells, bugs, vulnerabilities, and poor test coverage. Rather than manually analyzing
the reports, why not automate the process by integrating SonarQube with your Jenkins
continuous integration pipeline? This way, you can configure a quality gate based on your
own requirements, ensuring bad code always fails the build. SonarQube is an excellent tool
for measuring code quality, using static analysis to find code
You’ll learn exactly how to do that in this article, through a full worked example
where weadd SonarQube analysis and SonarQube quality gate stages to a Jenkins pipeline.

DevOps Dept. of CSE
SonarQube refresher
SonarQube works by running a local process to scan your project, called the SonarQube
scanner. This sends reports to a central server, known as the SonarQube server.
The SonarQube server also has a UI where you can browse these reports. They look like
this:
Quality gates
In SonarQube a quality gate is a set of conditions that must be met in order for a project
to be marked as passed. In the above example the project met all the conditions.
Here’s an example where things didn’t go so well.
Clicking on the project name gives full details of the failure.
Here you can see here that a condition failed because the maintainability rating was
a D rather than A.

DevOps Dept. of CSE
SonarQube and Jenkins
Running a SonarQube scan from a build on your local workstation is fine, but a robust
solution needs to include SonarQube as part of the continuous integration process. If you
add SonarQube analysis into a Jenkins pipeline, you can ensure that if the quality gate fails
then the pipeline won’t continue to further stages such as publish or release. After all, nobody
wants to release crappy code into production.
To do this, we can use the SonarQube Scanner plugin for Jenkins. It includes two features
that we’re going to make use of today:
1. SonarQube server configuration – the plugin lets you set your SonarQube server
location and credentials. This information is then used in a SonarQube analysis
pipeline stage to send code analysis reports to that SonarQube server.
2. SonarQube Quality Gate webhook – when a code analysis report is submitted to
SonarQube, unfortunately it doesn’t respond synchronously with the result of whether
the report passed the quality gate or not. To do this, a webhook call must be
configured in SonarQube to call back into Jenkins to allow our pipeline to continue (or
fail). The SonarQube Scanner Jenkins plugin makes this webhook available.

DevOps Dept. of CSE
Here’s a full breakdown of the interaction between Jenkins and SonarQube:
1. a Jenkins pipeline is started
2. the SonarQube scanner is run against a code project, and the analysis report is sent to
SonarQube server
3. SonarQube finishes analysis and checking the project meets the configured Quality
Gate
4. SonarQube sends a pass or failure result back to the Jenkins webhook exposed by the
plugin
5. the Jenkins pipeline will continue if the analysis result is a pass or optionally
otherwise fail

DevOps Dept. of CSE
Full worked example

Let’s get our hands dirty with a worked example. We’ll run through all the steps in the UI
manually as this is the best way to understand the setup.
In this example we’ll:
1. get Jenkins and SonarQube up and running

2. install the SonarQube Scanner Jenkins plugin and configure it to point to our
SonarQube instance
3. configure SonarQube to call the Jenkins webhook when project analysis is finished
4. create two Jenkins pipelines
 one that runs against a codebase with zero issues (I wish all my code was like
this
 one that runs against a codebase with bad code issues
5. run the pipelines and see it all working
You’ll need to make sure you have Docker installed before carrying on.
Fast track: to get up and running quickly check out this GitHub repository. Everything is
setup through configuration-as-code, except the steps under Configure SonarQube below.

DevOps Dept. of CSE
Running Jenkins and SonarQube
What better way to start these two services than with Docker Compose? Create the following
file docker-compose.yml:
version: "3"
services:
sonarqube:
image: sonarqube:lts
ports:
- 9000:9000
networks:
- mynetwork
environment:
- SONAR_FORCEAUTHENTICATION=false
jenkins:
image: jenkins/jenkins:2.319.1-jdk11
ports:
- 8080:8080
networks:
- myn network

DevOps Dept. of CSE
networks:
myn network:
 we’re configuring two containers in Docker Compose: Jenkins and SonarQube

 the Docker images used come from the official repositories in Docker Hub
 we’re adding both containers to the same network so they can talk to each other
 for demo purposes SonarQube authentication is disabled so Jenkins won’t need to
pass a token
Running docker-compose up in the directory containing the file will start Jenkins
on http://localhost:8080 and SonarQube on http://localhost:9000. Awesomeness!
Configuring the SonarQube Scanner Jenkins plugin
Grab the Jenkins administrator password from the Jenkins logs in the console output of the
Docker Compose command you just ran.
jenkins_1 | Please use the following password to proceed to installation:

jenkins_1 |
jenkins_1 | 7efed7f025ee430c8938beaa975f5dde
Head over to your Jenkins instance and paste in the password.

DevOps Dept. of CSE
On the next page choose Select plugins to install and install only the pipeline and git plugins.
The SonarQube Scanner plugin we’ll have to install afterwards since this Getting Started page
doesn’t give us the full choice of plugins.
In the final steps you’ll have to create a user and confirm the Jenkins URL
of http://localhost:8080.
Once complete head over to Manage Jenkins > Manage Plugins > Available and search
for sonar. Select the SonarQube Scanner plugin and click Install without restart.

DevOps Dept. of CSE
Once the plugin is installed, let’s configure it!
Go to Manage Jenkins > Configure System and scroll down to the SonarQube server’s
section. This is where we’ll add details of our SonarQube server so Jenkins can passits details to our
project’s build when we run it.
Click the Add SonarQube button. Now add a Name for the server, such as SonarQube.
The Server URL will be http://sonarqube:9000. Remember to click Save.

DevOps Dept. of CSE
Networking in Docker Compose: The SonarQube URL

is http://sonarqube:9000 because by default Docker Compose allows any service to call
any other service in the same network. You do this by using the service name as the hostname
in the request URL, as defined in docker-compose. This is why we use a host of SonarQube.
Configuring SonarQube
Let’s jump over to SonarQube. Click Log in at the top-right of the page, and log in with the
default credentials of admin/admin. You’ll then have to set a new password.
Now go to Administration > Configuration > Web hooks. This is where we can add web
hooks that get called when project analysis is completed. In our case we need to configure
SonarQube to call Jenkins to let it know the results of the analysis.
Click Create, and in the popup that appears give the web hook a name of Jenkins, set the
URL to http://jenkins:8080/sonarqube-webhook and click Create.

DevOps Dept. of CSE
In this case, the URL has the path SonarQube-webhook which is exposed by the SonarQube
Scanner plugin we installed earlier.
Adding a quality gate
SonarQube comes with its own Sonar way quality gate enabled by default. If you click
on Quality Gates you can see the details of this.

DevOps Dept. of CSE
It’s all about making sure that new code is of a high quality. In this example we want to
check the quality of existing code, so we need to create a new quality gate.
Click Create, then give the quality gate a name. I’ve called mine Tom Way
Click Save then on the next screen click Add Condition. Select On Overall Code. Search
for the metric Maintainability Rating and choose worse than A. This means that if existing
code is not maintainable then the quality gate will fail. Click Add Condition to save the
condition.

DevOps Dept. of CSE
Finally click Set as Default at the top of the page to make sure that this quality gate will
apply to any new code analysis.
Creating Jenkins pipelines

Last thing to do is setup two Jenkins pipelines:
1. A pipeline which runs against a code project over at the SonarQube-jacoco-code-
coverage GitHub repository. The code here is decent enough that the pipeline should
pass.
2. A pipeline which runs against the same project, but uses the bad-code branch. The code
here is so bad that the pipeline should fail.

DevOps Dept. of CSE
Good code pipeline
Back in Jenkins click New Item and give it a name of SonarQube-good-code, select
the Pipeline job type, then click OK.
Scroll down to the Pipeline section of the configuration page and enter the following
declarative pipeline script in the Script textbox:
pipeline {
agent any
stages {
stage('Clone sources'){
steps {
git url: 'https://github.com/tkgregory/sonarqube-jacoco-code-coverage.git'
stage('SonarQube analysis'){
steps {
withSonarQubeEnv('SonarQube'){
sh"./gradlewsonarqube"
stage("Quality gate"){
steps {
waitForQualityGateabortPipeline: true

DevOps Dept. of CSE
The script has three stages:
1. in the Clone sources stage code is cloned from the GitHub repository mentioned
earlier
2. in the SonarQube analysis stage we use the withSonarQubeEnv('Sonarqube') method
exposed by the plugin to wrap the Gradle build of the code repository. This
provides all the configuration required for the build to know where to find
SonarQube. Note that the project build itself must have a way of running
SonarQube analysis, which in this case is done by running ./gradlewsonarqube. For
more information about running SonarQube analysis in a Gradle build see this
article
3. in the Quality gate stage we use the waitForQualityGate method exposed by the
plugin to wait until the SonarQube server has called the Jenkins webhook.
The abortPipeline flag means if the SonarQube analysis result is a failure, we abort
the pipeline.
Click Save to save the pipeline.
SonarQube magic: all the withSonarQubeEnv method does is export some environment
variables that the project’s build understands. By adding a pipeline step which runs the
command printenv wrapped in withSonarQubeEnv, you’ll be able to see environment
variables such as SONAR_HOST_URL being set. These get picked up by the Gradle build of the
code project to tell it which SonarQube server to connect to.
Bad code pipeline
Create another pipeline in the same way, but name it SonarQube-bad-code. The pipeline
script is almost exactly the same, except this time we need to check out the bad-code branch
of the same repository.
pipeline {
agent any
stages {
stage('Clone sources'){
steps {

DevOps Dept. of CSE
git branch: 'bad-code', url: 'https://github.com/tkgregory/sonarqube-jacoco-code-coverage.git'
stage('SonarQube analysis'){
steps {
withSonarQubeEnv('SonarQube'){
sh"./gradlewsonarqube"
stage("Quality gate"){
steps {
waitForQualityGateabortPipeline: true
In the Clone sources stage, we’re now also specifying the branch attribute to point to
the bad-code branch
Again, click Save.
You should now have two Jenkins jobs waiting to be run.

DevOps Dept. of CSE
SonarQube analysis and quality gate stages in action
Yes, that’s right, now it’s time to run our pipelines!
Let’s run the sonarqube-good-code pipeline first.
You should get a build with all three stages passing.
If we head over to SonarQube we can see that indeed our project has passed the quality gate.

DevOps Dept. of CSE
Now let’s run the SonarQube-bad-code pipeline. Remember this is running against some
really bad code!
You’ll be able to see that the Quality gate stage of the pipeline has failed. Exactly what we
wanted, blocking any future progress of this pipeline.
In the build’s Console Output, you’ll see the message ERROR: Pipeline aborted due toquality gate
failure: ERRORwhich shows that the pipeline failed for the right reason.

DevOps Dept. of CSE
Over in SonarQube you’ll see that this time it’s reporting a Quality Gate failure.
Looks like we got some code smells on our hands!
Click on the project name for more details.

We can see that the maintainability rating has dropped to B because of the two code smells.
This doesn’t meet our quality gate, which requires a minimum A rating.
Final thoughts
You’ve seen that integrating SonarQube quality gates into Jenkins is straightforward using
the SonarQube Scanner Jenkins plugin. To apply this to a production setup, I suggest also to:
 remove the SONAR_FORCEAUTHENTICATION environment variable from

SonarQube & configure the webhook in Jenkins to require an authentication token
(see the SonarQube Scanner plugin configuration)
 consider running SonarQube analysis on feature branches, so developers get early
feedback on whether their code changes are good before merging into master.
However, multi-branch analysis does require a paid subscription to SonarQube.
For full details about setting up SonarQube analysis in a Gradle code project, see How To
Measure Code Coverage Using SonarQube and Jacoco. If you’re using Maven, check out
this documentation from SonarQube.

DevOps Dept. of CSE
EXERCISE-11
In the configured Jenkins pipeline created in Exercise 8 and 9, implement quality gates for static
unit testing.
Jenkins provides an out of box functionality for Junit, and provides a host of plugins for
unit testing for other technologies, an example being MS Test for .Net Unit tests.
If you go to the link https://wiki.jenkins-ci.org/display/JENKINS/xUnit+Plugin it will give
the list of Unit Testing plugins available.

DevOps Dept. of CSE
Example of a Junit Test in Jenkins

The following example will consider
 A simple HelloWorldTest class based on Junit.

 Ant as the build tool within Jenkins to build the class accordingly.
Step 1 − Go to the Jenkins dashboard and Click on the existing HelloWorld project and
choose the Configure option

DevOps Dept. of CSE
Step 2 − Browse to the section to Add a Build step and choose the option to Invoke Ant.
Step 3 − Click on the Advanced button.

DevOps Dept. of CSE
Step 4 − In the build file section, enter the location of the build.xml file.
Step 5 − Next click the option to Add post-build option and choose the option of “Publish
Junit test result report”

DevOps Dept. of CSE
Step 6 − In the Test reports XML’s, enter the location as shown below. Ensure that Reports is
a folder which is created in the HelloWorld project workspace. The “*.xml” basically tells
Jenkins to pick up the result xml files which are produced by the running of the Junit test
cases.
These xml files which then be converted into reports which can be viewed later.
Once done, click the Save option at the end.
Step 7 − Once saved, you can click on the Build Now option.
Once the build is completed, a status of the build will show if the build was successful or not.
In the Build output information, you will now notice an additional section called Test Result.
In our case, we entered a negative Test case so that the result would fail just as an example.

DevOps Dept. of CSE
One can go to the Console output to see further information. But what’s more interesting is
that if you click on Test Result, you will now see a drill down of the Test results.

DevOps Dept. of CSE
EXERCISE-12
Module name: Course end assessment.
In the configured Jenkins pipeline created in Exercise 8 and 9, implement quality gates for
code coverage.
Code analysis in the agile product development cycle is one of the important and necessary
items to avoid possible failures and defects arising out of the continuous changes in the source
codes. There are few good reasons to include this in our development lifecycle.
 It can help to find vulnerabilities in the distant corners of your application, which are
not even used, then also static analysis has a higher probability of finding those
vulnerabilities.
 You can define your project specific rules, and they will be ensured to follow without
any manual intervention.
 It can help to find the bug early in the development cycle, which means less cost to fix
them.
More importantly this you can include in your build process once and use it always
withouthaving to do any manual steps.
Challenge
Now let’s talk about the actual the challenge. SonarQube does help us to gain
visibility into our code base. However, soon you will realize that having visibility into code
isn't enough and in order to take the actual advantage of code analysis, we need to make the
use of different data insights that we get with SonarQube.
One way was to enforce the standards and regulate them across all teams within the
organization. Quality Gates exactly what we needed here and are the best way to ensure that
standards are met and regulated across all the projects in your organization.
Quality Gates can be defined as a set of threshold measures set on your project like
Code Coverage, Technical Debt Measure, Number of Blocker/Critical issues, Security
Rating/ Unit Test Pass Rate and more.

DevOps Dept. of CSE
Enforce Quality Gates
Failing your build jobs when the code doesn’t meet criteria set in Quality Gates should
be the way to go. We were using Jenkins as our CI tool and therefore we wanted to setup
Jenkins job to fail if the code doesn’t meet quality gates.
In this article, we are going to setup following
1. Quality gate metrics setup in SonarQube.

2. Configure Jenkins job to fail the build when not meeting Quality Gates.
Jenkins job setup

Prerequisites
 Install Jenkins plugin “sonar-quality-gates-plugin” if not already present.

 Email-ext. plugin for Jenkins to be able to send emails.
 Jenkins project configured i.e., successfully passing the build already.
Here is the snapshot of the job that currently passing build before Quality Gates setup.

DevOps Dept. of CSE
Let’s setup Quality gate metrics in the SonarQube server. We are going to create
quality gate only for the metrics “Code coverage” for demo purpose. But there are more
metrics availablethat you should be selecting while creating quality gates.
Login to SonarQube as admin → go to Quality Gates
Click on create -> Add Condition -> Choose metrics

(In this example, we selected Code Coverage) -> select operator along with warning and
error threshold.

DevOps Dept. of CSE
Select the project from the available list to which you want to associate this quality
gate. Wehave selected sample miqp project for which we have set up Jenkins job.
Now go to the Jenkins job and configure the quality gate validation. Click on the job
and go to Post-build Actions and provide the project details you have associated with
Quality Gatecreated in the earlier steps.

DevOps Dept. of CSE
Run the Jenkins job again and verify the build status post quality check enabled.
As we could see that code passed the build, however, it doesn't pass quality gate check.
Therefore, build fails in the end. We can verify the same with the project status in SonarQube
server

Devops Record

Uploaded by

Copyright:

Available Formats

Devops Record

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Devops Record

Uploaded by

Copyright:

Available Formats

SIR C R REDDY COLLEGE OF ENGINEERING

This is to certify that this is the BONAFIDE RECORD of the work

 Total number of experiments held : 12

LAB-IN-CHARGE HEAD OF THE DEPARTMENT

S. No. Name of The Experiment Date Page Valued Grade

models, values and principles of agility and

the need fragile software development.

This will enable you to work in projects

following an agile approach to software

Get a working knowledge of using extreme

practices of test first development,

refactoring and automating test case

It is important to comprehend the need to

lifecycle stages through DevOps. Gain an

understanding of the capabilities required

to implement DevOps, continuous

integration and continuous delivery

4 Configure the web application and Version

Sir C.R. Reddy College of Engineering Page No: I

Configure a static code analyzer which will

application code and identify the coding

practices that are not appropriate. Configure

the profiles and dashboard of the static

code analysis tool.

6 Write a build script to build the application

using a build automation tool like Maven.

Create a folder structure that will run the

build script and invoke the various software

development build stages. This script

should invoke the static analysis tool and

unit test cases and deploy the application to

a web application server like Tomcat.

Configure the Jenkins tool with the

8 Configure the Jenkins pipeline to call the

build script jobs and configure to run it

whenever there is a change made to an

application in the version control system.

Make a change to the background colour of

the landing page of the web application

and check if the configured pipeline runs.

Sir C.R. Reddy College of Engineering Page No: II

In the configured Jenkins pipeline created in

In the configured Jenkins pipeline created in

12 In the configured Jenkins pipeline created in

Sir C.R. Reddy College of Engineering Page No: III

Skill Oriented Course- III

Reference course name: Software Engineering and Agile Software Development

The people who are involving in

Sir C.R. Reddy College of Engineering Page No: 1

Sir C.R. Reddy College of Engineering Page No: 2

Fig: Water Fall Model

Advantages of Waterfall Methods

Disadvantages of Waterfall Methods

It is teamwork-based software development where continuous iteration is possible

Sir C.R. Reddy College of Engineering Page No: 3

Fig: Agile Methodology

Advantages of Agile Methodology

Disadvantages of Agile Methodology