AZ-400 Designing and Implementing Microsoft DevOps Solutions Exam

Design a branch strategy, including trunk-based, feature branch, and release branch

A branch strategy is a plan for how developers create and merge branches in a source control system. Its purpose is to help teams work in parallel without disrupting the main code. Branch strategies improve collaboration, reduce merge conflicts, and support continuous delivery. By choosing the right approach, teams can deliver updates faster and with higher quality.

In a trunk-based strategy, every developer merges changes directly into a single main line, often called trunk or main. Teams use short-lived branches or no branches at all and rely on continuous integration to keep the main code stable. This approach reduces complexity and keeps the codebase current, but it requires strict testing and fast feedback loops. It works best for small teams or projects that deploy frequently.

A feature branch strategy uses a new branch for each feature or bug fix. Developers work in isolation and merge back into main only after the feature is complete. This model supports code reviews and peer feedback through pull requests. Teams can name branches by ticket numbers or feature descriptions to keep things organized.

When you need a formal release, a release branch is created from main just before deployment. This branch is used for final testing, bug fixes, and documentation updates. After the release, changes are merged back into main and often into a development branch. This approach helps stabilize the code for production without blocking ongoing feature work.

Choosing between these strategies depends on team size, release frequency, and risk tolerance. Trunk-based works well for fast-moving teams, while feature branches offer isolation in larger groups. Release branches give a controlled environment for final testing. The key is to balance agility with stability and to enforce consistent naming and merging rules.

Design and implement a pull request workflow by using branch policies and branch protections

A pull request is a formal way to ask for code to be merged into a target branch. It triggers discussions, reviews, and automated checks before integration. Using pull requests encourages peer review and keeps the main branch clean. They also provide a history of why changes were made, which is useful for auditing and debugging.

Branch policies in Azure Repos let you enforce rules on pull requests. You can require a minimum number of reviewers, successful builds, or linked work items before merging. These policies help ensure that code meets quality standards and follows team guidelines. Policies can be applied to any branch, but they are most critical on main and release branches.

Branch protections prevent direct pushes to important branches. By enabling protected branches, you force all changes to go through pull requests. This reduces the chance of accidental breaks and enforces consistent review practices. Protections can also block force pushes and deletions, keeping history intact.

A good pull request workflow includes clear templates, small changes, and timely reviews. Teams should use branch policies to automate checks like code coverage and static analysis. Pull requests should be labeled, tied to work items, and assigned to the right reviewers. This practice ensures that every change is verified, documented, and approved.

By combining pull request workflows, branch policies, and protections, teams create a robust process that supports collaboration and code quality. Automated checks catch issues early, and human reviews add context and insight. This structured approach helps deliver reliable software on schedule.

Implement branch merging restrictions by using branch policies and branch protections

Branch merging restrictions establish rules about who and how code can be merged. They protect key branches from unreviewed or failing changes. Restrictions are crucial for maintaining a stable production environment. In Azure Repos, you configure these through branch policies and branch protections.

Branch policies can require that builds succeed before a merge, enforce code reviewer approvals, and ensure work items are linked. These settings prevent merges when tests fail or reviews are missing. Teams can also block merging if certain file paths are modified without extra scrutiny. This level of control helps catch errors that automated tests might miss.

Path filters let you apply different policies to different parts of the repository. For example, changes to critical infrastructure files might need more approvals. Other areas, like documentation folders, may need fewer checks. This flexibility allows you to fine-tune restrictions based on risk and impact.

Protections also include preventing force pushes and deletion of branches. This ensures that history remains traceable and that no one can overwrite approved changes. Teams can set expiration policies or require periodic security audits to keep the process up to date. These measures add another layer of safety to the development flow.

By enforcing branch merging restrictions, teams uphold high standards for code quality and security. Everyone follows the same rules, and mistakes are caught before they reach production. A consistent, well-enforced policy framework boosts confidence and reduces downtime.

Conclusion

In this section, we examined three key areas of branching strategies in Azure Repos. We started by exploring how to design strategies with trunk-based, feature, and release branches to suit different team needs. Next, we looked at building a strong pull request workflow using branch policies and branch protections to ensure every change is reviewed and tested. Finally, we covered how to implement merging restrictions to keep critical branches stable and secure. Together, these practices help teams deliver code quickly, maintain high quality, and reduce the risk of production issues.