UNIT–I: Introduction to DevOps: Introduction to SDLC, Agile Model.

Introduction to
Devops. DevOps Features, DevOps Architecture, DevOps Lifecycle, Understanding Workflow
and principles, Introduction to DevOps tools, Build Automation, Delivery Automation,
Understanding Code Quality, Automation of CI/ CD. Release management, Scrum, Kanban,
delivery pipeline, bottlenecks, examples Introduction

 Software Development Life Cycle (SDLC)

• It is a process used by the software industry to design, develop and test high quality softwares.
• The SDLC aims to produce a high-quality software that meets or exceeds customer expectations,
reaches completion within times and cost estimates.
• It is also called as Software Development Process.
• SDLC is a framework defining tasks performed at each step in the software development process.
• It consists of a detailed plan describing how to develop, maintain, replace and alter or enhance
specific software.
• The life cycle defines a methodology for improving the quality of software and the overall
development process.

Stage 1: Planning and Requirement Analysis

• Requirement analysis -with inputs from the customer
• This information is then used to plan the basic project approach
• Planning -various technical approaches that can be followed to implement the project
successfully with minimum risks.
Stage 2: Defining Requirements
• Requirements get approved from the customer or the market analysts. This is done
through an SRS (Software Requirement Specification) document which consists of all
the product requirements to be designed and developed during the project life cycle.
Stage 3: Designing the Product Architecture
• SRS is the reference for product architects to come out with the best architecture for the
product to be developed. Based on the requirements specified in SRS, usually more than
one design approach for the product architecture is proposed and documented in a DDS -
Design Document Specification.
• based on various parameters as risk assessment, product robustness, design modularity,
budget and time constraints, the best design approach is selected for the product.
Stage 4: Building or Developing the Product
• The programming code is generated as per DDS during this stage. Developers must
follow the coding guidelines The programming language is chosen with respect to the
type of software being developed.
Stage 5: Testing the Product
• this stage refers to the testing only stage of the product where product defects are
reported, tracked, fixed and retested, until the product reaches the quality standards
defined in the SRS.
Stage 6: Deployment in the Market and Maintenance
• The product may first be released in a limited segment and tested in the real business
environment (UAT- User acceptance testing).
• Then based on the feedback, the product may be released as it is or with suggested
enhancements in the targeting market segment. After the product is released in the
market, its maintenance is done for the existing customer base.

1. Waterfall Model (Linear Sequential Model)

The Waterfall model is the oldest and most straightforward model. It follows a step-by-
step process where each phase must be completed before moving to the next one. You
cannot go back to change or fix something in a previous phase.

Requirements
→
Design
→
Implementation
→
Testing
→
Deployment
→
Maintenance

Each arrow flows one-way, like a waterfall falling down from one level to the next.

Advantages:

• Simple and easy to follow.

• Well-documented process.
• Works well when requirements are fixed and well understood.

Disadvantages:

• No flexibility — you can’t revisit earlier stages.

• Late testing means bugs are found at the end, which is costly to fix.
• Not suitable for complex or dyna;mic projects where requirements change.

Real-Life Example:

Imagine you're building an e-commerce app (like Flipkart):

• You gather all the requirements in the beginning (like "Add to Cart", "Search",
"Payment").
• You do the design, code everything, and only then test it.
• If the client suddenly wants "Wishlist" after the design phase, it’s too late or very
costly to add.
 2. Spiral Model
The Spiral Model combines ideas from both Waterfall and Prototyping models, focusing on
risk analysis and iterative development.

It works in cycles (called spirals). Each spiral involves:

1. Planning
2. Risk analysis
3. Development
4. Testing

After each cycle, the software improves with more features and refinements.

Diagram:
⬆ ⬆
←----| Evaluation | ------- →
| |
Planning → Risk Analysis → Development → Testing
↑ ↓
(Next Spiral Cycle with new features)

Think of it as a spiral moving outward, with each loop bringing the project closer to
completion.

Advantages:

• Focuses on risk management.

• Good for large, complex, high-risk projects.
• Allows for early detection of issues.
• Flexible — changes can be made between cycles.

Disadvantages:

• Complex to manage.
• Expensive (due to risk analysis in each cycle).
• Not suitable for small projects.

Real-Life Example:

Imagine developing flight control software for aircraft:

• In the first spiral, you develop and test basic flight data.
 • In the next spiral, add altitude controls and safety checks.
• In the third spiral, handle emergency landing systems.
• Each feature is built, evaluated, and tested with risk assessment.

Problems with Traditional Models

1. Developers and Operations Teams are Separate

• In traditional models like Waterfall, the development team (who writes the code) and
the operations team (who deploys and manages it) work in isolation.
• Developers finish the code and then “throw it over the wall” to the Ops team for
deployment.

Why it's a problem:

• Lack of communication leads to delays, misunderstandings, and blame-shifting.

• Developers say: “It works on my machine.”
• Operations say: “But it’s breaking in production!”

Example:
Imagine one group builds a car engine, and another installs it without knowing how it works.
If it doesn’t fit, both groups blame each other.

2. Code Works on Developer Machine but Fails in Production

• Developers build software in their own local environments.

• But the production environment (where real users access the software) can be very
different—different OS, settings, versions of libraries, etc.

Why it's a problem:

• What works fine on a developer’s laptop may crash or behave differently on the
server.
• This causes last-minute surprises during deployment.

Example:
A developer uses version 1.2 of a library, but production uses 1.0 — and suddenly, a feature
fails when deployed.

3. Manual Testing and Deployment = Time-consuming

• In traditional models, testing is done manually, often by QA teams after all

development is completed.
 • Deployment is also manual, involving human steps like uploading files, configuring
servers, restarting services.

Why it's a problem:

• Manual work is slow and error-prone.

• A missed step during deployment can break the whole system.
• Takes days or even weeks to deliver a small feature.

Analogy:
Manually watering plants vs. using an automatic sprinkler system. Manual is fine for a few
plants, but not for an entire field.

4. No Feedback from Users Until Late

• In models like Waterfall, the software is shown to the user only at the end—after
months of work.
• If something is wrong, it’s too late or expensive to fix.

Why it's a problem:

• You might spend weeks building a feature the user doesn’t want.
• Late feedback = wasted time and effort.

Example:
You build an app that allows users to filter shoes by color, but users wanted to filter by size.
You find this out only after full development is done.

5. Hard to Respond Quickly to Bugs or Feature Requests

• Traditional models require formal change requests and approvals.

• Any bug fix or new feature might need to go through a long cycle again: plan →
design → test → deploy.

Why it's a problem:

• Bugs can stay in production for weeks.

