Azure DevOps (VSTS) security and policies (part 4)

In our last post we covered the Pull Request process and problems with leaving merged feature branches. But what about validating the code in a pull request before merging? What does AzDO offer by way of PR pre-merge validation? The answer is Pull Request builds for which we can leverage in PR policies as well.

Pull Request Builds

Once we are ready to build code, we create Build and Release Pipelines in Azure DevOps Pipelines. We can trigger Continuous Integration through a CI trigger in our Build Jobs and we can use Pipelines to validate code prior to merging as well.

Example:

Let’s create a quick React App:

npm init react-app ./test-react-app

cd test-react-app

npm install --save jsonlint

Create a quick testing.json:

{
"test" : "value",
"another" : "value2"
}

5. Change line 7 , the test script, in the package.json to test our file:

This works, however, we now have a branch that is out of date (it’s missing the merge back) and restores to a used branch name!

Branches view in our Repo

Of course, i immediately deleted the branch (trash can icon in red above). So we can push to a new branch, i’ll want to go back to develop, update, then create a new branch and merge these changes into it:

Testing:

Let’s use the standard user and go to the repository - we are prompted to create a PR:

PR Creation from the Repo files view

Once created, we see a PR build is automatically queued:

The play icon in the Policies section shows that a "PR Build [is] in progress"

This should pass:

A passing build

However, what happens if we break the file again? It should block the PR, even if others approve:

Build running after an approval

We see that it was approved by the Reviewer (in the left hand history) but then when I pushed another change (listed as “update 2”), it reset the vote and triggered a PR build.

That failed as i added a mangled json:

A failed PR build

When we look at the build history, PR builds are immediately called out. The “branch” column lists PR number instead of the root branch. This lets us know that it was built for the purpose of validating a PR versus a CI trigger on branches.

Pipeline Build History showing PRs and Branches in the Branch Column

Summary:

The point here is we can validate all PR code through a build process. This allows us to exercise the code in whatever ways are meaningful. In this case, I added a basic linter to the npm test which would easily catch json issues and automatically prevent them from being merged into the mainline “develop” branch. You can expand on this to do proper unit testing with Mocha / Chai.