DEVOPS

(CS503PC)
Course Outcomes: On successful completion of this
course, students will be able to:

1. Identify components of DevOps environment

2. Describe Software development models and
architectures of DevOps
3. Apply different project management, integration,
testing and code deployment tool
4. Investigate different DevOps Software development
models
5. Assess various DevOps practices
6. Collaborate and adopt DevOps in real-time projects
UNIT 1
 Introduction: Introduction
 Agile development model
 DevOps, and ITIL
 DevOps process and Continuous Delivery
 Release management
 Scrum
 Kanban
 delivery pipeline
 bottlenecks
Software Development Process

 Software is not built randomly. It follows a structured

process to go from an idea to a working product.
Phases in SDLC (Software Development Life Cycle):
 Requirement Gathering – Understand what to build.
 Design – Create system architecture (what connects to

what).
 Development – Write the code.
 Testing – Check if it works as expected.
 Deployment – Release it to users.
 Maintenance – Fix bugs, add new features.
 Waterfall Model (Linear Sequential
Model)
Problems with Traditional Models

 Developers and Operations Teams are

Separate

 Code Works on Developer Machine but Fails

in Production

 Manual Testing and Deployment

 No Feedback from Users Until Late

 What is DevOps?

 DevOps is a culture and set of practices that

combines Development (Dev) and Operations
(Ops) to deliver software faster, reliably, and
continuously.
 The idea is: Build → Test → Release → Monitor →

Repeat
 Development (Dev) – people who write the software

(coders, testers)
 Operations (Ops) – people who maintain the

systems that run the software (IT support, system

admins)
What Problem Does DevOps Solve?
 In traditional software development:
 Developers wrote code and threw it "over

the wall" to the operations team.

 Operations had to deploy and manage the

software without knowing how it was

written.
 This caused delays, errors, and blame

between teams.
 DevOps breaks this wall down.
 It encourages collaboration, automation,

and shared responsibility from start to

finish.
 Core Principles of DevOps
Principle Description Example

Developers and Operations work as one They meet daily, share tasks, and
1. Collaboration
team solve problems together

Automatically test and deploy code

2. Automation Use tools to do repetitive tasks
without human errors

3. Continuous Integration Code is tested and merged frequently Code is always up-to-date and
(CI) (daily/hourly) working

4. Continuous Delivery (CD) Software is ready for release at any time New features can go live quickly

Constantly check systems and learn from If a bug appears, alerts are triggered
5. Monitoring & Feedback
issues and the team fixes it immediately
 DevOps Tools
Tool Use

Git Source code control (track changes in code)

Jenkins Automate building and testing code (CI/CD)

Docker Package apps into containers to run anywhere

Kubernetes Manage containers at large scale

DevOps vs Traditional Models

Point Traditional Model DevOps Model

Separate teams for Dev

1. Team Structure Unified Dev + Ops team
& Ops

2. Communication Minimal, siloed Continuous and open

3. Speed of
Slow
Development Fast

4. Feedback After release Continuous during development

5. Flexibility Hard to change Easy to adapt

Manual
6. Automation Automated processes
testing/deployment
 At end of Ongoing (early and
7. Testing
development continuous)

8. Time to Market Delayed Fast

Dev builds, Ops

9. Responsibility Shared responsibility
runs
10. Issue
Slow detection/fix Fast detection and fix
Resolution
“Not my job” “We’re in it together”
11. Culture
attitude mindset
Built in from the
12. Quality Focus Focus at the end
start
Automated
13. Infrastructure Manual setup (Infrastructure as
Code)
14. Customer Delayed feedback, Fast updates, happier
Satisfaction slow fixes users
What Is Agile?

 Agile is a way to build software that focuses on:

 Delivering work in small pieces,
 Getting feedback quickly,
 Improving continuously.
 History of Agile
 February 2001 – The Snowbird Meeting
 Seventeen software experts met at a ski resort in Snowbird, Utah,

USA to discuss a better approach to software development.

 They created a short but powerful document called the Agile

Manifesto.
The Agile Manifesto (2001)
 It has 4 values and 12 principles.

The 4 Core Values:

 Individuals and interactions over processes and tools

 Working software over comprehensive documentation

 Customer collaboration over contract negotiation

 Responding to change over following a plan

 Core principles
1.Customer satisfaction is top priority

2. Welcome changes—even late in the project

3. Deliver working software frequently

4. Business people and developers must work together daily

5. Build projects around motivated individuals

6. Face-to-face communication is best

7. Working software is the true measure of progress

 Core principles
8. Agile promotes sustainable development

9. Focus on technical excellence and good design

10. Simplicity—the art of maximizing the amount of

