Azure Repos

Azure DevOps Repos: Bypass Branch Policies

/ Azure, DevOps / , ,

Last week we covered adding branch policies to a branch in an Azure DevOps Repo and this week we are going to deal with what happens when you need to break the policies you set up for some reason.

Setting Bypass Security

There are a couple of ways to set up bypassing depending on how broadly you want to give someone rights to bypass. We are going to start with the narrower option which is allowing bypass for an individual branch (sadly security options are currently available at the folder level like policies are). Starting from the list of branches for your repo mouse over the branch you want to set security for and click the three dots for the menu and select Branch security.

On the dialog that shows find the user, you want to change for security for, Eric Anderson in this example. After selecting a user their specific setting will be loaded to the right. On Bypass policies when completing pull requests change the option to Allow.

The second option for setting bypass security is at the repo level. From your Project settings under Repos select Repositories and then fine the Branches node under the project you want to set the policy for.

From here it is the same as the branch level. Find the user, you want to change for security for and set Bypass policies when completing pull requests to Allow.

Bypassing Policies on a Pull Request

Now that we have our security setup we are going to walk through what the bypass process looks like. Here we have a pull request that is missing approval by a reviewer.

Now let us say we don’t have a reviewer available for some reason and we need to complete this PR without review. Use the dropdown on the Set auto-complete button and click Complete.

When the PR completion dialog show you will notice a section at the top with a red background that lists out the policies that haven’t been met. With your new-found security, you will also have a section for Policy override options. To proceed and bypass the policies check the Override branch policies and enable merge checkbox, enter your reason for overriding, and click the Override and complete button.

Do note that the fact a PR was overridden is visible on the list of completed PRs and the reason will show when mousing over the bypassed indicator as well as in the details of the PR.

Wrapping Up

Branch policies are great and will help you make sure the code that makes it in your branches are high quality and don’t break your builds. Hopefully, you won’t need to bypass your policies often, but now you know-how without having to temporarily remove the policies or getting people used to blindly approving changes.

Azure DevOps Repos: Bypass Branch Policies Read More »

Azure DevOps Repos: Branch Policies

/ Azure, DevOps / , ,

For the last few weeks I have been doing a series of posts about Azure DevOps Pipelines and I hit a post I wanted to do that didn’t make sense without introducing the Branch Policies feature of Azure Repos. This post is going to assume you already have an Azure DevOps Project with some code in it. If not you can check out my post on Getting Started with Azure DevOps.

Repo Introduction

The repo used here is the same one used in the Pipelines posts linked above and contains two .NET Core 3.1 web applications. The repo also contains three branches (master, releases/1.0, and releases/1.1).

It is worth noting that putting a forward slash in a branch name displays as a folder in the UI as you can see with releases in the screenshot above.

Editing Policies

Mouse over either a specific branch or a folder and it will show the three dots for the menu. Click the dots and then select Branch policies. For this example, we are putting policies on the master branch.

This will bring you to the page that allows you to view and edit the policies on the selected branch or folder.

The descriptions do a good job of explaining what policies do what so I’m not going to bore you with repeating them. The official docs on branch policies also go into a lot more detail. If you are not working along I highly recommend using Require a minimum number of reviews and Check for comment resolution. Build validation I would recommend no matter your team size as it keeps you away from the possibility of having that one magical machine that is the only one your build will work on. The following screenshot is with the first two recommend policies set. The settings shown for the require a minimum number of reviews are based on the fact that my project only has one contributor. After your done make sure and click the Save changes button.

Build Validation Policies

There is a bit more to the build validation policy which is why I’m covering it in a different section. On the Branch policies screen click the Add build policy button.

In the edit build policy screen, the only required change is selecting the Build pipeline to make available when a PR that is targeting the branch that is policy is for. Here we are using the automatic Trigger so any time we push to our remote branch when it has an open pull request it will run the select build pipeline. Policy requirement controls if a successful build is required before the pull request can complete or not. For a since person project Build expiration isn’t a big deal, but if your working with a team it can be helpful. Click Save when you are done.

Back on the branch policies screen, you will see the new requirement listed. You can also add as many build validations as you need.

Wrapping Up

Hopefully this quick little into to branch policies will help your team improve the quality of the code that makes it into your branches. I know to require another person or two to review your code before you can check-in sounds like it will slow you down if you are new to the concept but in reality, it helps catch issues before they make it to QA and production which saves time and money in the long run.

Azure DevOps Repos: Branch Policies Read More »

Getting Started with Azure DevOps

/ .NET Core, Azure, DevOps / , , ,

I have been doing a lot of work lately with our build and release pipelines in Azure DevOps and while it is fresh on my mind I’m going to do a few posts to remind me of some of the things I have leaned and may or may not have gotten to use. This post is going to serve as a jumping-off point for the post that will follow for readers who may not have used Azure DevOps in the past.

Before moving forward make sure and sign up for a free Azure DevOps account.

Create a new Project

