One of the most commonly used parts of Azure DevOps is the repositories feature or repos for short. It provides you with the functionality to store and maintain your source code artefacts in one single place and have developers from all over the world securely work on your code. Let’s take a closer look at this feature.
Repos in Azure DevOps are great, it’s actually really difficult for me to pick a single feature which I enjoy the most. So instead, let me start with a few highlights that I really like.
- You get free unlimited private repositories with your project
- You can use any Git client that takes your fancy
- The level of integration with other tools is incredible
- Comes with a powerful and simple to use code search
- Branching policies are great for protecting code quality
I really want to look at a couple of features in particular which are not unusual but certainly from experience don’t get used a whole lot. These are branch policies and web hooks.
First of all, how do we get to branch policies. Go to your Settings and then under the Repos header, click Repositories. On here click the repository in question and then in the main window, click Policies. You will see that with a brand new repository, you don’t have any options, because the repository has not initialised yet.
You can also set branch policies across all repositories in a project if your project has multiple repositories. Simply click Policies in the main All Repositories window and you will be able to set global policies within the scope of that project. You can protect all default branches or use a pattern to define the branches to protect.
Click the name of the branch you would like to set a policy on and you will then be presented with a number of options for your policy settings.
One feature I really like is that if any of the policies are enabled, that restricts the ability to delete the branch and any changes must be submitted through a pull request.
Requiring a number of reviewers sets the number of people who must approve pull requests on the branch. You can then specify if those people can approve their own changes, prohibit the the most recent pusher from approving their own changes, allowing completion of the request even if votes are waiting and finally reset votes when new changes come in.
The last option is especially useful when you send back for additional work, this effectively restarts the voting process so you can vote on the new changes.
Check for linked work items looks looks to increase the traceability of pull requests by enforcing that work items are linked to commits of code, you can make this option either mandatory or optional.
With check for comment resolution, you have the ability to again either mandate or make optional a check on all comments on the pull request, if mandatory, these comments must be resolved.
Limiting merge types enables you to control the branch history on the repository by limiting the available merge types when those pull requests are completed. Options available are; Basic merge, squash merge, rebase and fast-forward and rebase with merge commit. More information can be found on this blog post on merge types.
Azure DevOps allows for the adding of build validation, status check filters and the ability to automatically include reviewers based on a folder path, which includes the ability to add wildcard patterns.
This can be useful especially when you have teams with both developers and infrastructure specialists for example, you want to ensure that developers review application code and infrastructure engineers review IaC code.
The web hook functionality, formally known as Service hooks enables the integration of numerous third-party tools and applications as well as a number of other Microsoft tools into the Azure DevOps tool chain. Some popular integrations include; Microsoft Teams, Slack, Trello, Datadog, Grafana and many more.
However, what if integration is not available for your desired application? Well, luckily the ability to create a web hook also exists within service hooks. A huge number of events are supported, however lets look at an example for repositories.
In this scenario, we will send an event to our custom endpoint letting us know when a pull request has completed. In this example, the endpoint is a service management tool and we will use the pull request hook to create a change request in our system.
So first of all, in your Project Settings, click Service hooks under the General heading, then click the Create subscription button, from the list that appears, select Web Hooks and click Next.
On the Trigger screen, set your event as Pull request created and then select any appropriate filters. You can filter the trigger to only fire on a specific repository, branch, when the pull request is from a specific group or the reviewer includes a specific group.
Once you have your configuration defined, click Next. Web hooks work by sending a POST request via HTTP, so you need to setup the URL, for this example and demo, I’m using an endpoint created on RequestBin.
For a live endpoint, you would need some level of authentication and additional headers. However for this demo, this is not required.
You can then define which level of details you want to send, either all, minimal or none. Choose based on your needs and only send what is required. Next you can choose the messages to send, again, pick the option most appropriate to your requirements. When you have finished, go ahead and click Test.
You should see a test message created to your endpoint, your window should look something like this.
You can click through the headings at the top to see the raw request and response from the endpoint as well as the raw event details which are sent. Let’s head over to RequestBin and see if we got the request.
Indeed we did, let’s interrogate this in more detail. You can see the message originally sent was “Jamal Hartnett created a new pull request”. If we look closer at the request payload, we should be able to see that message come through.
As you can see from the screenshot above, we can indeed verify the message has come through and the message is as expected from the original request.
As you can see, other than your typical expected features within repositories, some extras are also included. I particularly like the web hooks feature for integration and obviously in the real world you could do much more with this information.