Exercise: 1

AIM: Explain about Software engineering and Agile software development?

Software Development Life Cycle:

A software life cycle model (also termed process model) is a pictorial and diagrammatic
representation of the software life cycle. A life cycle model represents all the methods
required to make a software product transit through its life cycle stages. It also captures the
structure in which these methods are to be undertaken.

In other words, a life cycle model maps the various activities performed on a software
product from its inception to retirement. Different life cycle models may plan the necessary
development activities to phases in different ways. Thus, no element which life cycle
model is followed, the essential activities are contained in all life cycle models though the
action may be carried out in distinct orders in different life cycle models. During any life
cycle stage, more than one activity may also be carried out

The stages of SDLC are as follows:

Stage1: Planning and requirement analysis

Requirement Analysis is the most important and necessary stage in SDLC.

The senior members of the team perform it with inputs from all the stakeholders and domain
experts or SMEs in the industry.

Planning for the quality assurance requirements and identifications of the risks associated
with the projects is also done at this stage.

Business analyst and Project organizer set up a meeting with the client to gather all the data
like what the customer wants to build, who will be the end user, what is the objective of the
product. Before creating a product, a core understanding or knowledge of the product is
very necessary.

For Example, A client wants to have an application which concerns money transactions. In
this method, the requirement has to be precise like what kind of operations will be done,
how it will be done, in which currency it will be done, etc.

Once the required function is done, an analysis is complete with auditing the feasibility of
thegrowth of a product. In case of any ambiguity, a signal is set up for further discussion.

Stage2: Defining Requirements

Once the requirement analysis is done, the next stage is to certainly represent and
document the software requirements and get them accepted from the project stakeholders.

This is accomplished through "SRS"- Software Requirement Specification document which

contains all the product requirements to be constructed and developed during the project
life cycle.

Stage3: Designing the Software

The next phase is about to bring down all the knowledge of requirements, analysis, and
design of the software project. This phase is the product of the last two, like inputs from the
customer and requirement gathering.

Stage4: Developing the project

In this phase of SDLC, the actual development begins, and the programming is built. The
implementation of design begins concerning writing code. Developers have to follow the
coding guidelines described by their management and programming tools like compilers,
interpreters, debuggers, etc. are used to develop and implement the code.

Stage5: Testing

After the code is generated, it is tested against the requirements to make sure that the
products are solving the needs addressed and gathered during the requirements
stage.During this stage, unit testing, integration testing, system testing, acceptance testing
are done.

Stage6: Deployment
Once the software is certified, and no bugs or errors are stated, then it is deployed.Then
based on the assessment, the software may be released as it is or with suggested
enhancement in the object segment. After the software is deployed, then its maintenance
begins.

Stage7: Maintenance

Once when the client starts using the developed systems, then the real issues come up and
requirements to be solved from time to time.This procedure where the care is taken for the
developed product is known as maintenance.

What are agile methodologies?

The first we heard about Agile development (or the term Agile) was back in 2001 when a
community of developers that had grown tired of using development methods considered
to be “heavy” – namely, the waterfall model – decided to set out a manifesto: The Agile
Manifesto. This very important document had so much impact that it has worked as a bible
for Agile development even until today, laying out all principles and good practices.

Agile methodologies argue that, above all, we should seek client satisfaction through the
continuous delivery of value-adding software, by staying in constant communication with
the client, and also by focusing on communication between team members.
Contrary to previous practices, Agile methodology is not characterised by the complete
definition of a product, but rather “step by step” – a complete analysis or the definition of
all categories/requirements, by dynamic interaction that allows constant delivery
– Focused on “near-shore” visibility but never losing the long-term product goal.

Customer satisfaction is the top priority, demonstrated through continuous delivery and
addedvalue.

The customer and the development team should work together on a daily basis, facilitating
team and product synchronisation.

It is vital to provide a pleasant environment and good support to development teams. Only
inthis way is it possible to keep them motivated.
Agile processes promote sustainable development due to their constant rhythm and
technical.
The main advantage of using Agile methodologies is not just the fast delivery of software, but
also the constant delivery of “value” to the customer, since deliveries are incremental.

