Design and implement processes and communications
Flow of Work and Traceability
CoreDesign short feedback loops and durable traceability from planned work through source, quality evidence, release, and production learning across GitHub and Azure Boards.
Aligned to AZ-400 skills measured as of July 27, 2026; guide and product behavior verified September 25, 2026.
Why this matters
Expert DevOps decisions make work visible without multiplying disconnected records. Traceability must survive tool boundaries and answer who requested, changed, validated, released, and restored a service.
Must Know
- GitHub Flow uses a protected main branch and short-lived branches that become pull requests; it suits continuous delivery when incomplete exposure is controlled separately.
- GitHub Issues and Projects can capture work, ownership, status, and automation; notifications should be subscribed at the narrowest event and repository scope that requires action.
- The Azure Boards GitHub App connects selected GitHub repositories to one Azure Boards organization and project and supports AB# work-item links from commits and pull requests.
- A traceability chain needs durable identifiers linking work item, branch or commit, pull request, build, test result, artifact, deployment, and incident or bug.
- A work item link is evidence of association, not proof that a build passed, a test ran, or the change reached production.
- Feedback design includes ownership, routing, response expectations, and closure criteria; sending more notifications is not the same as shortening a feedback loop.
Compare and Distinguish
- GitHub Issues track work in GitHub; Azure Boards provides Azure DevOps backlog, planning, query, and process capabilities; GitHub Projects can organize issues and pull requests across repositories.
- A commit mention supplies a link; branch protection or policy supplies merge enforcement; pipeline and deployment records supply quality and release evidence.
Scenario examples
- Scenario: Product planning stays in Azure Boards while code moves to GitHub. Think: connect the repositories through the Azure Boards GitHub App and use AB# traceability.
- Scenario: A defect escaped to production. Think: follow durable work, source, build, test, artifact, deployment, and incident identifiers rather than relying on commit messages alone.
Exam traps
- Long-lived feature branches increase integration delay and do not create better traceability.
- Connecting a repository does not automatically make every commit meaningful; teams still need consistent linking and completion practice.
- Watching every repository event creates noise that can hide the feedback requiring action.
Key takeaways
- Choose one authoritative work record per planning need and integrate rather than duplicate.
- Separate linkage, merge enforcement, quality evidence, and deployment evidence.
- Design feedback for action and closure, not raw notification volume.
How it works
- Repository and work-tracking integrations attach stable identifiers to commits and pull requests, while pipelines add build and deployment evidence.
- Branch protection enforces entry to the main line; it does not replace release history or production incident correlation.
Objects and administrative surfaces
- GitHub Issues, Projects, notifications, pull requests, checks, and repository settings.
- Azure Boards connections, work items, queries, backlogs, dashboards, and deployment links.
When to use it
- Use a cross-platform connection when code and the authoritative backlog intentionally remain in different products.
Security and governance implications
- Limit repository connections to the projects and repositories that need linkage, and retain evidence of protected changes.
Troubleshooting signals
- If AB# references do not link, verify the installed app, selected repository, destination project, syntax, and integration permissions.
- If a trace ends at build, compare retained artifact and deployment identifiers before adding more work-item metadata.
More detail
- Choose GitHub Issues, GitHub Projects, or Azure Boards according to where planning authority and cross-repository views must live.
- Use the Azure Boards GitHub App and AB# syntax when GitHub commits and pull requests must update existing Azure Boards work.
- Distinguish a work-item association from proof that a particular build passed tests and reached a named environment.
Ready for the quiz?
- When does GitHub Flow fit better than a release-branch model?
- Which evidence proves a work item reached a particular production deployment?
- Why can an AB# link be necessary but insufficient for quality traceability?
Related objectives
- D1.1.S1 — Design and implement a structure for the flow of work, including GitHub Flow
- D1.1.S2 — Design and implement a strategy for feedback cycles, including notifications and GitHub Issues
- D1.1.S3 — Design and implement integration for tracking work, including GitHub projects, Azure Boards, and repositories
- D1.1.S4 — Design and implement source, bug, and quality traceability