Using custom Quality Profiles with SonarQube and the new Team Build

When you analyse a project with SonarQube you are running the analyser with a predefined set of rules – they are the most commonly used rules, but not the most comprehensive.

This has a lot of sense, because you might not want to end up cluttering the dashboard with tons of information you don’t actually need or that you can’t work on now.

Here is where custom Quality Profiles come into play. For example, I might want a specific build definition to be used for Code Analysis with all the rules enabled.

After creating a new, empty Quality Profile all I need to do is to search for the rules I want and add them to my custom profile. Searching is quite a powerful experience – you can rely on really a lot of criteria, aside from the simple search on the name.

But in this case, the name (CA, which is the code for each Code Analysis rule ran by Visual Studio) will do:

Here you can select which rules you want to go into the profile. If you want all of them, just go for the Bulk Change button on the top right hand side:

You need to type in the name of the profile now:

That’s it!

Now you need to create a new SonarQube project to use this custom quality profile:

From the Administration menu, select Quality Profiles so you can change the default one with your custom profile:

Eventually, configure the new build definition with the same parameters for the SonarQube analyser:

Now you can run the build as usual, and this project will have different results (of course!).

Small but very valuable nuggets about Work Item Tracking in TFS and VSTS

Have you ever noticed this couple of small but very useful features in Team Foundation Server and Visual Studio Team Services?

You can query across projects – think about it, you can create a cross-project (in case you are not using the One Team Project approach) query which can be pinned in the main dashboard. A very minor thing bringing a lot of value to certain roles.

You can compare different fields! I realised this a few days ago (my bad!), and I think it dramatically improves the custom queries’ experience, given that you can build a result based on field comparison.

A new experience with Work Items deletion in VSTS

With Team Foundation Server you can either remove a Work Item by changing its state (leaving it on the backlog then, not really a removal) or permanently destroy it. No middle ground, no real choice if you need to clear the backlog.

With Visual Studio Team Services instead you have this middle ground, with the Recycle Bin.

It is literally that – you can now delete a Work Item via the context menu and it would be gone, moved to the Bin. Pretty much like a file.

Of course it isn’t actually destroyed (only witadmin destroywi can do that, and it needs confirmation for doing that), but it is only hidden from the backlog. All the traceability is retained, which is very handy.