work not done—is essential

11. Teams work best when they organize themselves

12. Regularly reflect and adjust to improve

 Agile Process
1. Gather Requirements (User Stories):“What do you want the software to do?”
2. Sprint Planning : The team chooses a few user stories from the backlog to work on
in the next sprint (usually 1–4 weeks long).
3. Start the Sprint (Development Time):The team starts coding and building the
features.
 Every day, they have a short meeting (called a Daily Stand-up) to discuss:

4. Test and Review

 At the end of the sprint, the team:

 Tests what they built

 Shows it to the customer

 This is called a Sprint Review.

5. Feedback and Retrospective : After the review, the team has a Sprint
Retrospective, where they reflect:
 What went well?

 What didn’t go well?

 How can we improve in the next sprint?

6. Next Sprint Begins
 Based on feedback, the team:

 Updates the backlog

 Plans the next sprint

 Starts building the next set of features

 This cycle continues until the whole product is ready.

 Term
Backlog A list of all features the customer wants
A short period (1–4 weeks) to build part
Sprint
of the software
A short sentence describing what the
User Story
user wants
A quick daily meeting for progress
Daily Stand-up
updates
Meeting with the customer to show what
Sprint Review
was built

Agile Roles in a Team

Role Who They Are What They Do
Decides what features are
Product Owner Represents the customer
needed

Makes sure Agile is followed

Scrum Master Team leader (like a coach)
and removes obstacles

Programmers, designers,
Development Team Build and test the product
testers
Advantages of Agile

 Focused
 Flexible
 Team-based
 Early Delivery
 Better Quality

Disadvantages of Agile

 Can be chaotic
 Needs good communication
 Can take longer if not managed
What is ITIL?

 ITIL = Information Technology Infrastructure Library

The Goal of ITIL
 To help businesses:

 Deliver high-quality, consistent IT services

 Handle problems and incidents in a systematic way

 Align IT with business needs

ITIL Service Lifecycle
ITIL organizes IT work into 5 stages, each with its own
processes:
1. Service Strategy – What should we offer?
2. Service Design – How will we deliver it?
3. Service Transition – How do we launch new services?
4. Service Operation – How do we manage services
daily?
5. Continual Service Improvement – How can we
improve?
ITIL Processes
Process Purpose

Incident Management Fix issues quickly

Find root causes of frequent

Problem Management
issues
Control and track system
Change Management
updates

Service Request
Handle user needs
Management

Track IT assets and their

Configuration Management
relationships
 DevOps vs. ITIL
Feature DevOps ITIL

Focus Software delivery IT service management

Deliver features faster, Deliver stable, reliable

Goal
automate everything services

Approach Agile, flexible, continuous Structured, process-based

Rapid development and Standardized operations and

Style
deployment support

Developers, operations
Users IT support, service managers
engineers

Jenkins, Docker,
Tools ServiceNow, BMC Remedy
Kubernetes
 Can DevOps and ITIL Work
Together?
 Can DevOps and ITIL Work Together?

Situation DevOps Helps ITIL Helps

Ensures changes are

Build new Automates building,
approved and
software testing, deploying
documented
Tracks system
Makes deployments
Deploy updates changes and
faster and reliable
incidents

Logs incidents,
Uses monitoring tools assigns
Handle crashes
to detect problems responsibility, and
reports
Continuous Integration vs Continuous Delivery vs Deployment

CI (Continuous Integration):Code is automatically

tested and merged daily
CD (Continuous Delivery):Code is always ready to be
deployed (manually)
CD (Continuous Deployment):Code is deployed
automatically when all tests pass
Release Management

Release Management is the process of planning, scheduling,

coordinating, and deploying software releases (updates or new
features) to production .

What is the Goal of Release Management?

 To ensure:
 Software is released smoothly and on time
 It works correctly in the live environment
 It causes no disruption to users or services
Key Activities in Release
Management:
Step What Happens
Decide what to include and when to
1. Plan the Release
release
Bundle all code, config, and files
2. Build & Package
together
Make sure it works, doesn't break
3. Test the Release
anything
4. Schedule
Set a date/time for going live
Deployment

5. Deploy the Release Push to production systems

Check for issues, be ready to
6. Monitor and Support
rollback
 Tools Used in Release Management

Tool Purpose

Jira Track release planning and tasks

Git Version control for code

Jenkins / GitLab CI Automate build, test, and deployment

ServiceNow / BMC Remedy ITIL-style release tracking and approvals

Docker / Kubernetes Containerized releases for easy rollouts

Monitoring Tools (e.g., Datadog, Prometheus) Watch for post-release issues

 Controlled vs. Continuous Releases

Type Description

