Azure DevOps Branching Strategy

In this blog Azure DevOps Branching Strategy, you will learn how you should use branching to support multiple releases and patch versions over a period of time. Git branches aren’t much more than a small reference that keeps an exact history of commits, so they are cheap to create. Committing changes to a branch will not affect other branches, and you can share branches with others without having to merge the changes into the main project. Create new branches to isolate changes for a feature or a bug fix from your master branch and other work.

Azure DevOps Branching Strategy
Azure DevOps Branching Strategy
Azure DevOps Branching Strategy
Azure DevOps Branching Strategy
Azure DevOps Branching Strategy

Branch policies are an important part of the Git workflow and enable you to:

· Isolate work in progress from the completed work in your master branch

· Guarantee changes build before they get to master

· Limit who can contribute to specific branches

· Enforce who can create branches and the naming guidelines for the branches

· Automatically include the right reviewers for every code change

· Enforce best practices with required code reviewers

Azure DevOps Branching Strategy

Code reviews are a best practice for most software development projects. To require teams to review their changes before completing a pull request, select Require a minimum number of reviewers.

The basic policy requires that a certain number of reviewers approve the code with no rejections.

If Requestors can approve their own changes isn’t selected, the creator of the pull request can still vote Approve on their pull request, but their vote won’t count toward the minimum number of reviewers.

If any reviewer rejects the changes, the pull request can’t finish unless you select Allow completion even if some reviewers vote to wait or reject.

You can reset code reviewer votes when new changes are pushed to the source branch. Select Reset code reviewer votes when there are new changes.

Azure DevOps Branching Strategy

Require associations between pull requests and a work item to ensure that changes to your branch have work item management tracking. Linking work items provide additional context for your changes and ensures that updates go through your work item tracking process.

Azure DevOps Branching Strategy

Configure a comment resolution policy for your branch by selecting Check for comment resolution.

Image for post

Maintain a consistent branch history by enforcing a merge strategy when a pull request finishes. Select Enforce a merge strategy and pick an option to require that pull requests merge using that strategy.

Azure DevOps Branching Strategy

Set a policy requiring changes in a pull request to build successfully with the protected branch before the pull request can be completed.

Azure DevOps Branching Strategy

Build policies reduce breaks and keep your test results passing.

Build policies help even if you’re using continuous integration (CI) on your development branches to catch problems early.

External services can use the PR Status API to post detailed status to your PRs.

The branch policy for additional services brings the ability for those third-party services to participate in the PR workflow and establish policy requirements.

Azure DevOps Branching Strategy
Azure DevOps Branching Strategy

Select reviewers for specific directories and files in your repo.

Azure DevOps Branching Strategy

These reviewers are automatically added to pull requests that change files along those paths. You can also specify an Activity feed message.

Image for post

Bypass branch policies:

There are several permissions that allow users to bypass branch policy.

In Azure DevOps Services, the Exempt from policy enforcement permission does not exist. Instead, there are two new permissions:

· Bypass policies when completing pull requests

· Bypass policies when pushing

Azure DevOps Branching Strategy

Users that previously had Exempt from policy enforcement enabled now have the two new permissions enabled instead.

In some cases, you need to bypass policy requirements. Bypassing lets you push changes to the branch directly or complete a pull request even if branch policies aren’t satisfied.

Branch Securities:

· Set up permissions to control who can read and update the code in a branch on your GlTrepo.

· You can set permissions for individual users and groups and inherit and override permissions as needed from your repo permissions.

Azure DevOps Branching Strategy

· Remove permissions for a user or group by selecting the user or Azure DevOps group, then selecting Remove.

· The user or group will still exist in your Project and this change will not affect other permissions for the user or group.

Azure DevOps Branching Strategy

Branch Lock:

· Prevent updates to a Git branch by locking the branch. Locking a branch prevents other users from changing the existing commit history.

· Locking also blocks any new commits from being added to the branch by others.

Azure DevOps Branching Strategy

