So, we've set up these code analyzers, Roslyn, FXcop, and SonarCloud, and they are providing us with a wealth of information. But what we really need is this data to be used in preventing poor quality builds from being deployed. One way we can do this is set up branch policies so that pull requests to the main branch have to pass through certain quality gates for the code to be merged. I've created another branch called DBRework and I've made a bunch of changes to my code which I'm going to commit to the rework branch and then create a pull request to the master branch, which will have a branch policy set. The branch policy will use information from SonarCloud analysis to decide if the merge should be allowed.

If I go to branches and then to the context menu of the master branch, I can select branch policies. In a real-world situation, we would check require a minimum number of reviewers and we wouldn't let me review my own code, but obviously for the sake of demonstration, I will just leave those checkboxes unchecked. Under build validation, I'm going to add a build policy. I'll select the pipeline and give it a name and hit the save button. I've left the trigger on automatic so that the source branch will be built on changes committed, thereby triggering the SonarCloud quality gate.

To integrate SonarCloud into my branch policy, I'll need to get a token. So, I go into my user account settings, and under security, select personal access tokens. I'll give it the name SonarGateCheck. And I need to give it read and write access to my source code. So, this has been created, but I need to grab the access token that I'll use in SonarCloud to give access to my pipeline. Next, I'll go into my SonarCloud project and under administration menu, choose general settings and then pull requests. Under the provider, choose Azure DevOps, services and the personal access token. Paste that token that we've grabbed from the Azure DevOps account.

Right, so back in the DevOps project, I'll create a pull request to pull the commits from my DB rework branch to master, and it sets off a build. I know what you're thinking, so what? Nothing's happened yet. Well, we haven't finished. Let's go back to branch policies, and this time I will go down to require approval from additional services and click the add status policy button. Having set up the connection with the personal access token in SonarCloud, the quality gate is now available to choose from the status to check drop-down list, which was not the case before. I'll select my SonarCloud quality gate and save.

Back in Visual Studio, I'll make a few more code changes and commit them, and then sync those changes back to my repo. Again, that triggers a build, but this time data from SonarCloud is going to come back, and we can see Sonar comments are visible inside the pull request overview. More importantly, we can see here on the upper right, the quality gate check failed. I've been back into the code and fixed the bugs and re-run the build pipeline, and this time we can see it has passed the quality gate.

So, a little workaround to suppress those warning messages is to insert pragma warning disable and then the code of the rule you want to have suppressed. There is a full listing of all the analyzer rules on the docs.microsoft.com site with detailed explanations and examples of how the rule is violated and how to fix those violations.