Business development is becoming an increasingly unpredictable playground, just like

software development. So the challenge is now why not implement Agile methodologies in

business process management? Agile methods are adaptable, allowing for rapid decision-
making and instant influence on business development.

4 values of Agile Manifesto

Main Agile methodologies:

1. Scrum

Scrum is, undoubtedly, the most used of the many frameworks underpinning Agile
methodology. Scrum is characterised by cycles or stages of development, known assprints,
and by the maximisation of development time for a software product towards a goal, the
Product Goal. This Product Goal is a larger value objective, in which sprints bring the scrum
team product a step closer.

It is usually used in the management of the development of software products but can be
used successfully in a business-related context. Every day starts with a small 15-minute
meeting, the daily Scrum, which takes the role of synchronising activities and finding the
best way to plan out the working day, allowing for a check on sprint “health” and product
progress.

2.kanban

The word Kanban is of Japanese origin and its meaning is linked to the concept of “just in
time”. In practice, the Kanban method is organised on a board or table (Kanban board),
divided into columns, showing every flow within the software production project. As the
development evolves, the information contained in the table changes, and whenever a new
task comes into play, a new “card” is created.

This methodology is also useful in individual business departments, such as HR, marketing,
etc., bringing the desired visibility over all the team’s tasks

2. Extreme Programming (XP)

This is a typical Agile development framework, developed by Kent Beck, and can be adapted
to development companies of various dimensions.

Extreme Programming (“XP”) methodology is based around the idea of discovering “the
simplest thing that will work” without putting too much weight on the long-term product
view. It is a methodology that emphasises values such as Communication, Simplicity,
Feedback, Courage and Respect, and prioritises customer satisfaction over everything else.
This methodology encourages trust by motivating developers to accept changes in customer
requirements, even if they arrive during the latter stages of the development cycle.
 Exercise: 2
AIM: Explain about Development & Testing with Agile: Extreme Programming

Extreme Programming XP Practices

Planning Game

In XP the main planning process is called Planning Game. There are 2 levels of plans in XP;
level one is release planning and level 2 is iteration planning.

In both levels, there are 3 steps: exploration, commitment, and steering.

The first phase is release planning. The team and stakeholders/customers collaboratively
decide what are the requirements and features that can be delivered into production and
when. This is done based on priorities, capacity, estimations and risks factor of the team to
deliver.

Simple Design
In the XP, the team will not do complex or big architecture and designs upfront; instead the
team will start with a simple design and let it emerge and evolve over a period of
iterations. The code is frequently refactored so that it will be maintainable and free of
technical debt. Simple designs make the 'definition of done' easier.

XP teams conduct a small test or proof-of-concept workout called spike. The outcome of the
spike helps the team to apprehend the validity of the hypothesis, gauge the complexity of
the solution and feel assured to estimate and build something primarily based on the test.

Test-Driven Development (TDD)

In XP Developers write the unit test cases before starting the coding. The team automates
the unit tests and it helps during the build and integration stage. The main benefit of TDD is
that programmers have to only write the code that passes the tests.

Basics steps of TDD,

 Write the unit test case first
 Write a minimal amount of code to pass the test.
 Refactor it by adding the needed feature and functionality, While continuously
making sure the tests pass.
Code Standard

Organizations want their programmers to hold to some well-described and standard style of
coding called coding standards. It is a guideline for the development team as in XP. Since
there are multiple programming pairs at play coding standards are very useful to make
consistency in code, style, naming conversion, exception handling and use of parameters.

These standards must define and agreed before the team starts the coding.

It will make the code simple to understand and helps detect the problem or issues quickly
andalso increases the efficiency of the software.
Refactoring

Refactoring as the word suggests, is restructuring or reconstructing existing things. In XP

over a period of time the team produces lots of working code and it increases the
complexity and that contributes technical debt. To avoid this, we should consider the below
points,
 Ensure code or functions are not duplicated.
 Ensure all variables in scope, defined and used.
 No long functions or methods
 Removing unnecessary stuff and variables
 Proper use of access modifiers etc.
