We’re moving toward DEVOPS with our team and want to automate code quality checks. Another team already installed a SonarQube server for their python development and advised us to try it for our dotnet development. Now we know why the other team is stocked about SonarQube. We are sure you will be setting this up for your own team when you see how easy the setup is and the huge quality gain it brings.
First add a new service endpoint to your TFS by going to settings > services. Put in the url (root of the sonarqube server: http://your_sonar_server) and your token (generated in sonarqube, hover over the icon at the end of the input) and give it a suitable name.
After installing the sonarqube build tasks on TFS and adding javaruntime to your build agents you can add sonarqube to your builds. There are three tasks you should add: prepare, run and publish. Only the first task (prepare) needs to be configured to the service endpoint you created before. The project key and project name are up to you and will be created if they don’t exist (like the first time you run the build) We’ve set the project version to the buildnumber which is not the case in this screenshot.
Now queue a build and watch sonarqube do it’s magic in the logging. You’ll notice the actual analysis is done on the build agent, not on the sonarqube server. This is why you need the java runtime on the build agent. After the publish you can browse to the sonarqube server and find your project in the list of projects. Open the details page and find something like below:
The bugs are mostly caused by not validating parameters like assuming not null.
Vulnerabilities are about known security issues.
Code smells tell you about to much nesting of to much if statements.
Code coverage from unittests is reported.
Duplication reports duplicate code.
Everything combined gives you the technical debt.
You can setup rules (or use the default) that determined the quality gate result. Make sure you’re in the green