Before starting development, the solution architect should also decide on the right branching strategy for Azure DevOps, which can be useful in the following scenarios:

• When a stable version is needed for testing while the development work continues in other areas.
• When multiple development teams are working on a set of features that are independent, but each team also depends on the features that have been developed by the other teams. You need to isolate the risk of the changes made by each team, but you will need to merge all the features together into one product.
• When the implementation is being carried out in multiple phases, one phase that is in production may need continuous support, but the team may be working on the next phase.

The following are some popular branching strategies typically used in operations projects:

• The main only strategy: This is the simplest and most basic branching methodology, where one branch is created and all the developers check in the changes to the main branch. The build machine can be used to create a build-out of the Main branch to be released for testing and, later, for the production environment. The following screenshot shows only the Main branching strategy:

• The development and main branching strategy: The development and main branching strategy introduces one or more development branches from the main branch, which enables the concurrent development of the next release, multiple projects running in parallel, experimentation, or bug fixes in an isolated development branch. The following screenshot shows the Main and Dev branching strategy:

• Development, main, and release: If you expect to be performing emergency break fixes outside of your normal release schedule, create a release branch. The release branch represents the code that exists in production. The following screenshot shows the branching strategy with release:

• Development, main, and multiple release: If you are an ISV, developing vertical solutions, and want to manage and support multiple versions of your solutions, you can create multiple release branches of the service-specific product version. The following screenshot shows the multiple-release strategy: