Shift Left with SonarCloud Pull Request Integration

One of our DevOps “habits” is to Shift Left and move quality upstream.  Including additional validations earlier in the DevOps pipeline means identifying potential issues before they become a problem.  For teams using pull requests, catching issues while the PR is active is ideal – the code hasn’t been merged yet, so it’s easy to respond to feedback.  The latest SonarCloud extension for Visual Studio Team Services (VSTS) is a great tool to help identify issues during the PR – let’s take a look at how it works.

To try out the integration, I’ve done the following:

All of this allows SonarCloud to scan my code during the CI builds, and produce reports about the state of my code.  For example, I can see an issue about an empty method in my code:

Empty method code smell from SonarCloud

I can even use SonarCloud to drill in to look at the code that’s causing the problem:

Code view in SonarCloud with inline warning

This is great, but to Shift Left, I want to get that analysis on new changes submitted in pull requests.  That way, problems can be addressed before merging code into the mainline.  To do that, I followed the steps to set up pull request integration with SonarCloud, which involved setting up a new PR build policy for my master branch.

Build policy configuration for master branch

With the policy set up, any new PR will trigger the CI build, which is configured to run the SonarCloud analysis.  After creating the PR, you can see the build running under Required section in the Policies list.

Pull request build policy in progress

When the build runs to completion, I can see that my changes didn’t break the build, but there’s a Code Quality check that failed.  The best part is that I can see exactly what the issues are that caused this failure without leaving the PR view.

Pull request with code quality check that failed

See the code comment in  SonarCloud found that Code Smell and automatically left a comment in the review.  I don’t need to drill into the build results or the SonarCloud analysis report to find the problem code – it’s plain for me to see right in the PR.  And even better, other code reviewers can see and comment on the issue, in case I need some help on the best way to fix the issue.

(Note, I currently have the integration configured to run under my credentials, hence, I’m listed as the comment author, but SonarCloud did the hard work.)

If I want to go even further, I can set up a policy to require that the Code Quality check must succeed for all pull requests.  I can do that by creating a new status policy for the master branch.

Add status policy

Simply pick the SonarCloud quality gate from the list, and click Save.

SonarCloud quality gate policy configuration.

Now, if there are a failures, the PR will be blocked from merging until all of the issues are fixed or marked as confirmed or resolved in SonarCloud.

SonarCloud failing quality check blocks pull request merge

With this policy in place, I now have the confidence that my code is going to meet a higher quality standard before it reaches the master branch.  Having this integration as part of my pull request is a natural extension of the PR workflow – I can review the SonarCloud comments like I would any other reviewer’s comments, and work through them one by one to resolve all of the issues before my code is merged.  This is the heart of what it means to Shift Left.

If you want to try out the SonarCloud extension, check out the hands on lab to Integrate Visual Studio Team Services with SonarCloud.

Happy coding!