When you first log in to Azure DevOps you should end up at something like the following that lists all your organizations on the left, ericlanderson being the sample organization I’m using. In the man section of the page make sure you are on the Projects tab and then click the New project button.

On the next screen, all that is required is a Project name. If you do want to allow public access to the project you will have to tweak an organization policy. Under Advanced you can also tweak how you want to manage work for the project, but that is out the scope of the point of this post. When done click the Create button.

Initialize a Repo

When project creation is complete you will be forwarded to the project landing page as you can see below. Now we want to initialize a new repo for this project. Click Repos button.

Since the sample projects are going to be .NET based I opted to use a .gitignore for Visual Studio. When the options you want are selected click the Initialize button.

When the initialization process is complete you will be taken to a files view of the repo.

Connect to project and clone the repo from Visual Studio

Now that we have the Azure DevOps setup it is time to switch over to Visual Studio and interact with our new project. In Visual Studio all the interactions with Azure DevOps will happen via the Team Explorer window. The first step is to connect to the project. In the Team Explorer window hit the plug icon.

Next, click Manage Connections and then click Connect to a Project.

In the dialog that shows you will need to use the drop-down and select Add an account if you already have an account connected as I do, if not then the process might be slightly different.

After completing the login process with your Azure DevOps credentials you should see your organization listed and under it your project. In this case, the project and repo have the same name. Select the repo and click Clone.

Create Sample Applications

Now that the repo is cloned I’m creating a couple of sample applications using the .NET CLI. Open a command prompt in the root folder of the clone from above and use the following command to create a new Visual Studio solution.

dotnet new sln -n Playground

Next, use the following command to create a new web application.

dotnet new webapp -o src/WebApp1

Then add the new project to the solution file.

dotnet sln add src/WebApp1/WebApp1.csproj

I then repeated the project creation process a second mostly to give us more to work with in future posts. Here are the commands to create the second project and add it to the existing solution.

dotnet new webapp -o src/WebApp2
dotnet sln add src/WebApp2/WebApp2.csproj

Commit Code and Push to Azure DevOps

Back in Visual Studio in the Team Explorer window, we need to switch to the Changes area. There are a couple of ways to get to the changes area. If you are in the home area you can click the changes button.

Another option is to click the current area and select the new area from the drop-down menu. For example, in the following screenshot, I clicked on Branches to show the drop-down and could then click Changes.

Enter a commit message and if you use the dropdown on the Commit All button and select Commit All and Sync it will push all of the changes to the associated Azure DevOps branch.

Wrapping Up

Hopefully if you are new to Azure DevOps this will give you a good jump-off point and will provide a base for some future posts.

Getting Started with Azure DevOps Read More »

Azure Repos and Azure Pipelines

/ .NET Core, ASP.NET Core, Azure, DevOps / , , , , ,

Last week’s post looked at using GitHub with Azure Pipelines. This week I’m going to take the same project and walk through adding it to Azure Repos and setting a build up using Azure Pipelines. I will be using the code from this GitHub repo minus the azure-pipelines.yml file that was added in last weeks post.

Creating a Project

I’m not going to walk you through the sign-up process, but if you don’t have an account you can sign up for Azure DevOps here. Click the Create project button in the upper right corner.

On the dialog that shows enter a project name. I’m using the same name that was on the GitHub repo that the code came from. Click Create to continue.

Adding to the Repo

After the project finishes the creation process use the menu on the left and select Repos.

Since the project doesn’t currently have any files the Repos page lists a number of options for getting files added. I’m going to use the Clone in VS Code option and then copy the files from my GitHub repo. If I weren’t trying to avoid including the pipeline yaml file an easier option would be to use the Import function and clone the repo directly.

I’m not going to go through the details of using one of the above methods to get the sample code into Azure Repos. It is a git based repo and the options for getting code uploaded are outlined on the page above.

Set up a build

Now that we have code in a repo you should see the view change to something close to the following screenshot. Hit the Set up build to start the process of creating a build pipeline for the new repo. This should be pretty close to the last half of last week’s post, but I want to include it here so this post can stand alone.

On the next page select Azure Repos as the source of code.

Next, select the repo that needs to be built for the new pipeline.

Template selection is next. Based on your code a template will be suggested, but don’t just take the default. For whatever reason, it suggested a .NET Desktop template for my sample which is actually ASP.NET Core based. Select your template to move on to the next step.

The next screen will show you the YAML that will be used to build your code. My repo contains two projects so I had to tweak the YAML to tell it which project to build, but otherwise, the default would have worked. After you have made any changes that your project needs click Save and run.

The last step before the actual build is to commit the build YAML file to your Azure Repo. Make any changes you need on the dialog and then click Save and run to start the first build of your project.

The next page will show you the status of the build in real time. When the build is complete you should see something like the following with the results.

Wrapping Up

As expected using Azure Repos with Azure Pipelines works great. If you haven’t yet give Azure DevOps a try. Microsoft has a vast offering with this set of products that are consistently getting better and better.

Azure Repos and Azure Pipelines Read More »