By refactoring, the programmers look to improve the overall code quality and make it more
readable without altering its behavior.

Pair Programming

This is my favorite and most used practice. Pair programming consists of two programmers
operating on the same code and unit tase cases, on the same system (one display and one
keyboard). One programmer plays the pilot role and focuses on clean code, and compiles
and runs. The second one plays the role of navigator and focuses on the big picture and
reviews code for improvement or refactoring.

Every hour or given a period of time this pair is allowed to switch roles so that the pilot will
play the role of navigator and vice versa.

The pairs of pilots and navigators are also not fixed and they are frequently swapped, the
main benefits of that over a period of time is that everyone gets to know about the code
and functionality of the whole system.

Collective Code Ownership

By following pair programming practices the XP team always takes collective ownership of
code. Success or failure is a collective effort and there is no blame game. There is no one key
player here, so if there is a bug or issue then any developer can be called to fix it.
Continuous Integration

CI is Continuous Integration. In XP, Developers do pairs programming on local versions of

the code. There is a need to integrate changes made every few hours or on a daily basis so
after every code compilation and build we have to integrate it where all the tests are
executed automatically for the entire project.

If the tests fail, they are fixed then and there, so that any chance of defect propagation and
further problems are avoided with minimum downtime.

The team can use CI tools like Jenkins, shippable, Integrity, Azure DevOps Pipelines, etc.

Small Release

A cross-functional team in XP, releases Minimum Viable Product (MVP) frequently. Small
releases also help to breakdown complex modules in a small chunk of code. This helps the
developer team as well as the on-site customer to demonstrate the product and focus only
on the least amount of work that has the highest priority.

System Metaphor

This is majorly connected with the user story, the story must be simple enough to be easily
understood by user and developers and to relate it with code.
It could be a naming conversion practice used in design and code to have a shared
understanding between teams. For example Order_Food() is easily explained -- this will be
used to order food.
 EXERCISE-3

AIM: Solve the questions given in Quiz1, Quiz2, Quiz 3

QUIZ-1:

ANSWER: FALSE

ANSWER:A remote repository platform

ANSWER:--global
ANSWER:git cinfig user.email

ANSWER:git add --all

ANSWER:git status
ANSWER : git init

ANSWER: FALSE

ANSWER: git commit

ANSWER:git commit –m “NEW EMAIL”

ANSWER: git commit -help

ANSWER: git push origin

ANSWER: fetch and merge

QUIZ-2:

1. Identify the tool for DevOps?

 1. Nagios
2. Jenkins
3. Monit
4. All of the above
Answer: All of the above

2. What are the requirements to become a DevOps Engineer?

1. Fluency in web languages like Ruby, Python, PHP or Java
2. Interpersonal skills that help you communicate and collaborate across teams and roles
3. All of the above
Answer: All of the above

3. Which of the following key component of DevOps?

1. Continuous Delivery
2. Continuous Testing
3. Continuous Integration
4. All of the above
Answer: All of the above

4. Which of the following type of Version Control Systems?

1. Local Version Control Systems
2. Distributed Version Control System
3. Centralized Version Control Systems
4. All of the above
Answer: All of the above

5. What do you mean by telemetry?

1. Telemetry is a widely known SaaS tool to plan and execute DevOps projects
2. Telemetry is the process of recording the behaviour of your systems.
Answer: Telemetry is the process of recording the behaviour of your systems.

6. Which of the following isn’t a goal of NewOps?

1. By automating operations, remove the need for human competencies.
2. None of these
Answer: By automating operations, remove the need for human competencies.

7. What do you mean by trunk in trunk based DevOps delivery?

1. Trunk is the process of merging code in DevOps deliveries.
2. Developers collaborate on code in a single branch called “trunk”..
3. None of these
Answer: Developers collaborate on code in a single branch called “trunk”.

8. Which of the following statements defines Feature flags?

1. Feature flags are placeholders for future functionality for an app
 2. Feature flags allow you to show or hide features in an app
Answer: Feature flags allow you to show or hide features in an app

