Introduction
In a customer workshop earlier this week, Hans mentioned a very nice tool (SonarCloud). He used it “in his previous life and was very enthusiastic about it. So this immediately triggered my curiosity… 😉 As it is free for public projects, I investigated how easy it was to integrate into my existing pipelines. Which turned out to be quite easy! After browsing around a bit on how to integrate it into a YAML pipeline, I can proudly say that VMchooser is now fully hooked up with SonarCloud.
However, it did confirm my suspicion, that I am a lousy developer! 😉 Though better lousy code fulfilling a purpose than having no alternative at all?!?
Anyhow, today’s post is about the experience of moving existing pipelines to SonarCloud and investigate the results you get out of it.
Creating your SonarCloud Organization & Projects
Once you registered and created your organization, you can create your first project.
Initially, it will just show this message… That is fine for now!
As some additional prep work, go to your account, then “my account”.
Next up, go to the security tab and generate a token ;
Copy it for later on, as we will need it to create a service connection in Azure Devops. 😉
SonarCloud Documentation & YAML
The link you see after the creation of a project in SonarCloud …
… is more oriented towards setting it up via the GUI flow and not the YAML flow.
For YAML, check out the links in the SonarCloud Azure DevOps extension page (see below). This will help you get kickstarted with YAML!
Configuring your Azure DevOps Organization
In Azure DevOps, add the SonarCloud extension.
And afterwards create a service connection in Azure DevOps with the token you generated in SonarCloud ;
Integrating into an existing pipeline
The integration bit is quite easy… Before the build step(s), you add the SonarCloudPrepare task/step. And Right after you add the SonarCloudAnalyze to do the quality check and the SonarCloudPublish to publish the results.
(The above sample is for a manual CLI check. Check the backend sample below for a .NET/C#/MSBUILD example).
You might have noticed that there are some variables in there… So those you of course add to your pipelines.
- SonarCloud ; The name of the endpoint, “vmchoosersonarcloud” as shown above.
- organization ; lowercase organization name in sonarcloud
- ProjectKey = lowercase project name in sonarcloud
- ProjectName = my impression it is more free format…
Want some inspiration, check the following pipelines ;
- VMchooser Frontend ; https://github.com/vmchooser/azure-vmchooser-frontend-v3/blob/master/.pipelines/functionapp.yaml
- VMchooser Backend ; https://github.com/vmchooser/azure-vmchooser-backend-v3/blob/master/.pipelines/functionapp.yaml
If you now run the pipelines, you will see the additional tasks running ;
Where the actual analysis does not take that much time…
The results in SonarCloud
Now let us check what the results are of this integration … In our organization we get a nice overview of the different projects we have.
And we can drill through in the results per project of course ;
When checking (for instance) the vulnerabilities…
We can go even deeper and go straight to the code.
Where we will also be prompted with the rationale behind it being flagged!
Where the same flow goes for other issues of course!
Closing Thoughts
Hans was right… Value straight out of the box without too much hassle of integrating. You even get a nice badge to put in your repo if you want! 😉
You can configure the way you want to handle the quality checks too. For instance, with new projects you can have stricter guidelines straight off the bat. Where with existing projects, you can use a more phased approach. For instance, start with a barrier of X% code coverage at first, and increase it with Y% per month.
Want to check it out yourself? VMchooser‘s code is public, and so are the SonarCloud results!
Karim Vaes 