· Locking is ideal for preventing new changes that might conflict with an important merge or to place a branch into a read-only state.

· Locking does not prevent cloning of a repo or fetching updates made in the branch into your local repo.

Azure DevOps Branching Strategy
Azure DevOps Branching Strategy

Restore a deleted Git branch:

· We can restore a deleted Git branch via the web in Azure Repos or TFS 2019.

· If you need to restore a Git branch in your own repo from Visual Studio or the command line, push your branch from your local repo to Azure Repos to restore it.

· Open your repo on the web and select the Branches view.

· Search for the exact branch name using the Search all branches box in the upper right.

· Click the link to search for an exact match in deleted branches. If there is a deleted branch that matches your search, you will be able to see which commit it pointed to when it was deleted, who deleted it, and when it was deleted.

Azure DevOps Branching Strategy

· To restore the branch, select the … icon next to the branch name and then select Restore branch from the menu. The branch will be recreated at the last commit to which it pointed. Note that branch policies and permissions will not be restored.

Azure DevOps Branching Strategy

Compare Branches :

· The ahead of and behind numbers listed for each branch are in comparison with the branch currently labeled Compare on the Branches page. Update your compare branch to see how far ahead or behind your branches shown on the page are to another branch in your repo:

Azure DevOps Branching Strategy

· Select the … next to the branch you want to set as the baseline for comparison.

Azure DevOps Branching Strategy

· Select Set as compare branch.

· The Compare label will move to this branch and the other branches on the page will have the number of commits ahead/behind updated to reflect the new comparison.

Azure DevOps Branching Strategy

Successful Git branching model:

This model was conceived in 2010, now more than 10 years ago, and not very long after Git itself came into being. In those 10 years, git-flow (the branching model laid out in this article) has become hugely popular in many a software team to the point where people have started treating it like a standard of sorts

Azure DevOps Branching Strategy
Author: Vincent Driessen Original blog post: http://nvie.com/posts/a-succesful-git-branching-model License: Creative Commons BY-SA

The main branches :

The central repo holds two main branches with an infinite lifetime:

  • master
  • develop

The master branch at origin should be familiar to every Git user. Parallel to the master branch, another branch exists called develop.

Azure DevOps Branching Strategy
Author: Vincent Driessen Original blog post: http://nvie.com/posts/a-succesful-git-branching-model License: Creative Commons BY-SA

Supporting branches:

After, the main branches master and develop, our development model uses a variety of supporting branches for parallel development between team members, and tracking of features, production releases and to assist in quickly fixing live production problems. Unlike the main branches, these branches always have a limited lifetime(short-lived), since they will be removed after the work is completed.

The different types of branches we may use are:

  • Feature branches
  • Release branches
  • Hotfix branches
Azure DevOps Branching Strategy
Author: Vincent Driessen Original blog post: http://nvie.com/posts/a-succesful-git-branching-model License: Creative Commons BY-SA
Azure DevOps Branching Strategy
Author: Vincent Driessen Original blog post: http://nvie.com/posts/a-succesful-git-branching-model License: Creative Commons BY-SA

Related Courses

VILT & Self-Paced
Azure Developer Certification

AZ-204: Developing Solutions for Microsoft Azure

This self-paced course will help you prepare for the Azure Developer certification exam AZ-204: Developing Solutions for Microsoft Azure.

BUY NOW

Self-Paced
Azure Developer Certification

AZ-900: Microsoft Azure Fundamentals Tutorial

AZ-900: Microsoft Azure Fundamentals Tutorial provides foundational level knowledge on cloud concepts; core Azure services; security, privacy, compliance, and trust; and Azure pricing and support.

BUY NOW

Self-Paced
Azure DevOps Online Course

AZ-400: Designing and Implementing Microsoft DevOps Solutions

This self-paced course will help you prepare for the Azure DevOps certification exam AZ-400: Designing and Implementing Microsoft DevOps Solutions.

BUY NOW


Sharing is Caring

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top