9. Identify the methodologies does least impact the establishment of DevOps methodology?
1. Waterfall Software Delivery
2. Agile Software Delivery
Answer: Waterfall Software Delivery

10. How does DevOps impact security of an application or machine?

1. Security is increased because of the automation process
2. Security is increased by including it earlier in the process
3. Security is reduced because of the automation process
4. Both 1 & 2
Answer: Both 1 & 2

11. What is DevOps?

1. A small team of people that own everything related to a particular service
2. Developers performing operations
3. None of above
Answer: A small team of people that own everything related to a particular service

12. What is trunk in trunk based devops delivery

1. Developers collaborate on code in a single branch called trunk
2. Trunk is the process of merging code in DevOps deliveries
Answer: Developers collaborate on code in a single branch called trunk

13. Which of the following is not a feature of continuous delivery ?

1. Automate Everything
2. Gathering Requirement
Answer: Gathering Requirement

14. What are the Business advantages of DevOps?

1. less stable operating environments
2. Faster delivery of features
3. Both 1 & 2
Answer: Both 1 & 2

15. Who is known as the father of DevOps?

1. Liam Debois
2. Patrick Debois
3. Walter Dandy
4. None of these
Answer: Patrick Debois
Experiment-4

Git for Version Control

Centralized VCS

. In Subversion, CVS, Perforce, etc. A central server repository (repo) holds the
"official copy" of the code – the server maintains the sole version history of the
repo
• You make "checkouts" of it to your local copy – you make local modifications
– your changes are not versioned
• When you're done, you "check in" back to the server – your checkin
increments the repo's version
Distributed VCS (Git)

• In git, mercurial, etc., you don't "checkout" from a central repo – you
"clone" it and "pull" changes from it
• Your local repo is a complete copy of everything on the remote
server – yours is "just as good" as theirs
• Many operations are local: – check in/out from local repo – commit
changes to local repo – local repo keeps version history
• When you're ready, you can "push" changes back to server
 Git snapshots
• Centralized VCS like Subversion track version data on each
individual file.
• Git keeps "snapshots" of the entire state of the project.
Each check in version of the overall code has a copy of each
file in it.
Some files change on a given check-in, some do not.
More redundancy, but faster. Subversion Git 7 Local git
Set the name and email for Git to use when you commit:
git config --global user.name "Bugs Bunny"
git config --global user.email [email protected]
You can call git config –list
to verify these are set. •
Set the editor that is used for writing commit messages:
git config --global core.editor nano • (it is vim by default)

Creating a Git repo

• To create a new local Git repo in your current directory: –
git init
• This will create a .git directory in your current directory.
• Then you can commit files in that directory into the repo. –
git add filename – git commit –m "commit message"
• To clone a remote repo to your current directory: – git
clone url localDirectoryName
• This will create the given local directory, containing a
working copy of the files from the repo, and a .git directory
(used to hold the staging area and your actual local repo)
Experiment -5
Experiment -5
Experiment -5
Experiment -5
Experiment -5
Experiment -5
Experiment -5
Experiment -5
Experiment -5
Experiment -6
Configure a static code analyzer which will perform static analysis of the web
application code and identify the coding practices

Jenkins-SonarQube Integration

Step 1. Open SonarQube server- Go to Administration > click on Security > Users >
Click on Tokens (image 1)> Generate token with some name > Copy the token (image
2), it will be used in Jenkins for Sonar authentication.
Step 2. Setup SonarQube with Jenkins- Go to Manage Jenkins > Configure
system > SonarQube server section > Add SonarQube > Name it, provide Server Url
as http://<IP>:<port> > and authentication token copied from SonarQube Server
> Apply and Save
Step 3. Install SonarQube plugin to Jenkins. Go to Manage Jenkins > Manage
Plugins > Available > Search for SonarQube Scanner> Install.

https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner

Configure Sonar Scanner in Jenkins : Go to Mange Jenkins > Global Tool

Configuration > Scroll for SonarQube Scanner > Add sonar scanner > name it, uncheck
if you already have sonar else it will automatically download for you and your sonar
scanner setup will be done(in my case I already have) > provide path to sonar runner
home as in below image
Step 4. Create a Job- New Item > Name and select a project type (in my case I am
selecting Maven project you can opt for freestyle as well)

