Design and implement processes and communications · Topic 1 of 3

Traceability and Flow of Work

AZ-400 flow of work: GitHub Flow, feedback cycles with notifications and GitHub Issues, GitHub Projects, Azure Boards integration and end to end traceability.

5 min
Includes a diagram

In a nutshell

GitHub Flow: branch, commit, pull request, review, deploy, merge. main stays deployable.
Link work in Azure Boards from GitHub with AB#<id>. Install the Azure Boards app to enable it.
GitHub Issues track work in GitHub. GitHub Projects gives table, board and roadmap views.

What it is

Flow of work is how a piece of work moves from an idea to production without waiting or getting lost. Traceability is the ability to follow a change in both directions: from a requirement to the code, build and release that delivered it, and from a deployed change back to the requirement and the bug it fixed.

The exam asks you to design this: pick a branching flow, pick where work is tracked (GitHub or Azure Boards), connect them, and make sure feedback reaches the right people.

How it works

GitHub Flow

GitHub Flow: create a branch from main, commit changes, open a pull request, run review and automated checks, optionally deploy the branch to test, then merge to main, which stays deployable. GitHub Flow is a lightweight, branch based flow for teams that deploy often. The steps are always the same.

Create a branch from main with a descriptive name.
Make commits on the branch.
Open a pull request to start discussion and review.
Review, discuss and let automated checks run.
Deploy from the branch to test it if you need to, then merge into main.

The rule that makes it work is that main is always deployable. There are no long lived develop or release branches. It suits continuous delivery. Teams that ship versioned releases may need release branches instead (see the source control chapter).

Feedback cycles

Fast feedback means the right person hears about a change quickly.

Need	GitHub	Azure DevOps
Notify people of activity	Watching a repository, participating in a thread, notification settings (web, email, mobile)	Notification subscriptions (personal, team, project or organization level)
Collect requests and bugs	GitHub Issues with issue templates and forms, labels, assignees and milestones	Work items with fields, states and rules
Notify on pipeline results	Actions workflow notifications, status checks on pull requests	Build and release notifications, service hooks

Issue templates and forms make requests arrive with the information you need, such as steps to reproduce. Labels and milestones group issues. In Azure DevOps, subscriptions let a team get an email when, for example, a build fails or a work item is assigned to the team.

Tracking work

Tool	What it gives you
GitHub Projects	Table, board and roadmap views over issues and pull requests, custom fields, filters, grouping, built in automations (for example moving an item when it is closed) and charts
Azure Boards	Work item types for a process (Agile, Scrum, Basic, CMMI), backlogs, Kanban boards, sprints and queries

Azure Boards uses a process to define work item types. Agile has Epic, Feature, User Story, Task and Bug. Scrum has Epic, Feature, Product Backlog Item, Task and Bug.

Connecting Azure Boards and GitHub

You connect an Azure DevOps project to a GitHub repository by installing the Azure Boards app in GitHub and authorizing it. After that, you link by mentioning a work item in a commit message, pull request or issue using the syntax AB#<id>, for example AB#125.

Fixes AB#125: validate the payment currency

Using a closing keyword such as Fixes before AB#125 in a pull request can move the work item to a done state when the pull request merges. The work item then shows the linked commit and pull request in its Development area.

Traceability end to end

Link	How you get it
Requirement to code	Work item or issue ID in the branch name, commit message or pull request
Code to build	A build or workflow run records the commit it built
Build to release	A deployment records the build or artifact version it deployed
Release back to requirement	Azure Pipelines can show the work items included in a run, based on the commits
Bug to fix to test	Bug linked to the fixing pull request and to the test that verifies it

In Azure DevOps, work items can be linked to commits, pull requests, builds and deployments, so you can answer "which work items shipped in this release?". In GitHub, closing keywords such as Fixes #42 link a pull request to an issue and close the issue on merge.

A worked scenario

A team wants every production change to be traceable to an approved requirement. They keep requirements as Azure Boards work items, host code in GitHub, and deploy with Azure Pipelines. They install the Azure Boards app on the repository, require branch names and pull request descriptions to contain an AB# reference, and use a branch protection rule that requires the pull request. After a release, the pipeline run lists the work items that went out, and each work item lists its pull request.

What to remember for the exam

GitHub Flow: branch, commit, pull request, review, deploy, merge. main stays deployable.
Link work in Azure Boards from GitHub with AB#<id>. Install the Azure Boards app to enable it.
GitHub Issues track work in GitHub. GitHub Projects gives table, board and roadmap views.
Azure Boards processes are Agile, Scrum, Basic and CMMI.
Traceability means links between work items, commits, pull requests, builds and releases.

Exam tip

A question that says "link GitHub commits to Azure Boards work items" wants the Azure Boards app and the AB# syntax.

How the exam asks about this

"Move a work item to done when the pull request merges." A closing keyword with AB#.
"Show roadmap and board views over GitHub issues." GitHub Projects.
"Keep main always releasable with short lived branches." GitHub Flow.
"Notify a team when a build fails." A notification subscription or a service hook.

Common mistakes

Forgetting the app. Typing AB#125 does nothing until the Azure Boards app is installed and authorized.

Using long lived branches with GitHub Flow. It assumes short branches and a deployable main.

Tracking work outside the code system. A spreadsheet cannot give traceability. Link real work items.

Treating notifications as monitoring. Notifications tell people about events. They are not metrics.

Check yourself

What syntax links a GitHub commit to an Azure Boards work item?
AB# followed by the work item ID, such as AB#125, with the Azure Boards app installed.
In GitHub Flow, what must always be true of the main branch?
It is always deployable.
Which GitHub feature gives table, board and roadmap views over issues?
GitHub Projects.

Topic 1 of 3 in Design and implement processes and communications

Test yourself on Design and implement processes and communications

The full Microsoft AZ-400 question bank has 766 questions, with timed practice exams and an explanation for every answer.

Subscribe Try Sample Exam

This study guide is independent and is not affiliated with, endorsed by, or sponsored by Microsoft. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.