Fabrikam: One Repository, Four Release Cadences
Fabrikam has six teams sharing one Azure Repos Git repository: 12 GB, nine years of history, including roughly 400 MB of design files under /assets that change weekly. A fresh clone takes 25 minutes and branch builds take 18 minutes. Two services ship daily, the main product ships monthly, and one regulated component needs a two-week hotfix path with compliance sign-off. Today each release uses a long-lived release branch with cherry-picks from main, producing about two days of conflict resolution per release and occasional fixes that never reach main. Code review is inconsistent: the platform team reviews everything and has become a bottleneck, while /infra changes routinely merge unreviewed. Leadership asks whether the repo should be split.
1. Recommend a repository topology and branching model. Justify the choice against the four release cadences and the hotfix requirement.
Read the worked answer
Keep one repository, but stop storing binaries in it. Move /assets to Git LFS or, better, to an artifact/package store with a versioned pointer committed instead. Weekly-changing binaries are exactly what causes pack bloat, and this single change addresses most of the clone time without paying the cost of a repo split. Splitting for six teams multiplies pipeline, permission, and cross-repo change work and does not fix cadence.
Branching: trunk-based for the two daily services and the main product - short-lived feature branches, squash or rebase merge, release by tag rather than by branch. Long-lived release branches are the direct cause of two days of cherry-pick conflicts.
The regulated component can keep a frozen release branch if its sign-off genuinely requires a stable snapshot, but tag plus an immutable artifact usually satisfies that and avoids divergence. Deploy the tag, not the branch tip. Tradeoff: tags demand discipline and a rule that only pipeline-built artifacts reach production.
2. Fix review ownership and build validation so the platform team stops reviewing everything, without letting /infra merge unreviewed.
Read the worked answer
Use Azure Repos automatically included reviewers with path filters rather than a blanket policy:
/infra/**,*.bicep,*.ymlat repo root: platform team, reviewer required.- Each service folder: that service's two named reviewers, required only for its own paths.
- Everything else: optional review plus a minimum reviewer count on main.
Add build validation with path filters so a change under service A does not queue service B's full 18-minute build, and keep a stronger policy (more reviewers, no bypass) on main than on short-lived branches.
Tradeoffs: path-filtered reviewers can miss cross-cutting changes - a shared library edit that affects five services gets one team's review. Mitigate with an affected-services label and a required check from a dependency scan. This shifts the platform team from reviewer-of-everything to owner of infrastructure, pipeline YAML, and exceptions, which is where their judgement actually adds value.
3. Describe the hotfix flow end to end, including how the fix reaches main.
Read the worked answer
- Branch
hotfix/<incident>from the tag currently deployed to production, not from main. - Apply the minimal fix; open a PR with an expedited policy: one required reviewer, build validation scoped to that service, no unrelated refactoring.
- Deploy through the same pipeline stage as a normal release, with the compliance approver attached as an environment check so the sign-off is recorded against the artifact and commit.
- Tag the deployed commit.
- Merge the hotfix back into main by merge commit, under review - not by cherry-pick. If main has moved, that merge is where the conflict is resolved once, deliberately, instead of at the next monthly release.
Add a scheduled check that every tag deployed to production has an ancestor in main. Without it, divergence is silent and untested combinations accumulate.
Tradeoff: the merge-back can be slow if main drifted far. That friction is the signal that release branches live too long, not a reason to skip the merge.