• Business teams get frustrated because they can’t adapt to market changes quickly.

Example:
A competitor adds a new “Pay Later” option. Your marketing team wants the same, but it takes months to
go through your slow development process
Agile Model
• An iterative model that focuses on collaboration, customer feedback, and quick,
incremental releases.
• Unlike traditional software development models like waterfall, Agile does not require
detailed upfront planning.

Agile is a way to build software that focuses on:

• Delivering work in small pieces,

• Getting feedback quickly,
• Improving continuously.

Instead of doing everything at once and waiting months to finish a product, Agile breaks the
project into sprints (short development cycles), and delivers parts of the product regularly.

Think of it like building a house room-by-room instead of building the whole thing at
once. After each room is built, the owner checks it and gives feedback before the next room
starts.

four key features of Agile SDLC

• Iterative and incremental: Software is developed in small parts, with each part building
on the last to improve the product gradually
• Short cycles: Work is done in fixed periods (usually 1 to 4 weeks), allowing regular
progress and quick adjustments
• Continuous feedback: Teams collect input from customers and stakeholders regularly to
guide development in the right direction
• Cross-functional teams: Team members from different areas (like design, development,
and testing) work closely together throughout the project.

Agile allows teams to adjust their plans and incorporate feedback at any stage, making it ideal
for projects where requirements may evolve.
• In Agile SDLC, the process is divided into short, manageable cycles called “sprints” or
“iterations.”
• Each sprint includes planning, development, testing, and feedback sessions, ensuring
continuous improvement and regular check-ins. This model is all about teamwork, frequent
product updates, and delivering value to customers at every step.
• The 4 C’s: Clarity, Commitment, Comment, and Coach are principles that support
accountability and performance in Agile teams.

Different Phases of Agile Development

• The Agile SDLC is broken down into six key phases, each designed to drive continuous
collaboration, feedback, and improvement throughout the software development process.
 • 1. Concept: The main objective is to understand the problem that needs to be solved and
establish the overall vision for the product.

• 2. Inception: identify the required resources, and define the project scope.

• 3. Iteration:. Work is broken down into small, manageable units known as sprints. Each
sprint aims to complete specific features or tasks, and progress is regularly reviewed to
ensure alignment with the project goals and customer needs.

• 4. Testing: testing to ensure they meet quality standards and function as intended. This
helps identify and address software bugs.

• 5. Production: Once the product is tested, it moves into production. The final version is
released and made available to customers or users.

• 6. Review/Maintenance: After releasing the product, the team monitors its performance
to identify any issues or areas for improvement. They collect user feedback and use it to
make necessary adjustments or updates.

Why Was Agile So Important?

Because it changed how software was built:

• Faster delivery of working software

• Easier to adapt when requirements changed
• More customer involvement
• Better teamwork

Companies began to adopt Agile because it reduced project failures and improved quality
Introduction to 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

Think of DevOps as a Factory Line for software:

• Every change is automatically built, tested, and shipped

• DevOps, essentially an abbreviation of two words- development and operations, is a

methodology to manage and monitor the complete lifecycle of application development
and deployment by enabling a single team.
• DevOps involves continuous integration, deployment, monitoring, communication, and
collaboration to automate and accelerate processes.
• The end goal of DevOps is to deliver software of superior quality and reliability in the
shortest period.
• Note: DevOps is all about automating and streamlining the software development
lifecycle so that code moves from development to production quickly, reliably, and
securely.

Agile = A methodology to develop software in small iterations using customer feedback.

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. Deployment
Few times a year Multiple times a day
Frequency
 5. Feedback After release Continuous during development

6. Flexibility Hard to change Easy to adapt

Manual
7. Automation Automated processes
testing/deployment

8. Risk High (big releases) Low (small, frequent releases)

9. Testing At end of development Ongoing (early and continuous)

10. Time to Market Delayed Fast

11. Responsibility Dev builds, Ops runs Shared responsibility

12. Issue Resolution Slow detection/fix Fast detection and fix

13. Culture “Not my job” attitude “We’re in it together” mindset

Key features and concepts often included in a DevOps

• Continuous Development: Writing code in small, manageable chunks.
• Continuous Integration (CI): Automatically building and testing code every time a
developer merges their changes into a central repository.
• Continuous Testing: Automated testing throughout the development process to catch
issues early.
• Continuous Deployment/Delivery (CD): Automatically deploying code to production or
to a pre-production environment after it has passed all tests.
• Continuous Monitoring: Continuously tracking the performance and behavior of the
application in production.
• Continuous Feedback: Gathering and acting on feedback from users and monitoring to
improve the product.
• Automation: Automating repetitive tasks like testing, building, and deployment to
increase speed and reduce errors.
• Collaboration: Breaking down silos between development and operations teams through
shared communication and tools.
• Version Control: Using systems like Git to manage code changes and enable
collaboration.
• Infrastructure as Code: Managing and provisioning infrastructure through code to
ensure consistency and automation

DevOps architecture
• DevOps architecture is a framework that mixes development and operations practices. It
helps us create a smoother, more cooperative, and efficient way to deliver software.
DevOps Lifecycle

The DevOps lifecycle is a structured approach that integrates development (Dev) and operations
(Ops) teams to streamline software delivery. It focuses on collaboration, automation, and
continuous feedback across key phases planning, coding, building, testing, releasing, deploying,
operating, and monitoring executed in a continuous loop.
• Planning and Design − We define the needs and plan the solution.
• Development − This is where we code, control versions, and run automated tests.
• Deployment − We use continuous integration and delivery. We also handle infrastructure
as code.
• Operations − Here, we monitor, manage issues, and improve performance.
• Feedback − We make things better with regular feedback from metrics and users.
• Plan: In this stage, teams identify the business requirement and collect end-user
feedback. They create a project roadmap to maximize the business value and deliver the
desired product during this stage.
• Code: The code development takes place at this stage. The development teams use some
tools and plugins like Git to streamline the development process, which helps them avoid
security flaws and lousy coding practices.
• 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: The build is ready to deploy on the production environment at this phase. 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.
• 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.
• Monitor: In this stage, the DevOps pipeline is monitored based on data collected from
customer behavior, application performance, etc. Monitoring the entire environment
helps teams find the bottlenecks impacting the development and operations teams’
productivity.

DevOps Workflow
DevOps workflow refers to a structured sequence of tools and practices. These are crafted to
automate and integrate the processes between IT operations and software development team. It
shortens the development lifecycle to continuously deliver top-quality software. This ensures
uninterrupted collaboration across teams.
Key Components of DevOps Workflow
Following are the key components of DevOps Workflow-
1. Source Code Management
• This includes maintaining a repository to store and manage code. Developers can easily
track changes, manage version control and collaborate. Top tools used here are GitHub,
Git, Bitbucket and GitLab. It helps in providing version history, facilitating collaboration
and ensuring code integrity.
2. Continuous Integration For DevOps Workflow
• CI includes integrating code changes automatically from various contributors into a
single shared repository many times a day. Issues are detected early by running
automated tests. Top tools used for this are Travis CI, Jenkins and CircleCI. It helps in
faster feedback cycles, consistent build quality and early detection of integration issues.

3. Automated Testing
• Automated tests verify the performance, security and functionality of the code. These
tests can be integration tests, end-to-end tests or unit tests. Top tools used here are
JUnit, Selenium and TestNG. Top benefits include reduced manual testing efforts,
ensuring consistent quality, and accelerating the development process.
4. Continuous Deployment
• Continuous deployment helps in automating the process around deploying code changes
for production. It facilitates changes that pass the automated tests to automatically get
deployed to the production environment. Top tools are Docker, Kubernetes and Ansible.
Its key benefits are reduced deployment errors risk, immediate availability of new
features and faster releases
5. DevOps WorkFlow For Configuration Management
• It is about managing and automating the configuration of software and systems. This
ensures that all the environments are consistent. Top tools are Puppet, Chef and Ansible.
Top benefits are reduced configuration errors, easier scaling and consistent environments.
6. Monitoring & Logging
• This component continuously monitors the health and performance of infrastructure and
applications. Logs are collected to be analyzed for identification of issues and
improvement in system reliability. Top tools are Grafana, Prometheus and ELK Stack.
 Key benefits are improved system performance, better user experience and proactive
issue detection.
7. Collaboration & Communication
• Effective collaboration and communication among team members is extremely crucial.
Different tools help in video conferencing, chat and issue tracking. Top tools used here
include Microsoft Teams, Slack and Jira. Some of the key benefits are faster decision-
making, enhanced transparency and enhanced team coordination.
The DevOps workflow automates and integrates the processes between the departments of
development and operations. This promotes continuous integration, continuous delivery and
collaboration. It uses tools and practices to help organizations achieve higher quality software,
enhanced operational efficiency and faster releases.

DevOps Workflow Tools Set

Core Principles of DevOps

• Collaboration & Communication: DevOps promotes regular communication, short
meetings, and collaboration between the teams. No group is allowed to ‘throw code over
the wall’; everyone pays for stability and timely delivery. This is because it promotes
high morale among the employees and reduces internal bureaucracy.
• Automation & Continuous Processes: Scripts and infrastructure automation are used
instead of manual processes and pipelines, such as CI/CD and IaC. Automation of tests
and the environment helps to save iteration time and have the same result each time.
Relieving teams from monotonous work allows them to think creatively and work on
actual problems.
• Continuous Feedback & Improvement: Every release or environment update produces
logs, metrics, and feedback from the users. It is integrated into the following sprints,
improving the DevOps pipeline. This makes the solutions to be dynamic, always
changing with the user needs or new technologies in place.
• Shared Responsibility & Ownership: In DevOps, both development and operations
teams are involved in the development process throughout the SDLC. This means that
 people are involved in the development phase, implementation phase, and even the
maintenance phase, and this makes everyone have ownership of the project.

Introduction to DevOps tools

DevOps Tools: Building the Modern Pipeline
The DevOps ecosystem thrives on automation.

1. Plan – Work Planning & Prioritization

• Define what needs to be built: features, bug fixes, enhancements.

• Use Agile frameworks (Scrum or Kanban) to plan sprints or workflows.
• Stakeholders, Product Owners, and developers collaborate.
• Keeps teams aligned.

• Breaks complex goals into manageable tasks.

• Helps respond quickly to changes in requirements.

Tools: Jira, Trello, Azure Boards, ClickUp

Example: You plan a new feature: “Customers can track order status.”

2. Develop – Code Creation & Version Control

• Developers write code locally and commit to a Git repository.

• Feature branches are used to avoid disrupting the main codebase.
• Pull/Merge Requests are created for peer review and collaboration.

• Ensures teamwork without overwriting each other's code.

• Every change is tracked and reversible.
• Enables collaboration and faster debugging.

Tools: Git, GitHub, GitLab, Bitbucket, VS Code

Example: Developer adds a new “Track My Order” screen and commits code.

3. Build – Compiling and Packaging the Code

• Source code is automatically compiled into an executable or deployable package.

• Dependencies are resolved.
• Artifacts (e.g., Docker images, .jar files) are generated.

Tools: Jenkins, GitHub Actions, GitLab CI, Maven, Gradle, Docker

 • Catches build errors early.
• Saves time by automating packaging.
• Creates consistent, reliable builds.

Example: Jenkins compiles the app and creates a Docker container with the new feature.

4. Test – Quality Assurance Through Automation

• Run automated tests after build to ensure code works correctly.
• Test types: Unit, Integration, Functional, UI, Security
• Tests run in parallel for speed.

Tools: Selenium, JUnit, Postman, SonarQube, Cypress

• Prevents bugs from going live.

• Makes testing faster and repeatable.
• Ensures code meets quality standards.

Example: A Selenium test simulates a user checking order status to confirm it works.

5. Release – Prepare S Approve the Deployment

• Code is marked as a candidate for production release.

• Often reviewed and signed off by QA or managers.
• Artifacts are versioned and stored in repositories.

Tools: Nexus, Artifactory, Azure Release Pipelines

• Controls what goes to production.

• Allows rollback to previous versions.
• Ensures only tested, approved code is released.

Example: Release manager tags version v1.4of the app and marks it for deployment.

6. Deploy – Push Code to Production

• Release is automatically deployed to production servers/cloud.
• Strategies used: Blue-Green, Canary, Rolling
• Infrastructure-as-Code ensures consistent environments.

Tools: Ansible, AWS CodeDeploy, ArgoCD, Terraform, Kubernetes

• Reduces downtime.
• Eliminates manual deployment errors.
• Enables frequent, safe delivery.

Example: Code is deployed to a small % of users first (canary), then to all.

 7. Monitor – Observe & Optimize in Real-Time

• Application is monitored for health, performance, and usage.

• Set up alerts for failures, high CPU, or user drop-off.
• Real-time data is collected to inform future improvements.

Tools: Prometheus, Grafana, New Relic, ELK Stack, Datadog

• Detects problems early.

• Improves user satisfaction.
• Feeds data back into the planning stage.

Example: You spot a sudden drop in “Track Order” feature usage, and investigate a bug.

Here’s a breakdown of some popular DevOps tools by category:

Stage Tools

Version Control Git, GitHub, GitLab

CI/CD Jenkins, CircleCI, Travis CI

Configuration Management Ansible, Puppet, Chef

Containerization Docker, Kubernetes

Monitoring & Logging Prometheus, Grafana, ELK Stack, Splunk

Security (DevSecOps) SonarQube, Snyk, Aqua Security

Real-Time Examples
1. WhatsApp

• Roll out new features like "View Once" with zero downtime
• Monitor delivery speed, crash reports
• Fix bugs and deploy in minutes using CI/CD

2. Amazon

• Releases code every 11.6 seconds

• Thousands of developers working together using Git, Jenkins, AWS

3. Uber/Ola

• New fare rules? Change backend code.

• New UI for users? Change frontend.
• Deploy both changes using DevOps pipeline automatically
 Imagine Netflix:

• Developers work on features like movie recommendations.

• Using DevOps tools, they:
o Write and test code automatically
o Deploy it to millions of users quickly
o Monitor the system for errors in real-time
• If a bug is found, it's fixed within minutes, not weeks.

That’s DevOps in action — fast, efficient, reliable.

Benefits of DevOps

• Faster time to market

• Better quality (thanks to automated testing)
• Stronger team collaboration
• Rapid feedback and improvement
• Fewer failures and faster recovery

Build Automation
Build automation in DevOps refers to the process of automating the compilation, testing, and
deployment of software applications.
It is a crucial aspect of modern software development that aims to streamline the development
lifecycle, enhancing collaboration, and ensuring reliable deployments and improve efficiency.
Build automation is a sophisticated approach to controlling and managing builds within a CI/CD
pipeline with multiple steps.
key reasons for Importance of Build Automation
 Time-Saving
• Build automation eliminates repetitive manual tasks like compiling, testing, and
packaging code, allowing developers to focus on more strategic aspects of software
development and speeding up the build cycle.
 Consistency
• Automated processes ensure every build follows a standardized procedure, reducing the
risk of errors caused by manual intervention and maintaining uniformity across builds.
 Faster Feedback
• With build automation, developers receive instant feedback on code changes, enabling
them to identify and fix issues before they escalate quickly.
 Code Quality
• Incorporating unit tests, integration tests, and other quality checks into the build process
improves code quality by detecting bugs and regressions early.
 Automated Deployments
• Build automation integrates with deployment pipelines, facilitating faster, error-free
software releases. Automated deployments ensure consistent results across environments.
 Scalability
• Manual processes need to be more efficient as projects and teams grow. Build automation
scales quickly, adapting to projects’ increasing complexity and size without adding
overhead.
 Auditability and Documentation
• Automated builds generate detailed records of the build process, including version
control history, dependencies, and configurations. This audit trail is valuable for
troubleshooting, replicating builds, or meeting compliance requirements.
 Enhanced Collaboration
• Automated builds create a standardized framework, ensuring all team members work
with the same codebase and artifacts. This consistency fosters smoother collaboration
across teams.
 Resource Optimization
• Build automation can schedule tasks during non-working hours, optimizing resource
usage and minimizing disruptions to the development workflow.
 Improved Time-to-Market
• Build automation shortens development cycles by reducing errors, streamlining
processes, and enabling faster feedback. This allows teams to deliver software more
quickly.
•
How does Build Automation work
• The build automation process uses tools, scripts, and workflows to automate the tasks
required to build and deploy software efficiently.
overview of the build automation workflow:
• Code Commit to Repository: Developers commit updated code to a Version Control
System (VCS) like GitHub, GitLab, or Bitbucket. These platforms manage software
updates and track code changes.
• CI Server Detects Changes: A Continuous Integration server monitors the repository for
new commits. It updates its database and prepares for the next steps when changes are
detected.
• Build Configuration Triggers Build Agent: A build configuration defines the build
process, including triggers like new commits, scheduled times, or post-scan completions.
When triggered, it activates build agents to execute tasks.
• Build Agents Activate Build Tools: Build agents, installed on dedicated servers, follow
commands from the CI server. They coordinate tasks such as compiling code, generating
installers, or compressing data using predefined configurations.
• Executing Build Tasks: Build tools like Maven, Gradle, or others handle tasks such as
compiling code, running tests (e.g., unit tests), and compressing files. These tools are
optimized for specific programming languages and automate the low-level work.
• Build Artifacts Sent to CI Server: If all stages pass, the build artifacts—executable files
or binaries—are returned to the CI server. They may then be deployed, undergo further
testing, or stored as part of the CI/CD pipeline.

Key Components of a Build Automation System

• A Build Automation system streamlines the development process by automating key
tasks.
Here are its essential components:
• Track code changes and trigger builds using tools like Git or SVN.
• Define build steps with scripts created in Maven, Gradle, or Bash.
• Automate build processes with CI tools like Jenkins or Travis CI.
• Execute builds across environments using build agents for scalability.
• Ensure code quality with testing frameworks like JUnit or Pytest.
• Store build outputs in artifact repositories for easy access and deployment.
• Get real-time build status updates through notification systems.
• Automate artifact delivery to production using tools like Docker or Ansible.
How to Automate the Build Process?
• Quality assurance to Quality engineering and Testing are significant parts of the Software
Development Life Cycle.
Here is how to Automate the Build Procedure:
• Write the code.
• Commit code to a shared, central repository.
• Scan the code utilizing tools.
• Start a source code review.
• Accumulate code & files.
• Run test automation.
• Notify contributors to mitigate issues.

Role of CI in the Automated Build Process

• The automated build process allows CI (Continuous Integration). So, the role of CI in the
build automation process is that CI uses build automation to verify check-ins and allow
teams to identify issues early.
• Due to its relationship with CI, build automation also makes CT (Continuous
Testing) and CD (Continuous Delivery) possible.

Popular Build Automation Tools

• CI Tools (Execute Build Automation)

These tools run the build scripts:

• Jenkins
• GitHub Actions
• GitLab CI
• Azure DevOps
• CircleCI
• Travis CI

Build Automation Workflow (Step-by-Step)

Below is a typical DevOps build pipeline:
 Step 1: Developer pushes code to Git
Commit → Push → Trigger CI pipeline.
 Step 2: CI Tool Starts Build Job
Jenkins/GitLab CI pulls code.
 Step 3: Build Script Runs
Example in Maven:
mvn clean install
 Step 4: Run Automated Tests
JUnit, Selenium, PyTest, Jest etc.
 Step 5: Package Artifact
Example outputs:
[Link]
[Link]
Docker image
 Step 6: Push Artifact to Repository
Nexus
Artifactory
Docker Hub
 Step 7: Notify Developers
Success or failure reports via: Email, Slack, Teams
Delivery Automation
• Delivery Automation is the automated process of packaging, testing, and deploying
software changes from development to production environments without manual
intervention.
• It is the automated process of delivering, deploying, and releasing software into different
environments using CI/CD pipelines and DevOps tools.
• It includes automated packaging, testing, environment provisioning, deployment
strategies, and monitoring.
It ensures:
• Faster delivery of features
• Fewer deployment errors
• Predictable & repeatable releases
• It is a major part of the CI/CD pipeline, specifically focusing on Continuous Delivery
(CD) and Continuous Deployment.

Stages of Delivery Automation

Stage 1: Build Packaging Automation

Stage 2: Automated Testing Pipeline
Stage 3: Automated Environment Provisioning
Stage 4: Deployment Automation
Stage 5: Configuration & Secrets Management
Stage 6: Automated Release Management
Stage 7: Post-Deployment Monitoring & Feedback

Tools Used in Delivery Automation (Full List)

CI/CD Tools
• Jenkins
• GitLab CI
• GitHub Actions
• CircleCI
• Azure DevOps

Understanding Code Quality

Code Quality in DevOps refers to how good, clean, maintainable, secure, and efficient the
code is throughout the DevOps lifecycle.
It ensures that software is reliable, scalable, free from bugs, and easy to modify.
Why Code Quality Is Important in DevOps?
• 1. Faster Delivery
High-quality code reduces bugs → fewer delays → faster CI/CD pipeline executions.
• 2. Improved Collaboration
Readable code makes developers + testers + ops work smoothly.
• 3. Reduced Technical Debt
Clean code avoids extra future work and rework.
• 4. Better User Experience
Stable, bug-free releases → higher customer satisfaction.
• 5. Automation-Friendly
CI/CD depends on automated testing, linting, builds → good code makes automation
effective.
 Key Components of Code Quality in DevOps

1. Code Readability
Easy to read and understand
Meaningful variable/function names
Consistent formatting
2. Code Maintainability
Easy to update/modify
Modular functions
Follows coding standards
3. Reliability
Works correctly under all conditions
Verified through automated tests
4. Performance
Efficient memory and CPU usage
No unnecessary loops, complex logic
5. Security
No vulnerabilities
Secure coding practices
Security scanning (SAST/DAST)
6. Testability
Code structured for unit testing
High test coverage

Code Quality in the DevOps Lifecycle

DevOps Stage Code Quality Activities
Plan Define coding standards, architecture guidelines

Develop Linting, code reviews, unit tests

Build Automated build + static analysis

Test Integration testing, regression testing, security testing

Release Ensure passed quality gates

Deploy Monitor errors and rollbacks
Operate Log monitoring, bug tracking
Feedback Improve standards continuously

Popular DevOps Tools for Code Quality

Purpose Tools
Static Analysis SonarQube, ESLint, Pylint
Code Review GitHub, GitLab, Bitbucket
Automated Testing Jenkins, GitHub Actions, CircleCI
Security Scanning Snyk, OWASP ZAP
Automation of CI/ CD
 CI/CD stands for Continuous Integration and Continuous Deployment (or Delivery).
CI/CD is a software delivery concept and a core aspect of DevOps that automates
multiple stages within the DevOps workflow.
 While CI helps you with building and testing, CD helps you deploy your applications and
services to the target environment.
Automation of CI/CD means automating the entire software delivery process — from coding
→ building → testing → deploying — without manual intervention.

1. What is Continuous Integration (CI)?

• Continuous Integration automates:
• Code merging from developers
• Code building
• Running automated tests
• Detecting bugs early
Automated CI workflow:
• Developer pushes code to Git (GitHub/GitLab/Bitbucket)
• CI tool triggers automatically (Jenkins, GitHub Actions, GitLab CI)
• Code is built automatically
• Unit tests and code quality checks run
• Feedback is sent to the developer
• CI ensures the code is always in a working state.

2. What is Continuous Delivery (CD)?

Continuous Delivery (CD) is a DevOps practice where:

Software is always in a release-ready state.

 This means:

• Code is tested automatically.

• It can be released anytime — with the click of a button.
• There is no need for manual, risky deployments.
• CD = Code → Test → Ready for Release (automated)

Continuous Delivery automates:

• Packaging the software
• Preparing deployment artifacts
• Running advanced tests (integration, performance)
• In Continuous Delivery, deployment to production is manual, but everything before
it is automated.

How Continuous Delivery Works

1. Developers commit code to Git.
2. A CI/CD pipeline:
o Builds it automatically
o Tests it automatically
o Packages it for release
3. The team decides when to release (it’s ready anytime).
4. In Continuous Deployment (the next level), code is automatically released without
even clicking a button.

Tools for Continuous Delivery

Tool Purpose

Jenkins, GitLab CI Automate builds and tests

Docker Package apps into containers for deployment

Kubernetes Run and manage those containers

Spinnaker, ArgoCD Control deployment pipelines

Benefits of Continuous Delivery

• Faster Releases: Features reach users quicker.

• Lower Risk: Smaller updates are easier to test and fix.
• Higher Quality: Automated testing means fewer bugs.
• Better Feedback: Real user responses arrive quickly.

3. What is Continuous Deployment?

• Continuous Deployment means:
• Every code change that passes tests is automatically deployed to production.
• No human approval required.
• It is the fully automated form of CD.
Components in CI/CD Automation

a. Source Code Management (SCM)

GitHub, GitLab, Bitbucket
b. Build Automation
Maven, Gradle, npm, Ant
c. CI Tools
Jenkins
GitHub Actions
GitLab CI/CD
CircleCI
d. Testing Automation
JUnit, Selenium, PyTest
e. Artifact Repository
Nexus
JFrog Artifactory
Docker Hub
f. Deployment Automation (CD tools)
Jenkins
ArgoCD
Spinnaker
Octopus Deploy

Automated CI/CD Pipeline Flow (Step-by-Step)

Step 1: Developer commits code

Triggers CI pipeline automatically
Step 2: Build Stage
Code compiled
Dependencies installed
Step 3: Automated Testing
Unit tests
Integration tests
Code quality (SonarQube)
Step 4: Artifact Packaging
.jar, .war, Docker image created
Step 5: Push to Artifact Repository
Step 6: Deployment Automation
Deploy to:
Dev
QA
Staging
Production
Step 7: Monitoring & Feedback
Monitoring tools:
Prometheus
Grafana
ELK
Example CI/CD Pipeline Tools Combination
Stage Tools
SCM GitHub
CI Jenkins or GitHub Actions
Build Maven/Gradle
Code Quality SonarQube
Artifact Store DockerHub/Nexus
CD Jenkins/ArgoCD/Kubernetes
Monitoring Prometheus & Grafana
Benefits of CI/CD Automation
• Reduces manual errors
• Faster releases
• Higher code quality
• Early bug detection
• Consistent and reliable deployments
• Improves developer productivity

Release Management
• Release Management is a critical process that oversees the planning, coordination,
testing, and deployment of software releases from development to production
environments.
Goals of Release Management in DevOps
• The goals of Release Management in DevOps services are focused on reducing risk,
increasing efficiency, and enhancing collaboration between development and operations
teams.
To ensure:
• Software is released smoothly and on time
• It works correctly in the live environment
• It causes no disruption to users or services..
Benefits of Release Management for DevOps
• Improved reliability and stability of software releases by identifying and fixing bugs,
reducing errors, and ensuring consistent performance across different environments.
• Increased collaboration between development and operations teams, enabling faster
feedback loops, and better communication and coordination between teams.
• Faster time to market by streamlining the software delivery pipeline, reducing manual
processes, and automating testing and deployment.
• Enhanced customer satisfaction by delivering high-quality software releases that meet
customer needs and expectations.
• Cost savings and greater efficiency by reducing downtime, minimizing errors, and
optimizing resource utilization.
Types of Software Releases
Type Description Example

Major Release Big changes, new features Windows 11

Minor Release Small improvements Added dark mode to app

Patch Release Bug fixes or security updates Fix login crash

Emergency Release Urgent fix due to system failure Patch after system outage
Controlled vs. Continuous Releases
Type Description
Traditional (Controlled) Release is planned, reviewed, approved step by step
DevOps / Agile (Continuous) Automated, frequent, small releases (often daily or hourly)
NOTE: DevOps focuses on Continuous Delivery and frequent releases

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

Key Activities in Release Management:

Step What Happens Example

Plan the Release Decide what to include & when to release Let’s release login and profile update
features next week

Build & Package Bundle all code, config, and files Code is compiled into an app versio
together

Test the Release Make sure it works, doesn't QA tests it in staging environment
break anything

Schedule Set a date/time for going live “We’ll deploy on Saturday at 2 AM to avoid user
Deployment disruption.”

Deploy the Push to production systems New version goes live for all users
Release

Monitor and Check for issues, be ready to If there’s a bug, roll back or fix immediately
Support rollback
Scrum
• Scrum is a management framework that teams use to self-organize tasks and work
towards a common goal. It is a framework within which people can address complex
adaptive problems while the productivity and creativity of delivering products are at the
highest possible value.
• Scrum is used because it makes software development faster, more flexible, more
organized, and more customer-focused.
• The Scrum framework is a simple, agile way to manage projects that helps teams work
together to create high-quality products quickly.
• Scrum allows us to develop products of the highest value while making sure that we
maintain creativity and productivity.
• The iterative and incremental approach used in scrum allows the teams to adapt to the
changing requirements.
Scrum = How teams plan & build software
DevOps = How software is built, tested, delivered, and maintained
Many modern organizations use Scrum + DevOps together:
• Development happens in sprints (Scrum)
• Deployment happens continuously with automation (DevOps)

Scrum = Agile project management approach

DevOps = Culture + tools to deliver software continuously

Basic components and principles of Scrum

Scrum Team
 Product Owner: Decides what the team should work on and makes sure it meets
business and customer needs.
 Scrum Master: Helps the team follow Scrum rules and removes any obstacles they face.
 Development Team: A group of people with different skills who work together to build
the product.
Artifacts:
 Product Backlog: A list of everything that needs to be done for the product, organized
by priority.
 Sprint Backlog: A list of tasks the team plans to complete during the current sprint.
 Increment: The finished work at the end of a sprint that could be released to users.
Events:
 Sprint: A short, fixed period (usually 1-4 weeks) where the team works on specific tasks
from the sprint backlog.
 Sprint Planning: A meeting at the start of the sprint where the team decides what to
work on.
 Daily Scrum: A quick daily meeting where the team checks in on progress and plans the
day's work.
 Sprint Review: A meeting at the end of the sprint where the team shows what they’ve
accomplished and gets feedback.
 Sprint Retrospective: A meeting at the end of the sprint where the team discusses what
went well and what could be improved for the next sprint
What are Sprints in Scrum?
• Whenever we build projects or products we do it in series of repetitions and these
repetitions are known as sprint, sprint helps the developers of the project to build
projects with higher productivity and functional. sprints are just a series of steps involved
in a time-frame or duration that deals with the overall development of the product.
• The sprint also allows us to adapt to the changes more faster and quickly.
• The sprint helps creators and developers to build products faster.
• The sprint is a series or cycle to break down the tasks.

Sprint Process

What is Sprint Process?

• Step 1: The scrum cycle is a complete cycle of product development which starts with
the Product Owner, the product owner defines all the product backlog and requirements
for further development.
 • Step 2: The next step is handled by the scrum team and the scrum team manages
the Sprint Planning in the sprint planning phase the team plans all the tasks and roles for
the development of the product.
• Step 3: Then in the next phase the team deals with the sprint backlogs which are due and
deals accordingly with all the backlogs left.
• Step 4: As we know the scrum master is someone who overseas all the tasks of the team
and acts as a mentor for the team, so in this step the scrum master overseas and
collaborates with the team to make sure the product is ready on time, this cycle typically
lasts from 1 to 4 weeks but depending on the project size it varies a lot, which is why
sometimes for larger projects, it's also divided into smaller part known as Daily Scrum.
• Step 5: This is the final process stage, in this stage the team integrates all the modules of
the project and tests the various components of the product.

Why to Use Scrum?

Benefit Description
 Faster delivery Working features delivered regularly
 Flexibility Easy to adapt to changes
 Team collaboration Everyone communicates daily
 Transparency Everyone knows what’s going on
 Continuous improvement Team gets better over time

Kanban
What is 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.
• Kanban is a visual workflow management method used in DevOps, software
development, and project management.
• It helps teams see work, limit work-in-progress (WIP), improve flow, and deliver
faster.

Purpose of Kanban

Kanban helps teams:

• Visualize their work

• Limit how much work is in progress
• Identify bottlenecks
• Improve efficiency over time

It’s not just a tool — it’s a method for managing flow and improving continuously.
Components of Kanban in Detail
1. Kanban Board

A Kanban board is the main workspace. It has columns that represent different stages of work. (You
can create more stages to reflect your real workflow.)

Common columns:
Column Name Meaning
 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) Limits

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.
Example:

• WIP Limit for "In Progress" = 3

• If 3 tasks are already in progress, no one can start a new task until one is moved to
“Done”

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 S Improvement

Teams often use flow-based metrics to improve performance:

Metric Meaning

Lead Time Time from task added → to task done

Cycle Time Time from task started → to task done

Throughput Number of tasks completed per day/week

Cumulative Flow Diagram (CFD) Shows how tasks are moving over time

➡ Teams review these to find and fix bottlenecks (where tasks pile up or slow down).

Kanban Team Roles

Unlike Scrum, Kanban does not define fixed roles like Scrum Master or Product Owner.

Instead:

• Teams self-organize
• Everyone shares responsibility
• Leadership roles are flexible

Kanban Workflow
• The Kanban Workflow is composed of four Phases. The tasks are managed and
organized in these 4 columns over the Kanban board during the entire development
phase.
• The user stories are written on sticky notes, which are later pushed to their respective
columns as per the current status of the tasks.
• The Kanban Board could either be a Physical board which includes whiteboards and
sticky notes or a Digital Kanban Board which allows the team to track multiple
workflows at the same time.

4 Workflow Phases in Kanban:

• To-Do: The workflow is started with an empty clear board where all the tasks are meant
to be listed. A To-Do list is formed in the first column of the board which consists of all
 the user stories. The individual cards must provide a brief description and necessary
details of tasks like due date, functionalities, nature of task, etc.
• In-Progress: As the name suggests, the In-Progress column consists of all the tasks that
are currently under progress and under development phase. It acts as an indication that a
team is currently operating working on it.
• Validation: In the validation phase, the code is reviewed, and the model is tested against
several sets of tests like unit testing, acceptance testing, system testing, etc. All the
functionalities are reviewed and verified. Apart from this, all the bugs and
inconsistencies found are rectified in the validation phase itself.
• Done: After all the functional and system tests are performed and quality assurance is
reviewed, the task is shifted to Done state (4th column on the board). All the tasks move
column to column towards right until they reach the last column i.e. Done phase. The
done column reflects all the tasks that are finished and deployed without any errors.
Kanban Principles
• Kanban methodology is based on Lean Development approach.
• Kanban is composed of 4 major principles:
 Start with the existing process:
 Agree to continue evolutionary and incremental changes:
 Admire current roles, processes, responsibilities & titles:
 Leadership at all levels:

Key Principles of Kanban

• Visualize the work
 Use a Kanban board (physical or digital)
 Columns like: To Do → In Progress → Testing → Done

• Limit Work-In-Progress (WIP)

 Prevents overload
 Ensures smooth flow
 Improves focus
• Manage Flow
 Track how work moves from start to finish
 Identify bottlenecks

• Make Policies Explicit

– Define clear rules

(e.g., only 2 items allowed in “In Progress”)

• Implement Feedback Loops

 Daily standups
 Review meetings
• Improve Continuously
 Optimize workflow based on metrics
 Encourage small, continuous improvements
Steps of Kanban Approach
• The Kanban approach involves three steps:
Step 1. Visualize: This step involves defining and visualizing the workflow.
 Understand the need for improvement.
 Define the process.
 Value stream entire process flow.
 Visualize process flow.
Step 2. Quantify: This step involves three activities:
• Startup:
 Understand and/ or estimate WIP.
 Create initial WIP limits.
• Adjust:
 Study the feasibility of WIP limits.
 Adjust the limits if required.
 Develop statements on the limits and policies.
 Train the team on a pilot basis.

• Measure:
 Define current problems.
 Convert them to measurements.
 Derive metrics.
 Establish a metrics collection system.
 Define the tools used to analyze metrics and data.
Step 3. Optimize: This step involves the following three activities-
• Identify and Improve:
 Analyze data.
 Establish future value stream.
 Identify improvement opportunities.
 Prioritize.
 Develop action plans.
 Implement action plans.
 Ensure improvement.
• Establish standards:
 Revisit limits and policies.
 Train the team.
 Implement a new process.
• Envision for continuous improvement:
 Set up the system to continuously monitor and improve processes.
 Make the process, process-driven rather people-driven.

Kanban – Benefits
 Improves workflow visibility with boards
 Reduces bottlenecks and waiting time
 Increases productivity and efficiency
 Enables continuous delivery & quick response to change
 Enhances team collaboration and communication
 Supports better prioritization and focus
 Simple to implement and flexible to scale
Delivery Pipelines
• It is a series of automated steps that all the code changes go through from development to
production. This pipeline consists of a series of interconnected stages, each performing a
specific task. The delivery pipeline is used to build, test, and run software developments.

Stages of Delivery Pipelines

• A delivery pipeline has four main stages, all of which are explained in the simplest form
below.

• Create: In the first stage of the process of delivery pipelines, the developers write and
upload the code to a platform like GitHub. GitHub is a shared platform where everyone,
including developers, the operations team, and testers, can work together. This also
reduces the chances of errors.

• Build: The next step is to build the product. For example, the given code was for an
application development. So, the system will now take in the code, process it, and will
bring it together into a working product.

• Test: No software or update can be rolled out for public until and unless it is thoroughly
checked by the professionals. In the process of delivery pipelines, automated tests are run
to check if everything is fine and smooth in the software or not.

• Deploy: If all the tests are passed, the software is delivered. It may be deployed only for
testing purposes in the beginning or it may be directly released for the users. This depends
on the company and the type of software or update that has been created.

Delivery Pipeline Diagram:

Types of Delivery Pipelines

There are mainly three types of Delivery Pipelines. It includes Continuous Integration,
Continuous Delivery, and Continuous Deployment.
 Term Meaning

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

Continuous Integration (CI)

Continuous Integration Tools is the first automated step. Whenever a developer makes a
change in the code or writes a new code, the system automatically performs tests and checks to
ensure nothing is wrong and everything is working fine.
• It helps to detect errors or bugs in the early stages, which eventually helps in preventing
them before they cause any damage to the software or the data.
• Tools used: Jenkins, GitHub Actions

Continuous Delivery (CD)

• If no bugs or errors are found and the testing turns out to be successful, then the system
prepares the code to be released. Only the first release of a software requires manual
approval, rest everything is automated, which saves time and effort.
Tools used
• The following tools are used in the process of continuous delivery. Have a look.
• AWS CodePipeline
• Azure DevOps, etc.

Continuous Deployment
• Now, this is a completely automated step. Even when the developers make a slight
change to the code, it is automatically sent for testing by the system. And once the tests
are successful, the update is automatically deployed to the users.
• No human approval is required for this process, which helps in the faster completion of
the process with minimal chances of errors. This is used by most of the big tech
companies for releasing quick and frequent updates.
Tools used
• As this is an automated process, the tools used for the continuous deployment are:
• Argo CD
• GitHub Actions
• Tekton, etc.

Benefits of a Delivery Pipeline in DevOps

 Frequent updates and Fast releases
 Saves time
 Improved Quality
 Less Manual Work
 Instant feedback
 Enhanced Team Collaboration
 Enhanced reliability
 Identifying Bottlenecks
Bottlenecks are stages in the development process that slow down overall progress. These can
be caused by delayed approvals, long testing cycles, unbalanced workloads, or manual
processes. Identifying and eliminating bottlenecks is crucial for maintaining flow and
delivering software efficiently. Tools like burndown charts, Kanban metrics, and retrospectives
help in spotting such delays.

What is a Bottleneck in DevOps?

A bottleneck is the slowest or most overloaded part of the DevOps pipeline that limits the
flow of work.
Just like water in a bottle can only flow as fast as the narrow neck allows, in DevOps, the
entire release speed depends on the slowest stage
DevOps can encounter various bottlenecks that impede its effectiveness.
• Lack of Communication and Collaboration
• Slow and Inefficient Testing Processes
• Infrastructure Provisioning Delays
• Lack of Standardization and Configuration Management
• Problems with Deployment and Release Management
• Inadequate Monitoring and Observability
• Cultural Resistance to Change

The DevOps Pipeline – Overview

• Plan → Code → Build → Test → Release → Deploy → Monitor → Feedback
•
• Each of these phases can contain one or more bottlenecks.

Where Bottlenecks Can Appear & How to Spot Them

Phase Possible Bottlenecks Symptoms
Plan Unclear requirements, delayed approvals Developers waiting for direction
Code Overloaded developers, poor branching strategy Code stuck in local machines, merge conflicts

Build Slow build tools, no caching, overloaded runners Long CI build times, timeout errors

Test Manual testing, flaky automated tests Releases delayed due to QA, false test failures

Release Waiting for release approvals or sign-off Features done but not released

Deploy Manual deployments, fragile scripts High downtime, rollback delays

Monitor Lack of logs, no alerts Bugs discovered late, poor user experience

Feedback No feedback loop from users or monitoring tools Teams don’t know if release was successful
How to Identify Bottlenecks (Step-by-Step)

1. Use Value Stream Mapping (VSM)

• Create a visual flow of the entire software delivery pipeline.
• Track: Time spent on each stage
Idle/wait times (handoffs, approvals)
Rework loops (code sent back for fixes)
• Tools: Whiteboard, Lucidchart, Miro
 2. Collect Metrics with DevOps Tools

Use metrics from your CI/CD tools to monitor stage performance:

Tool Metric Example

 Jenkins Stage duration, build failures
 GitLab CI Pipeline duration, manual job waiting times
 Azure DevOps Deployment time, success rate
 SonarQube Code quality issues blocking progress
 Prometheus + Grafana System resource bottlenecks (CPU, I/O)
3. Analyze Queues and Wait Times

Ask:

• Which stage has backlogs?

• Are people waiting for approvals or test results?
• Is deployment blocked by one person’s availability?

4. Talk to the Team

Sometimes data doesn’t show everything. Ask:

• “Which part slows you down the most?”

• “Where do you wait for others?”
• “What do you do when blocked?”

These are often the real-world indicators of bottlenecks.

How to Fix Bottlenecks

Bottleneck Solution
 Manual testing Implement Automated Testing (Unit, Integration, UI)
 Slow builds Use caching, parallel jobs, Docker layers
 Approval delays Automate low-risk changes with policies
 Fragile deployments Use Infrastructure as Code, Blue-Green Deploy
 No feedback Add APM tools (Datadog, New Relic, Prometheus)

Tools to Help Identify Bottlenecks

Tool Purpose
 Jenkins/GitHub Actions Track build/test time
 Dynatrace, New Relic Monitor performance bottlenecks
 SonarQube Detect code quality issues
 Miro/Lucidchart Create value stream maps
 Promethus+Grafana Infrastructure monitorin
Examples:
Agile Real-World Example: Building a Food Delivery App
Let’s say we’re building a food delivery app.

Backlog:

• User login
• Browse restaurants
• Add food to cart
• Make payment
• Track delivery

Sprint 1 (2 weeks):

• Build login screen

• Make login work with email/password
• Show it to the customer for feedback
Customer says: “Great! But I also want Google login.”

So in Sprint 2, we:

• Add Google login

• Start building restaurant list

This continues until the full app is ready, step by step, with constant feedback.

Real-World Example of DevOps

Imagine Netflix:

• Developers work on features like movie recommendations.

• Using DevOps tools, they:
o Write and test code automatically
o Deploy it to millions of users quickly
o Monitor the system for errors in real-time
• If a bug is found, it's fixed within minutes, not weeks.

o That’s DevOps in action — fast, efficient, reliable

o
Real-World Example of Continuous Delivery : Mobile Banking App

Step DevOps Process CD in Action

Day 1 Developer writes a feature: “check balance by voice Code is committed to Git

Day 2 Automated build and testing run If tests pass, code is marked “ready to release”

Day 3 Manager clicks “deploy” → Feature goes live All users see the new feature instantly
Release Management Example: Releasing a New Feature in a Banking App

• Plan: Add “Scan to Pay” feature.

• Build: Developers create and package the code.
• Test: QA team tests functionality and security.
• Schedule: Decide to release during a low-traffic window (Sunday night).
• Deploy: IT team deploys it using tools like Jenkins or GitHub Actions.
• Monitor: They check system health and watch for bugs.

Scrum Simple Example: Building a School Website

Let’s say your class is building a school website:

Product Backlog:

• Create homepage
• Add photo gallery
• Add timetable section
• Contact form

Sprint 1 (2 weeks):

• Build homepage
• Add photo gallery

Sprint 2:

• Add timetable section

• Add contact form

Every day the team checks progress

At the end of each Sprint, you review what was built
Then you improve the process and plan the next Sprint

Pipeline Example: School App Pipeline

Let’s say a student team is building a school timetable app:
Stage Action

Code Developers write code and push to GitHub

Build Jenkins builds the app (e.g., creates .apk)

Test Automated tests run (check login, schedule, etc.)

Staging Teachers and students try it on test devices

Release After approval, it’s published to Google Play

Monitor Feedback is collected from users

Real Example of Bottleneck : Shopping App Feature Release
Scenario: Add a "Buy 1 Get 1 Free" Feature

1. Code done by dev in 2 hours

2. QA team takes 3 days to manually test it
3. Release manager waits for business sign-off (2 more days)
4. Finally deployed after 5 days

Bottlenecks Identified:

 Manual testing
 Delayed approvals