LEARN. PRACTICE. GROW.1. Start with a concrete operational question
During a fictional incident, RUN asks which version reached production and which request justified it. The answer should not depend on someone remembering a release name. Draw relationships between the work item, code change, build run, artifact and target deployment. Each relationship needs a retrievable reference. The current branch tip can postdate the build; a release name can have been reused. In the exercise, two teams use the same name but rebuilt the package at different times. The manager requests the reference actually consumed and the run that produced it. This chain supports investigation and recovery decisions. It does not by itself establish that content was correct, authorization was valid or the service met functional acceptance criteria. Keep these evidence boundaries visible when presenting deployment status.
2. Create observable links between Boards and GitHub
Configured integration still needs references in supported fields. An AB# mention in the PR description can create a work-item link; placing it only in the title or a comment does not have the same effect. The exercise uses a fictional number and asks you to confirm the resulting link. If absent, start by checking configuration, reference location and relevant permissions while retaining attempt history. Also distinguish linking from state transition. Merging into a release branch different from the default does not satisfy the documented condition for automatic transition. Avoid closing the ticket merely to improve a dashboard. State should represent the agreed completion rule and available evidence. A traceability relationship does not replace change acceptance. Explain the distinction to people who consume the work-item status as a delivery signal.
3. Use evidence appropriate to the pipeline technology
When migrating Classic releases to YAML, do not assume every interface control retains the same purpose. The work item Deployment control depends on classic release integration and does not support YAML stages. In the scenario, an empty field leads to an incorrect conclusion that the change never reached the target. For YAML, consult environment history for targets used by deployment jobs and follow the relevant run. Also confirm the consumed artifact and application observation. A recorded deployment describes an execution; a functional exercise describes the service outcome. Both kinds of evidence can be necessary. Update the support runbook when changing technology, including where to find information, which permissions are needed and how to investigate a gap without immediately repeating the change.
4. Review generated notes before handover
Notes generated from Git help collect changes but depend on the comparison range and filters. An excluded label can remove a PR from text while its changes remain in the package. In the exercise, maintenance hides a configuration change relevant to RUN. Review comparison boundaries, included content and operational impact requiring human explanation. Document manual steps, data effects and limitations where they exist. Notes should identify the delivered version without suggesting automatic generation verified the application. Also retain necessary evidence for the agreed period: deleting a run can remove its pipeline artifacts. The retention plan should allow investigation and recovery of relevant versions while respecting data rules applicable to the fictional project. A readable summary and retrievable technical evidence support different parts of the same handover.
5. Define the population before comparing metrics
A time chart represents items selected by team, type, filters and period. Before announcing improvement, confirm that you compare sufficiently similar work and that states were updated consistently. In the example, small urgent defects are compared with large features from the previous quarter. The observed difference can reflect sample composition. Reporting should present that limitation, counts and the question the metric helps answer. Another chart shows a low average among completed items while old work remains open. The average does not automatically incorporate that risk. Add observation of pending-work age and blockers. Do not turn a descriptive value into an individual delivery promise. Use it to investigate the process and discuss decisions with people who understand execution constraints and the consequences of changing priorities.
6. Investigate accumulation before starting more work
In a fictional model without reopening, cancellation or scope changes, the queue starts with eleven items. Eight arrive and five leave each day. After four days, twenty-three items are waiting. The arithmetic describes accumulation; it does not prove that a specific person is missing or that all items require equal effort. A cumulative flow diagram helps observe distribution across states and changes over time, provided the board represents actual work. The PM should investigate blockers, validation criteria, dependencies and capacity with accountable people. Increasing arrivals without understanding the constraint can increase waiting. When urgent items exist, make the priority decision and its effects on other work explicit instead of hiding the queue through artificial state changes. Record what would demonstrate that the chosen intervention improved flow.
7. Treat notifications as a path that can fail
A service hook can become restricted after failures and lose new events during probation. Seeing recent events after recovery does not establish completeness of the earlier interval. Compare the source system with the consumer and define controlled gap reconstruction. In another example, a GitHub receiver generates a lengthy report before responding. Separate validated receipt from processing, using an appropriate queue to preserve accepted work. A redelivery can represent the same delivery, so the consumer needs to recognize identity and avoid duplicate effects. This design decision is not a promise of exactly-once processing. Also record event type and action, validation outcome and processing failures. Support needs to distinguish no event, transport failure and consumer failure. Recovery should address the observed failure rather than merely increase the volume of notifications.
8. Rehearse the investigation RUN will need
Give the team a fictional incident containing a deployment reference, an artifact and a work item. Ask them to identify the version, retrieve evidence and explain whether they can decide on recovery. The Python model below only compares fields in supplied records: it does not authenticate origin, query Azure or GitHub, or verify package bytes. A model match means those relationships are consistent, not that functional acceptance passed. Then introduce an incorrect reference and observe whether the learner detects it without relying on the release name. This progression moves from a correct chain to a concrete gap and finally to an incident decision. In practice, record what handover lacks, who will fix it and which exercise demonstrates autonomy. The aim is repeatable investigation, including outside normal working hours.
# Fictional record-consistency model; no API calls, authentication or byte verification.
def consistent(change, build, artifact, deployment):
required = [(change, ("id", "commit", "target")),
(build, ("id", "commit")),
(artifact, ("id", "buildId")),
(deployment, ("artifactId", "target", "status"))]
if any(not record.get(key) for record, keys in required for key in keys):
return False
return (change["commit"] == build["commit"]
and artifact["buildId"] == build["id"]
and deployment["artifactId"] == artifact["id"]
and deployment["target"] == change["target"]
and deployment["status"] == "succeeded")
change = {"id": "CH-42", "commit": "commit-A", "target": "prod"}
build = {"id": "build-17", "commit": "commit-A"}
artifact = {"id": "artifact-A", "buildId": "build-17"}
deploy = {"artifactId": "artifact-A", "target": "prod", "status": "succeeded"}
assert consistent(change, build, artifact, deploy)
assert not consistent(change, {**build, "commit": "commit-B"}, artifact, deploy)
assert not consistent(change, build, {**artifact, "buildId": "build-18"}, deploy)
assert not consistent(change, build, artifact, {**deploy, "artifactId": "artifact-B"})
assert not consistent(change, build, artifact, {**deploy, "target": "qa"})
assert not consistent(change, build, artifact, {**deploy, "status": "failed"})
assert not consistent(change, build, artifact, {**deploy, "artifactId": ""})
assert consistent(change, build, artifact, {**deploy, "releaseName": "another-label"})
print("eight fictional traceability checks passed")
Two releases named October-Fix use different artifacts. The exercise compares change.commit, build.commit, artifact.buildId and deployment.artifactId to identify the incorrect relationship. Identifiers are fictional.
Common pitfalls
Confusing a linked PR with an accepted change; treating an empty classic field as proof about YAML; comparing different populations; ignoring open work; treating restored notifications as reconstructed history.
Related topics: Artifact provenance · Incident management · Flow metrics · Event integration
Traceability needs retrievable relationships and measurement needs a defined population. Establish what was delivered and what remains missing before deciding the next change.
Reference: Link GitHub commits and pull requests to Azure Boards work items · AZ-400 objectives 2026-07-27