Step 5. Set Git under SCM section and use * * * * * for Poll SCM under Build
Trigger section. Under Build Environment section add pre-buid step > select Execute
SonarQube Scanner
Step 6. Create a .properties file at any location and provide path on the task as
below(I have created it in Jenkins workspace folder). This property file will be project
specific. It contains certain sonar properties like which folder to scan, which folder to
exclude in scanning, what is the project key and many more you can see it from

Inside sonar-scanner.properties write below code —

sonar. project Key =github Jenkins sonarsonar.sources=./src

Step 7. Build the job. After successful build if you can see build logs it will show you
the files and folder it has scanned and after scanning it has posted the analysis report
to SonarQube Server you have integrated.

Step 8. From job dashboard, click on sonar icon or navigate to Sonar server click on
Projects (on header) you will see a new project with same project key you have given
in sonar-scanner.properties file. Now you can go inside your project and analyse the
report
Experiment -7
How to Create a New Build Job in Jenkins Freestyle Project

Jenkins Freestyle Project is a repeatable build job, script, or pipeline that contains steps
and post-build actions. It is an improved job or task that can span multiple operations.

Step 1) Login to Jenkins

http://localhost:8080
Step 3) Enter Item details
In the next screen,

1. Enter the name of the item you want to create. We shall use the “Hello world” for
this demo.
2. Select Freestyle project
3. Click Okay

Step 4) Enter Project details

Enter the details of the project you want to test.

Step 5) under source code management

Click: none

Step 7) Save the project

When you have entered all the data,

1. Click Apply
2. Save the project.
Step 10) See the console output

Click on the build number and then Click on console output to see the status of the
build you run
Experiment -8

What is Jenkins Pipeline?

Jenkins Pipeline is a combination of plugins that supports integration and implementation
of continuous delivery pipelines. It has an extensible automation server to create simple
and complex delivery pipelines as code via pipeline DSL. A Pipeline isa group of events
interlinked with each other in a sequence.

What is Continuous Delivery Pipelines? How it Works?

In a Jenkins pipeline, every job or event has some sort of dependency on at least one or
more events.

Jenkins File can be defined by either Web UI or with a Jenkins File.

Declarative versus Scripted pipeline syntax:

There are two types of Jenkins pipeline syntax used for defining your JenkinsFile.

1. Declarative
2. Scripted

Declarative:

Declarative pipeline syntax offers an easy way to create pipelines. It contains a

predefined hierarchy to create Jenkins pipelines. It gives you the ability to control all
aspects of a pipeline execution in a simple, straight-forward manner.

Scripted:

Scripted Jenkins pipeline runs on the Jenkins master with the help of a lightweight
executor. It uses very few resources to translate the pipeline into atomic commands. Both
declarative and scripted syntax are different from each other and are defined totally
differently.

Why Use Jenkin’s Pipeline?

Jenkins is an open continuous integration server which has the ability to support the
automation of software development processes. You can create multiple automation
jobs with the help of use cases, and run them as a Jenkins pipeline.
Install Build Pipeline Plugin in Jenkins
Here is how you can install the build pipeline plugin in your Jenkins:

Step 1) The settings for the plugin can be found under,

Manage Jenkins > Manage Plugins.

Step 2) If you do not have the plugin previously installed,

it shows up under the Available tab.

Experiment -9

How to Create Jenkins Pipeline

logged in to your Jenkins dashboard:

Step 1) Click on the “+” button on the left-hand side of your Jenkins
dashboard to create a pipeline.

Step 2)

1. You will be asked to give a name to the pipeline view. We shall call it “Guru99
Pipeline” for the duration of this demo.
2. Select Build a pipeline view under options
3. Click ok
Step 3) In the next page, you will be asked for some more details to configure your
Jenkins pipeline. Just accept the default settings, and make sure you choose the first
job under the settings.

Click on Apply and then OK.

This will show you the sample pipeline view of your item, as given below