Traditional (Controlled) Release is planned, reviewed, approved step by step

Automated, frequent, small releases (often daily or

DevOps / Agile (Continuous)
hourly)
Release Management in DevOps vs. ITIL

Feature ITIL DevOps

Approach Formal and scheduled Agile and continuous

Goal Stability and risk control Speed and innovation

Frequency Less frequent Very frequent (even hourly)

Process Multiple approvals Automation + feedback loops

 What Is Scrum?
 Scrum is a framework used to build products or complete
projects by breaking the work into small, manageable parts.
 It’s part of Agile — one way to practice Agile values.
 Scrum is lightweight, simple to understand, but powerful
when used well.
 It’s often used in software development, but also in
marketing, education, product design, etc.
 Scrum Framework Components
1. Scrum Roles:
Role Responsibility

Product Owner Decides what needs to be built, sets priorities

Makes sure the team follows Scrum, helps remove

Scrum Master
obstacles

Development Team Builds the product or works on the tasks

2.Scrum Events:
These are the meetings or events that keep the team on track:
Event Purpose When It Happens

A time-boxed period (1–4 weeks) to

Sprint Repeats again and again
complete work

Sprint Planning Decide what to work on this Sprint At the start of every Sprint

Daily Scrum (Stand-up) 15-minute meeting to discuss progress Every day

Show and get feedback on what was
Sprint Review End of the Sprint
built

Team reflects on what went well and

Sprint Retrospective After the Sprint Review
what to improve
3. Scrum Artifacts:
These are the key pieces of information used in Scrum:

Artifact Description Purpose

Product Backlog A list of all features, tasks, and ideas Acts like a to-do list

Sprint Backlog Tasks selected for this Sprint What the team focuses on now

Scrum Cycle:
1. Product Owner creates and updates the Product
2. In Sprint Planning, the team chooses what to build from the backlog
3. The team works during the Sprint (1–4 weeks)
4. Daily Scrum helps team stay on track
5. At end of Sprint: Review (demo) + Retrospective (feedback)
6. Start next Sprint with lessons learned

📌 This cycle repeats until the final product is ready.

Scrum Advantages:
 Faster delivery
 Flexibility
 Team collaboration
 Transparency
 Continuous improvement
 Kanban
 Kanban is a Japanese word that means “signboard” or “visual card.”
 Originally developed by Toyota in the 1940s for automobile production,
Kanban is now widely used in project management — especially in
software development, IT operations, marketing, education, and more.
Purpose of Kanban:
Kanban helps teams:
 Visualize their work

 Limit how much work is in progress

 Identify bottlenecks

 Continuous Delivery
Components of Kanban
1.Kanban Board
 A Kanban board is the main workspace. It has columns
that represent different stages of work.

• To Do - Tasks that are ready to be worked on

• In Progress - Tasks that are currently being worked on

• Done - Finished tasks

2. Kanban Cards
Each task is a card that moves from left to right across the
board.
Each card includes:
 Task name

 Person responsible

 Due date (optional)

 Description

 Priority

 Checklist (optional)

️These cards are moved across the board as progress

happens
3. Work-In-Progress (WIP)
One of the most powerful parts of Kanban.
 You limit how many tasks can be in each column at once.

Why?
 It prevents people from starting too many tasks at once.

 It forces the team to focus and finish before starting new things.

4. Continuous Delivery / Flow

 Kanban is not based on time (like Scrum’s Sprints).

It’s based on flow — the goal is to keep work moving smoothly.
 New work can be added anytime, and finished work can be released
anytime.
 There’s no “start” or “end” of a Sprint — work just flows continuously.
5. Metrics & Improvement

 Teams often use flow-based metrics to

improve performance:

Metrics:
Lead Time
Cycle Time
Throughput
Cumulative Flow Diagram (CFD)
 When to Use Kanban?
 Helpdesk / Support teams
 Ongoing maintenance work
 Teams with lots of changes
 Beginners in Agile
 Remote teams
Tools for Kanban
Tool Description
Most popular, simple drag-and-
Trello
drop
Jira (Kanban board) Used in software development
Whiteboard with Kanban
Miro
templates
 Kanban vs Scrum

Feature Kanban Scrum

Fixed time periods
Time-Based No fixed time (flow-based)
(Sprints)
Defined roles (Scrum
Roles No specific roles Master, Product Owner,
Team)
Tasks planned before
Planning Tasks pulled as needed
each Sprint
Flexibility Very flexible More structured
Daily stand-ups, Sprint
Meetings No required meetings
Planning, etc.
New product
Support teams, ongoing
Best For development, fixed
work
goals
Delivery Continuous At end of Sprint

