Design and implement branching strategies for the source code
Design a Branch Strategy
A branch strategy defines how developers organize their code changes in a shared repository. In trunk-based development, developers commit small changes directly to the main branch multiple times per day. This keeps the codebase constantly ready for release but depends heavily on automated testing to catch bugs early. Alternatively, feature branch workflows isolate new features or bug fixes in their own temporary lines of work until they are complete and tested. When preparing for a deployment, teams can create release branches to fix bugs in the release version while other developers continue working on new features.
Design and Implement a Pull Request Workflow
A pull request (PR) acts as a gateway where developers propose code changes and invite team members to review them before they merge into the main branch. To maintain code quality, teams configure branch policies that require specific conditions to be met, such as a minimum number of reviewer approvals or a successful automated build. These policies are enforced by branch protections, which block direct pushes to critical branches like the main branch. This structured workflow creates a clear security boundary and review process, ensuring that only verified, high-quality code enters the main codebase.
Implement Branch Merging Restrictions
Branch merging restrictions act as a safety net by controlling exactly when and how code from different branches can combine. These restrictions prevent developers from accidentally merging incomplete features, untested code, or unauthorized changes. For example, a team can block a merge until the code passes a security scan and all unit tests succeed. While a feature branch strategy relies on collaborative code reviews during the isolation phase, a trunk-based development strategy requires tighter automated merging restrictions because developers commit directly to the shared branch more frequently.
Select and Structure Repositories
When setting up source control, teams must choose between a distributed system like Git and a centralized system like Team Foundation Version Control (TFVC). For most modern DevOps teams, Git is the preferred choice because of its superior support for branching, merging, and offline work. Teams also decide how to organize their code, choosing between a single large mono-repo for multiple related projects or multiple smaller multi-repos for independent services. To prevent large files from slowing down repository performance, teams can implement Git Large File Storage (LFS), which replaces bulky assets with lightweight text pointers inside the repository.
Securing source code requires configuring repository permissions to manage who can read, write, or administer the codebase. Azure Repos secures these resources by using security groups, allowing administrators to apply the principle of least privilege across different teams. For instance, temporary contractors might only receive Reader access, while full-time developers are assigned Contributor permissions to write code and create pull requests. Administrators control control-plane operations, such as creating or deleting repositories, to maintain a strict boundary between public and private code assets.