Creating a Pull Request workflow in Azure DevOps

Photo by rawpixel.com from Pexels

Background

I’ve recently moved from a client with a very mature microservice architecture to one whom is just embarking on their microservice journey; mature vs green, AWS vs Azure. I had some ideas about how we should work, discussed them with the team and we set off to quickly make them reality. Or so we thought!

To provide some context, I have used the Trunk Based Development (TBD)¹ model successfully before, using GitHub Pull Requests and Thoughtworks GoCD. There are some great plugins for GoCD that integrate with GitHub that allow teams to validate their Pull Requests with the same rigour as that applied to the trunk.

In summary, we would like the master branch (the trunk) to be protected, and only changed via a Pull Request (PR). Such PRs should only be accepted if the same test suite that is applied to master is successful. Assuming PRs are up-to-date, we will have confidence that the trunk remains intact when the PRs are accepted.

What else?

Personally, I like to see the PR acceptance being subject to an approval too. If a pair have worked on the changes, then either should be able to approve the PR. If only a single person has been involved, then someone else should have to approve the PR. This ensures that at least 2 pairs of eyes have seen every change. Obviously more people can be involved in the approval process if you wish.

I also recommend squashing multiple commit PRs into a single commit on the trunk (the PR branch can be kept alive for a period of time for reference if necessary). For me this has a few benefits; a) it removes any changes that were reverted across commits, any tiny iterative commits and also people’s brain farts, b) it streamlines the trunk history into a single serialisable list of commits, removing potential hideous Git trainlines and allowing developers to easily see what’s changed, c) assuming only the net changes are reviewed, these will be the contents of the squashed commit.

Cracking on

One of my reasons for writing this post was due to the lack of resources in this area. I’m new to Azure and Azure DevOps, but familiar with the concepts of this workflow, so find it incredibly frustrating when I can’t…