The main branch of the booking portal of Nordlicht Reisen GmbH, a fictional travel agency, is still open so far: whoever has write access pushes directly. Last week a push broke the build, and nobody had seen the change. You are to protect the main branch so that every change goes through a pull request, is reviewed and built, and so that this works equally well in Azure Repos and on GitHub.

The exam calls this: designing the pull request flow with branch policies and branch protection rules and defining merge restrictions.

Prior knowledge: You know a pipeline for a repository from K3, lessons 3.7.1 and 3.7.2; there you also see how a build hangs on the pull request as a condition. Which branching strategy your team uses you decide in lesson 2.1; here you enforce it. Permissions and groups in detail follow in lesson 2.4 and in module D5.

The goal: a main branch that always builds

Microsoft's guide to the branching strategy says that the code in the main branch should pass tests, build cleanly and be current. For that it recommends a policy that requires three things: a pull request for changes (this prevents direct pushes), automatically added reviewers and a successful build. In addition, the pull request build should be fast so that it does not hold up the review. In Azure Repos the mechanism is called branch policies, on GitHub branch protection rules and, newer, rulesets.

Microsoft's page on branch policies says: A branch with required policies cannot be deleted, and all changes must go through pull requests.