Visualization Cards on a board Tasks grouped into Sprints

DevOps Lifecycle / Pipeline
 Plan – Work Planning & Prioritization : Define what needs
to be built: features, bug fixes, enhancements.
 Develop – Code Creation & Version Control : Developers
write code locally and commit to a Git repository.
 Build – Compiling and Packaging the Code :Source code is
automatically compiled into an executable or deployable package.
 Test – Quality Assurance Through Automation : Run
automated tests after build to ensure code works correctly.
 Release – Prepare & Approve the Deployment : Code is
marked as a candidate for production release.
 Deploy -Push Code to Production : Release is automatically
deployed to production servers/cloud.
 Monitor – Observe & Optimize in Real-Time:
Application is monitored for health, performance, and usage.
Delivery Pipeline
 A Delivery Pipeline is the automated process of moving software from development
to production — safely and quickly.
 It ensures that every code change goes through building, testing, and releasing — in
a controlled, repeatable way.

Why Is It Important?
Before pipelines, teams would:
 Write code for weeks/months
 Do manual testing
 Deploy manually (which was slow and error-prone)

With a Delivery Pipeline, teams can:

Release faster
Catch bugs early
Automate repetitive work
Deliver higher-quality software
Stages in a Delivery Pipeline
1. Source Code Management (SCM):
Tool examples: Git, GitHub, Bitbucket
2. Build Stage:
Tools: Maven, Gradle, MSBuild, Jenkins, Azure Pipelines
3. Automated Testing Stage:
Tools: JUnit, Selenium, PyTest, TestNG
4. Staging/Pre-production:
Tools: Docker, Kubernetes, Ansible
5. Deployment (Release Stage):
Tools: Jenkins, GitLab CI/CD, Azure DevOps, CircleCI
6. Monitoring and Feedback
Tools: Prometheus, Grafana, New Relic, Sentry
Benefits of Delivery
Pipeline
 Faster delivery
 Automated testing
 Repeatable
 Transparent
 Reduces risk
 Common Bottlenecks
 Limited automation
 Slow feedback
 Inadequate logging and monitoring
 Manual releases
 Complex configuration management,
 Poor collaboration
 Agile DevOps
Focuses on how teams write and plan Focuses on how software is delivered
1
code and maintained

Breaks work into small parts called Automates building, testing, and
2
sprints deploying code
Encourages frequent feedback from Connects development and
3
users operations teams
Helps teams adapt to change Ensures software runs reliably in
4
quickly production
Mainly involves developers and Involves developers and operations
5
testers teams
Emphasizes collaboration within the Emphasizes collaboration between
6
team dev and ops

Uses tools for continuous integration

7 Uses meetings like daily stand-ups
& delivery (CI/CD)

Focuses on delivering working Monitors software health and

8
software regularly performance continuously

Helps teams fix problems faster in

9 Manages requirements and features
live systems

Improves product development Improves software stability and

10
speed and quality scalability
# Agile DevOps Detailed Explanation

Focuses on how software is Agile is about creating features efficiently;

Focuses on how teams write
1 delivered and DevOps ensures those features are deployed
and plan code.
maintained. and sustained in production.

Breaks work into small, Automates building, Agile uses time-boxed iterations for progress;
2 manageable parts called testing, and deploying DevOps builds automation to move code
sprints. code. from commit to live quickly and safely.

Agile feedback loops are mostly from

Encourages frequent Connects development stakeholders/customers; DevOps feedback
3
feedback from users. and operations teams. loops are also from operational metrics and
monitoring.

Agile adjusts to new requirements easily;

Helps teams adapt to Ensures software runs
4 DevOps focuses on stability, scalability, and
change quickly. reliably in production.
uptime once changes are shipped.

Agile teams are dev/test heavy; DevOps

Mainly involves developers Involves developers and
5 adds ops and sometimes security for full
and testers. operations teams.
lifecycle ownership.
 Uses tools for
Agile’s collaboration is human-
continuous
Uses meetings like daily driven (meetings, ceremonies);
7 integration &
stand-ups. DevOps relies on automation
delivery
pipelines to speed delivery.
(CI/CD).

Monitors
Agile gets features out; DevOps
Focuses on delivering software health
ensures they stay healthy and
8 working software and
performant through monitoring
regularly. performance
and alerting.
continuously.
Helps teams fix Agile manages the backlog;
Manages requirements problems DevOps addresses production
9
and features. faster in live issues quickly using monitoring,
systems. automation, and quick rollbacks.

Improves Agile speeds up the creation of

Improves product
software quality features; DevOps ensures
10 development speed
stability and those features can scale and
and quality.
scalability. remain reliable over time.