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

Wednesday, 31 May 2017

What can you learn from The DevOps Handbook

I thought about reviewing The DevOps Handbook, but then I realised its real reference value. Books like this, with multiple layers of usage are really invaluable.


























This book is gold IMHO, and not just for its cover colour. But let’s rewind a bit.

I bought the book in January, I read the first few chapters then I forgot it at my parents’. Fast forward a few months, my brother comes visiting and he brings the book back, but it is then then left on the to read pile for a while.

Eventually I managed to find time to read it and here I am writing this post.
So why isn’t this a regular review? What did I realise, all of a sudden?

Well, books can be easily read in a few days, a couple of weeks tops. What happened is that each chapter I read was providing insights or mirrored situations I experienced during these months.

Each chapter can be cherry-picked and adapted to your situation, because it starts from a real scenario with real requirements and targets. You will notice patterns going through the book, all the concepts are there but applied in a tailored way to fit the problems one has to face.

I can see this book being a useful guide you might want to refer to when you are tackling a problem, just pick the chapter more akin to the approach you are using and you will feel guided.

Friday, 19 May 2017

Review - Professional Git

I am asked at least twice in three months about a good book on Git.

Despite the information available at https://git-scm.com/book is very comprehensive, there is value out of a published book to be consumed as a reference, especially when onboarding a new team member or when you finally want to get a firm grip on this (sometimes dreaded) Version Control System.

So I contacted Wrox to get a copy of Professional Git, which was published in December 2016 hence it is not only a reference book but also an updated reference book.


























You might wonder why is this so important to me. Well, it is fairly simple after all. Git became a mainstream tool a few years ago, but its history goes much further back. Documentation on its usage might be older, aimed at advanced users or fragmented, so it is important to have a book not only covering all the important topics, but crucially covering them from the right point of view.

Brent Laster did a brilliant job with this book. I felt the level of depth was perfect, neither too shallow nor too deep. Topics like Submodules – often troublesome for some and quite challenging anyway – are covered with a clarity that would make the essential information memorable.

The book has companion exercises and labs to keep you busy if you are a total newbie. If you are a bit more experienced it is still very valuable, putting down in plain language with straightforward samples even the trickiest of topics.

Just remember that the syntax used for the examples is UNIX-style – hence lots of ls! But aside from that I cannot refrain from suggesting it to who wants to start with Git and is looking for a comprehensive guide.

Tuesday, 9 May 2017

Error 404 when uploading the SonarQube Analysis Report from the Build

That can be something hard to catch if you don’t know where to look!

I spent some time on this issue – SonarQube’s End Analysis task fails, with either an unhandled exception (version 2.1.1 of the extension) or a 404 page in plain text in the log (with the older 2.0.0).

What was really odd was that the issue happened only on certain projects – some were fine, some others were failing, And it happened regardless of the build server used by TFS – whatever the agent, this randomness was there.

At the end of the day, don’t underestimate logs collected from the Web Server you are using: I found an error 404.13 in the logs, meaning the Analysis Report was exceeding the size limit for the upload.

Wednesday, 3 May 2017

What to do with WMI errors and Team Foundation Server

Last week I spent some time on trying to sort out WMI errors in a test environment. That was not fun, but at the end of the day there is something to learn out of it.
Everything starts with this set of errors with an AT-only installation:










Looking at the logs you can see it is pretty bad stuff:








I tried with the usual suspects (wmimgmt /verifyrepository, setting the involved machines as standalone hosts, etc), but they all run fine. One of the suggestions you can find around is to reinstall the IIS 6 Management Tools on the Application Tier:








Still no luck. I tried connecting with wmimgmt.msc and I got all sorts of errors. At the end of the day I temporarily reset the WMI repository on that machine and I then decided to move these test services to another VM. Why?

The WMI repository is not supposed to be rebuilt lightly. It should be the last resort, and I did not want to tie up this testing environment with a potentially problematic machine.
Don’t forget that the Application Tier is just a front-end for Team Foundation Server. You can replace it with another machine and scale out as needed.

Also, the errors above appear in both the Application Tier and Data Tier readiness check category for the AT-only install, despite they only apply to the AT. That is because the machine could not communicate with anything beyond itself (not even itself I would add), so it would report that the Data Tier isn’t reachable. Do not touch the database servers unless you really have to, and the logs are going to tell you if you have.

Tuesday, 18 April 2017

Quickly share query results with the Web Access

If you really like the Copy Query URL button because it opens a full-screen page with no other link to TFS or VSTS...

You would also know that the query link expires after 90 days. Too bad. Is there a way of getting the same behaviour (without taking into consideration any ACL-specific configuration) without using that link?

Well yes - just add &fullScreen=True to the Web Access URL: