Azure DevOps Development,

Deployment and Testing Flow

A Comprehensive Overview of
Branching, Development, Build,
Deployment and Testing
 Define the Epic and Break Down
Epics
Definition: Epics are the highest-level work items and represent
significant chunks of work or large business objectives. They often span
multiple teams, releases, or sprints.

Example
"Build a Customer Management System“

Usage
• Divide the project into large, strategic objectives.
• Typically broken down into multiple Features.
 Define the Feature and Break Down
Features
Definition: Features are a subset of an Epic and represent a group of
functionalities or deliverables that provide value to the user. They focus on
more specific goals than an Epic.

Example
• For the Epic "Build a Customer Management System," a Feature could
be "Implement User Authentication.“

Usage
• Focus on deliverables that can be completed in a shorter time frame.
• Often broken into multiple User Stories.
 Define the User Story and Break Down
Definition: User Stories describe specific, actionable requirements from the
end-user perspective. They capture the "who," "what," and "why" of a
particular feature or task.
Format: Often written as:
"As a [type of user], I want to [perform some action] so that [achieve some
outcome]."
Example:
For the Feature "Implement User Authentication," a User Story could be: "As
a user, I want to reset my password so that I can regain access to my account
if I forget it.“
Usage
• Define detailed requirements or actions needed to complete a feature.
• Typically assigned to individual team members for implementation.
 Relationship Between Epics, Features, and User
Stories
Hierarchy:
Epic → Feature → User Story → (optional) Task
Example Flow:
Epic: "Build a Customer Management System"
Feature: "Implement User Authentication"
User Story: "As a user, I want to reset my password so that I can regain
access to my account."
Other Related Work Items
Tasks: Smallest units of work, typically used to break down User Stories into
actionable steps.
Example: "Design the UI for the password reset page."
Bugs:
Work items used to track issues or defects in the system.
 General Acceptance Criteria for All Features

• The implementation must pass unit, integration, and end-to-

end testing.
• All UI elements must adhere to accessibility standards.
• The functionality must be tested in multiple browsers (e.g.,
Chrome, Firefox, Safari) and on multiple devices.
 Definition of Done (DoD)
The Definition of Done (DoD) outlines the criteria that must be met for a work item
(Epic, Feature, User Story, or Task) to be considered complete.

Here’s a breakdown for each level:

Epic:

Definition of Done:
• All associated Features are completed and meet their respective Definitions of
Done.
• Business stakeholders have reviewed and approved the overall delivery of the
Epic.
• Documentation related to the Epic (e.g., business case, success metrics) is
complete and accessible.
• Dependencies on other Epics or teams are resolved.
• The Epic's objectives and key results (OKRs) or goals are achieved and measurable.
End-user validation or feedback confirms that the Epic delivers its intended value.
Feature:

Definition of Done:

1.All associated User Stories are completed and meet their respective Definitions
of Done.
2.The Feature has been tested end-to-end, including integration with related
Features.
3.Documentation for the Feature (e.g., user guides, release notes) is complete
and shared.
4.Product owner or stakeholder has reviewed and approved the Feature.
5.All functional and non-functional requirements (e.g., performance, security)
are met.
6.The Feature is deployed to a staging or production environment (if applicable)
and verified.
User Story: Definition of Done

Definition of Done:

1. Code for the User Story is written, reviewed, and merged into the
main branch.
2. All unit, integration, and acceptance tests for the User Story pass.
3. The User Story has been reviewed and approved by the product
owner.
4. The functionality works as expected in staging or production
environments.
5. UI/UX designs, if applicable, match the approved mockups.
6. The work meets acceptance criteria, including edge cases and error
handling.
7. Necessary documentation (e.g., comments in code, API docs, user
guides) is complete.
8. No critical bugs or defects remain unresolved.
Task

Definition of Done:

1.The work described in the Task is completed as specified.

2.Any changes are committed to the version control system with
appropriate comments.
3.Code or deliverables are peer-reviewed and meet team coding or quality
standards.
4.The Task does not introduce new bugs or issues.
5.Documentation, if required (e.g., comments, setup instructions), is
complete.
6.The Task is linked to its parent User Story, Feature, or Epic and marked as
complete in the tracking tool (e.g., Azure DevOps).
 Testing Flow
Create Test Plans and Test Suites

Navigate to Azure Test Plans:

• In your Azure DevOps project, go to the Test Plans section.

Create a Test Plan:

• A Test Plan represents a collection of Test Suites and Test Cases
for a specific scope, such as a sprint or release.

Add Test Suites:

• Static Test Suite: Manually group related Test Cases.
• Requirement-based Suite: Automatically link Test Cases to User
Stories.
Track Bugs

Log Bugs:

• If a Test Case fails, create a Bug work item directly from the Test Case.
• Link the Bug to the relevant User Story or Test Case.

Fix and Retest:

• Developers address the Bug, and the Test Case is retested to verify the
fix.

Review and Report

Generate Test Reports:

Use built-in dashboards to track:
• Test Plan coverage.
• Test Case pass/fail rates.
• Bugs linked to Test Cases.
 Development Flow
1. Main Branch (e.g., main or master):
• This is the production-ready branch. Only fully tested and verified code gets
merged here. Do not directly commit to the main branch.
• Set branch policies to enforce quality (e.g., require PR reviews before
merging).
• Define a branching strategy (e.g., main, develop, and feature branches).

2. Feature Branches:

• Each developer works on a separate feature branch. These branches are

created off the main branch and are named based on the User Story or Task
they are working on.
Example: feature/user-login, feature/password-reset, feature/login-ui.
• Each branch should be dedicated to a specific User Story or Task to keep
things organized.
• Developers regularly pull the latest changes from the main branch to avoid
conflicts and ensure they are working with the latest code.
 Development Process for Multiple Developers

1. Each Developer Works on Their Task:

Developers pull the latest code from the main branch, create a feature
branch, and start coding.

2. Commit and Push Changes:

• Developers commit code with clear messages.
• Push changes to their feature branches regularly.

3. Pull Requests (PR):

• Developers create a PR to merge their changes into the `main` or
`develop` branch.
• Code review happens here before merging.
 Continuous Integration and Build Process
(CI/CD)

1. Automated Builds:
• Build pipeline triggered whenever changes are pushed to feature
branches.
• Builds and unit tests are executed automatically.
2. Build Definitions:
• Pipelines specify which branches to trigger builds on and define build
tasks.
3. Test Automation:
• Unit and integration tests run during the build to maintain code quality.
 Merging and Deployment to Environments

1. Feature Testing in Dev Environment:

Code merged into `develop` or `main` and deployed to Dev for
integration testing.

2. Deploy to QA Environment:
After Dev testing, the code is deployed to QA for functional testing.

3. Deploy to Staging/Production:
After successful QA testing, the code is deployed to Staging for UAT, then
to Production.
 Code Review and Collaboration Process

1. Code Review:
• Developers submit PRs for code review before merging.
• Reviewers ensure code quality and adherence to standards.
2. Resolve Merge Conflicts:
• Developers resolve merge conflicts and collaborate to integrate code.
 Final Testing and Deployment to Production

1. Staging and UAT:

• Code is deployed to staging for final UAT and approval from product
owners.
2. Production Deployment:
• After approval, the code is deployed to production.
 Retrospective Meeting
What is a Retrospective Meeting?
A Retrospective Meeting (or Retro) is a regular team meeting held after the
completion of a sprint, iteration, or milestone in Agile methodologies (like
Scrum). The purpose is to reflect on what went well, identify areas for
improvement, and define actionable steps to enhance future performance.

Purpose of a Retrospective Meeting

1. Continuous Improvement: Analyze past work to improve processes and

team efficiency.
2. Team Collaboration: Foster open communication and teamwork by
encouraging feedback.
3. Problem Solving: Identify and address challenges or blockers encountered
during the sprint.
4. Celebration: Acknowledge and appreciate successes and team efforts.
 Summary of the Development and Deployment
Flow
1. Branch Creation: Developers create individual feature branches off the
main branch.
2. Development: Developers work on their assigned User Stories or Tasks,
commit changes to their feature branches, and push them to Azure DevOps.
3. Pull Requests (PR): After completing a task, developers create PRs to
merge their changes into the develop or main branch. Code reviews are done
here.
4. CI/CD Pipeline: Automated builds and tests are triggered whenever a
developer pushes changes to a feature branch.
5. Deploy to Dev Environment: Merged code is deployed to a Dev
environment for integration testing.
6. Deploy to QA Environment: After successful testing, the code is deployed
to QA for full functional and acceptance testing.
7. Staging and Production: After final validation, the code is deployed to
Production.
How to Conduct a Retrospective Meeting

Preparation
•Set the Schedule: Typically held at the end of each sprint (e.g., 1-2 hours
for a 2-week sprint).
•Invite Participants: Include all team members involved in the sprint
(developers, testers, product owners, etc.).
•Choose a Facilitator: A Scrum Master or team member to guide the
meeting.

Best Practices for a Successful Retro

1.Create a Safe Space:

Encourage openness and honesty without fear of blame.
2.Time Management:
Keep the discussion focused and avoid going off-topic.
3.Encourage Participation:
Give everyone a chance to share their thoughts.
4.Focus on Actions:
Ensure the meeting ends with clear, actionable tasks.
Tools and Techniques :

Azure DevOps:
Use the Retrospectives extension to collect feedback and create
actionable tasks.

Benefits of Retrospective Meetings :

•Improves team morale by celebrating achievements.

•Enhances transparency and collaboration.
•Identifies process inefficiencies and bottlenecks.
•Encourages accountability through action items.
 Setting Up Project
• Navigate to the Boards section in project.
• Iteration Paths: Set up iterations (sprints) for managing Agile development.
• Area Paths: Organize work items into functional or team-specific areas.

• Customize columns ( New, On-Hold, Active, Resolved, Done) to match your workflow.

Points in Azure DevOps

• Points typically refer to Story Points or Effort and are used to estimate the relative size or
complexity of a work item (e.g., User Story or Task).

Purpose of Points:

• Effort Estimation: Quantify the amount of work or complexity.

• Team Velocity: Track how much work the team can handle in a sprint.
• Planning: Help allocate resources and predict sprint capacity.
• Consistency: Use a consistent scale (e.g., Fibonacci series: 1, 2, 3, 5, 8,13,21) for estimating points

Story Points vs. Effort:

• Story Points: Used in Agile processes like Scrum.
• Effort: Used in Basic and other templates. It serves a similar purpose.
 Priority in Azure DevOps

Priority defines the importance or urgency of a work item. It helps the team understand
what should be addressed first.

Purpose of Priority:

Decision-Making: Focus on high-priority items.

Customer Value: Prioritize items that deliver maximum value.
Risk Mitigation: Address critical issues before lower-priority ones.

Priority Levels:

Azure DevOps uses numerical values for priority, typically:

1 - High: Must be completed immediately or in the current sprint.

2 - Medium: Important but can wait until higher-priority items are resolved.
3 - Low: Nice-to-have or can be deferred to future sprints.
 Summary
Work Item Focus Definition of Done
Epic High-level objective All Features done, approved by
stakeholders, business value
delivered
Feature Group of functio All User Stories done, tested end-
nalities to-end, approved
User Story Specific user requirement Code complete, tested, meets
acceptance criteria
Task Smallest unit of work Work completed, reviewed, and
linked to parent item
Governance and Best Practices

1.Regular Backlog Grooming: Ensure work items are updated and prioritized.
2.Enforce Branch Policies: Maintain code quality through PR reviews and build
validations.
3.Use Templates: Standardize pipelines, work items, and test cases for consistency.
4.Track Velocity: Monitor team progress to adjust plans as needed.
5.Automate Everything: From builds to deployments, minimize manual
interventions to reduce errors.

Checklist

6.Work Items: Epics, Features, Stories, Tasks with acceptance criteria.

7.Repositories: Branching strategy and policies.
8.Pipelines: CI/CD automation for builds, tests, and deployments.
9.Testing: Manual and automated testing integrated with pipelines.
10.Dashboards: Custom metrics tracking for visibility.
11.Security: Role-based access and branch/environment protections.