Thursday, 22 June 2017

A few nuggets from using TFS/VSTS and SonarQube in your builds

The cool thing about SonarQube is that once it is set up it works immediately and it provides a lot of value for your teams.

After a while you will notice there are things that might be refined or improved in how you integrated the two tools, here are some I feel can be quite useful.

Bind variables between Team Build and SonarQube properties

I feel this is quite important – instead of manually entering Key, Project Name, Version, etc. you should be using your variables. Try to reduce manual input to a minimum.

Branch support

SonarQube supports branches with the sonar.branch property. This would create a separate SonarQube project you can use for comparison with other branches.

Analyse your solution once

Don’t be lazy and add just a task at the beginning and one at the bottom - you should scan one solution at the time and complete the analysis. This will solve the typical Duplicate project GUID warning you will get if you have multiple solutions in the same scan.

Exclude unnecessary files

It is so easy to add a sonar.exclusion pattern, do it to avoid scanning files you are not interested in.

Wednesday, 14 June 2017

How a (home)lab helps a TFS admin

I’ve always been a fan of homelabs. It is common knowledge that I am a huge advocate of virtualisation technologies, and pretty much all my machines feature at least Hyper-V running on them.

If you are not familiar with this, a homelab is a set of machines you run at home which simulate a proper enterprise environment. This does not mean a 42U cabinet full of massive servers, but even just a decently-sized workstation acting as VM host would do. The key here is enterprise, so ADDS, DNS, DHCP, the usual suspects indeed, plus your services.

What I am going to talk about is applicable to corporate labs as well, albeit this can be less fun Smile

So, if you are a TFS administrator, what are the advantages of a lab?

Testing upgrades!

Yes, test upgrades are one of the uses of a lab. But not just testing the upgrade itself, it also helps understanding how long an upgrade will take and what are the crucial areas you need to be aware of.

In an ideal world, you will have an exact copy of the production hardware so you might be able to have a very accurate forecast. This helps of course, but it will also hide what are the critical areas in your deployment.

Let’s take TFS 2017  – one of the most expensive steps is the migration of all the test results data in a collection to a different schema.

This is a very intensive operation, and having a lab where you know inside-out any finer detail about your hardware really helps when it comes to planning the proper upgrade, especially if you have a large deployment.

Without mentioning that in case of failure you are not breaking anybody’s day and you can work on your own schedule.

Also, you will find that sometimes you might need to experiment with settings that require a service interruption. The lab is yours, so you are not affecting anybody again and you can go straight to the solution when it comes to the production environment.

All of that sounds reasonable and maybe too simplicistic, but I saw too many instances where there was no lab and the only strategy was test-and-revert-if-fails, given that Team Foundation Server is “just a DB and IIS” (yeah…).

Definitely not something you want to see or hear, trust me Smile