Cram Sheet241 words
Topic 1.1 — Traceability and flow of work — cram sheet
Topic 1.1 — Traceability and flow of work · cram sheet
GitHub Flow
branch → commit → PR → review → merge → deploy. main is always deployable.
Work spanning cycles → merge continuously behind a feature flag, not a long branch.
Feedback
- Subscribe teams, not individuals — survives joiners and leavers.
- Scope to events needing a decision or action. Noise → wholesale filtering.
- Explicit feedback (issues, tickets) = what users noticed. Implicit (telemetry) = what happened, including to those who gave up silently.
Work tracking
- Link syntax
AB#123in commits, branch names, PR titles/descriptions. #123alone = a GitHub issue, not a work item.Fixes AB#123closes the item on merge.- Boards = hierarchy, process templates, portfolio. GitHub Projects = lightweight, beside the code. The connection lets you use both.
The traceability chain
work item → commit → PR → build → test results → release
| Link | Answers |
|---|---|
| Work item → commit | Why was this changed? |
| Commit → build | Which build contains it? |
| Build → test results | What evidence exists? |
| Build → release | Where is it running? |
Weakest link: commit → work item, because a human writes the mention. Enforce with a branch policy requiring a linked work item. A build with no published test results proves only that steps exited zero.