If you care about code quality and maintainability, then a static code analysis tool is a must, and the earlier in the process the developers know about a problem, the cheaper it is to fix. With this in mind, we, like many other teams, have code reviews through Pull Requests on every single piece of code that makes it into our product. Thanks to Microsoft doing such a great job with TFS/Azure DevOps, the process is very fast and intuitive, and quite comprehensive.
Our team follows a process adapted from Microsoft’s Release Flow [see: https://devblogs.microsoft.com/devops/release-flow-how-we-do-branching-on-the-vsts-team/], in which we create a branch off develop (our long-running mostly-stable product), do our work, commit it (with the PBI/Bug number in a comment), push the branch, then go into TFS and create a pull request. TFS will suggest a shortcut link to create a PR for the branch you just pushed to your default branch (in our case develop); or you can click the New pull request button and choose your source and target branches.
On the next step, it auto-links our Work Items (extracts it from the commit message), defaults the description to the last commit which we can modify, and one more click to create it and done. The whole process takes roughly 15 seconds from commit to PR.
For a more complete description of our workflow see Application Lifecycle Management / World-Class DevOps
Depending on your environment, either create a SQL account, or grant permissions to a service domain account. I recommend a domain account as best practice, with a proper password rotation policy, and running SonarQube as a service with that account using Integrated Security. As per SonarQube’s documentation (https://docs.sonarqube.org/latest/setup/install-server/):
Open the sonar.properties file in the conf folder (ex: C:\SonarQube-7.4\conf\sonar.properties) and set the sonar.jdbc.url property, and make sure sonar.jdbc.username and sonar.jdbc.password are commented out:
This guide describes the process very well and it’s what we used: https://jessehouwing.net/sonarqube-configure-ssl-on-windows/
Once set up and logged in as an administrator, navigate to the Administration -> Marketplace section. This is where you’ll find most of the plugins. There are a few plugins that we use which aren’t in the list, but you can find them linked from SonarQube’s Other Plugins section. We use the following:
The ones not available in the marketplace can be downloaded from the releases tab on github (or compiled yourself) and dropped into the [sonar directory]\extensions\plugins directory. You can do this while the service is running, in parallel to installing plugins through the marketplace
Once you installed all the plugins you want, you’ll need to restart the service
First, set up a build definition to build your solution (see https://devscriptbuild.wordpress.com/2017/05/09/creating-a-build-definition-in-tfs-2017/ for a guide on the first part)
Install the SonarQube TFS/Azure Pipelines extension: https://marketplace.visualstudio.com/items?itemName=SonarSource.sonarqube
In the build steps, insert the following before your Visual Studio or MSBuild steps:
Click on the
Under Generate Tokens enter a descriptive name for your TFS and click
Set the Display Name to “OWASP Dependency Check” so it’s easy to see in the logs Set the Tool path. Ex: C:\tools\dependency-check\bin\dependency-check.bat Set the Arguments
--project "$(Build.DefinitionName)" -f ALL -s "$(build.artifactstagingdirectory)" --suppression "$(Build.SourcesDirectory)\cve-suppression.xml" -o "$(Agent.BuildDirectory)"
—project is the name of your project as you want it to appear on the generated report -f lets you specify the report to generate (xml, html, etc). In this case ALL makes sense for us -s is the path to the directory you want scanned. We scan the compiled build since we only care about the dependencies that make it into our build, but make sure to understand the difference before you choose —suppression lets you specify a list of CVEs to ignore during analysis. This is useful to exclude false positives from future analysis -o is the directory to write the report to Add a Run Code Analysis task This task uploads the SonarQube and dependency check reports to the SonarQube server Add a Publish Quality Gate Result task This displays the Quality Gate status in the build summary and gives you a sense of whether the application is ready for production “quality-wise” Save the build definition and Queue a new build on your main branch (ex: develop). This will analyze the branch and upload the results to your SonarQube server
Click the gear icon on the line with your product branch and click Rename Branch
Enter the name of your product branch as it exists in TFS
SonarQube can comment directly on the line of code it found an issue in, directly in the Pull Request.
Configuration -> Pull Requests choose
VSTS / TFS as your provider
Go to your
VSTS / TFS and generate a Personal access token:
Click on your profile picture (top right) -> Security
In the Personal access tokens tab click
Add, then give it a descriptive name
Expires In based on your token rotation policy
Authorized Scopes choose Selected scopes and select Code (read and write)
Copy the access token and enter it into the
Personal access token field in SonarQube
Click on the
... next to your main product branch (ex: develop) and click
Check for comment resolution. This requires comments to be resolved before completing the PR.
Next under Build validation click + Add build policy
Under build definition select the build definition you created earlier, set the trigger to
Automatic, the policy requirement to
Required and you can set the build to be invalidated if the target branch is updated; then click
Next create a
Pull Request and wait for the build to complete
The first time the sonarqube server updates a PR, it registers a new status policy, which we can set to be Required
Open the branch policy page again
Under Require approval from external services click
+ Add status policy
Select the SonarQube/quality gate policy. Under Advanced, you can optionally select the identities that can update the status and apply filters or reset conditions
Save changes on the branch policy