Use the SonarQube Scanner with the new activity for the Team Build

As I mentioned the new SonarSource-maintained activity allows for the SonarQube scanner to be run independently of MSBuild – very useful for repositories containing only JavaScript files for example, where you cannot use the MSBuild-based task because of the lack of a .*proj file.

So all you need to do is to add the relevant task to your build definition:

You only need to configure the required options in the task - it comes with a pre-configured sonar-scanner.properties file so you are ready to go!

You need to create a SonarQube Endpoint like described in the other post, add the typical project key/name/version property triplet and, if you want, you can change the folder containing the source files. Also, if you have your own sonar-scanner.properties ready for use you can supply it in the Advanced pan:

Scenarios where you might want to use this task are where you don’t have a MSBuild-based project system supporting your code, so the other task would not work. Also, it is very handy with heterogeneous projects.

The new connected extension installation experience in TFS 2017

A few months ago I blogged about how the Marketplace takes advantage of the shared TFS and VSTS architecture to provide a good experience to the administrator when it comes to Extensions.

Now the experience goes from good to excellent with TFS 2017!

The installation experience is now completely seamless. From my local TFS Gallery I can browse the Marketplace like I always did:

By clicking that link I am going to be redirected to the Marketplace, but even if I am not logged in as a user I will be logged in as a server:

This is done on the Team Foundation Server instance you are using, if you look at the URL you clicked you can see a serverKey attribute in the query string.

Now I can browse the Marketplace and select whatever I am interested in. Let’s say the Countdown Widget:

Clicking on Install is going to trigger the installation, already pointing at the local TFS Gallery – the extension was already downloaded for you, this happened as soon as you clicked on Install:

That’s it!

It is a great improvement as the experience now no longer requires manual interaction with the server.

This is also an excellent example of a good experience in a context of a Hybrid DevOps Stack, where the Marketplace providing the extensions is part of the stack and it provides the very same service both on-premise and as a service.

What happened to the SonarQube extension?

If you run a SonarQube analysis in your pipeline you might have noticed this:

It is actually the case – the SonarQube extension is being spun off the product and transferred to SonarSource for further development.

This is not bad news, as we already gained the possibility of running the command-line scanner in the Team Build, both on-premise and (that is where it is important!) on the hosted one.

Also, there is a new integration type – a native SonarQube one:

Here you can define your server and use a token for authentication, which is much better than credentials.

Review – Professional C# 6 and .NET Core 1.0

.NET Core brings so many changes, even if you don’t write production code on a daily basis you might want to have a refresh and that’s what I did with Christian Nagel’s book.

It is very well flowing and never too near a knowledge base article – Christian writes very well. The content in there is for Visual Studio 2015, but you can definitely use it with 2017 as well.

I was particularly interested in the .NET Core and ASP.NET Core sections, and I reckon they are really a fresh and clear starting point on the matter. Given we are talking about a printed book it might not be fully updated, but again it is a matter of a few touches here and there. It is worth remembering that it is stuff in continuous evolution, so I would expect it.

But the book definitely isn’t just about .NET Core and ASP.NET Core. It covers extremely well the stack from top to bottom, and I quite enjoyed the What’s new in C# 6.0 section and the recap from C# 1.0 to 6.0 in the first pages. As I said it is about the whole stack, so once you are off the first 450 pages (Part I is all about the language) you can tackle the IDE, the Compiler Platform and more.

I particularly liked how broad the approach was. The Testing section for example mentions not only MSTest but also xUnit, and in both .NET Core and .NET Framework, the Diagnostics section mentions Application Insights, etc. Christian did an amazing job summarising these broad but also specialist topics, and the result is really well-integrated

I am a huge fan of books, and I really enjoy having a well-written reference I can dive into instead of going straight to Google, losing context in the meantime. This is one of these, and I also strongly suggest this book to whoever needs a refresh or is tackling C# and the Microsoft stack with a bit of past experience.

Safely add tasks to an on-premise Build Agent from the vsts-tasks repository

In my last post I uploaded a task from the vsts-tasks GitHub repository to my on-premise Build Agent. How did I know it was going to work in the same way as with VSTS?

First of all you need to check the minimum agent version in the task you are interested in. Let’s take the .NET Core task I used as an example, that task has a minimum version of 1.95:

This means that the task is going to work from version 95 of the closed-source version on Windows. How do I know that?

Before TFS 2017 there were two different agents – a Windows-only, closed-source version and a Xplat, open-source one. The closed-source version was v1.x, the open-source version was v0.x. This version number can be retrieved in the Agent.Version property of your Build Agent:

Now the agents come from a single repository and they are written in .NET Core as a single code base. This version of the agents is marked with v2.x.

So whenever you want to add a task from the tasks repository always check for the minimum agent version required for it. Generally, if you are on the latest version you won’t have problems adding new tasks unless there are breaking changes – and these are really well documented, if any.

Start building ASP.NET Core 1.1 with TFS

In my spare time I am looking at ASP.NET Core – it brings so much change that you can’t really ignore it even if you are not a web developer.

After putting together the first samples (thanks to the help of a book as well, review coming in a few weeks) I wanted to build something in my lab with a TFS build, so totally on-premise and with no connection to the shiny VSTS.

After installing all the prerequisites (Visual Studio 2017 RC is a great starting point, and I added this on top as well) you can easily get up and running by using command-line tools in the build:

But it isn’t really what I wanted… and in Team Foundation Server 2017 there are no OOB tools for .NET Core. Not everything is lost though.

Firstly, install tfx-cli. Not only it works perfectly on-premise as well as with VSTS, but given that TFS now has a Personal Access Token system we can stop using basic authentication with it. Awesome.

Then, we need the nice task VSTS uses. You can get it from here and upload it to your local TFS by using tfx build tasks upload --task-path <your path>. Simple as that.

So you can start using it! Instead of using a .json file as a Project file you can totally point it at a .csproj file – what the task does is nothing but wrapping calls to dotnet.exe so as long as it is updated you are totally fine.

As I am using a basically empty ASP.NET Core application I unchecked the Publish Web Project option in the dotnet publish step – I want total control over the command. Zip Published Projects is fine as it just zips the artifacts.

This is it – I now have a CI build running in…say five minutes?

.NET Core support in the new Team Build with VSTS

Technology on its own is not really helpful IMHO – having an ecosystem really helps. So I noticed that VSTS now supports .NET Core in the Team Build, and obviously I wanted to give it a go

I started by creating a Team Project in VSTS and adding a sample application created with dotnet new –t web to its Git repository:

So it is time to build it:

There is now a Build Definition Template for .NET Core – long are the days when you had only a couple of them…

What this Template does is nothing really fancy – it encapsulated the basic commands from dotnet to tasks. You could have done the same with a command line task yourself, but the key point here is that this is all out-of-the-box now.

I just accepted all the default settings and triggered a new build. It is successful of course…

But again, the point here isn’t about the template itself (which you’ll customise anyway).

The big point is providing support to cutting edge technology, without support and an ecosystem technology alone, regardless of how cool and innovative it is, is pretty much useless.

Don’t just chuck your stuff in VSTS, take advantage of the artifact repository!

If I’d get a penny for any question on this activity I would be a billionaire by today:

It is a waste of time not sorting and creating proper folders for your artifacts – why should you dig into subfolders when you can create the best possible structure?

Firstly, start by splitting any infrastructural definition. There is no point in handling the json files or anything else related to the infrastructure with the packages, binaries and application-specific scripts.

Then try to divide your output into groups. In my case I really like to split between Infrastructure, Packages and Scripts. This is more than enough 99% of the time.

This is way clearer than this:

Without mentioning the folder structure…

That is because the default activity will collect everything you specify in your matching pattern regardless of the folder structure, while the custom activity (where you just add a new one basically, there is nothing really custom there) gets only the final leaf.

Track service usage data in VSTS

Every TFS admin knows about the Operational Intelligence page. It is a very important tool for managing Team Foundation Server, which provides lots of useful information about service usage.

Nothing like that existed for VSTS, up until a few sprints ago. Now if you look at the Account level settings…

The Usage tab is a revamped version of Operational Intelligence for VSTS! Of course you won’t be interested in the server-side jobs as it is a service, but here you can get all the usage audit about a certain user:

It is worth noting that there are rate limits (the Usage column, expressed in Team Services Throughput Units), so you can be throttled or stopped if you are exceeding these – usually with an automated tool or a script. More about this here.

Easy Service Endpoints ACL management in VSTS

It is amazing how quickly VSTS changes and evolves – of course you need to keep up with it as well

This is todays discovery – the new Service Endpoint’s ACL management UI. In the past Service Endpoints were shown pretty much just as a key-value field with an URL, in reality they have two security groups behind the scenes:

• Endpoint Administrators
• Endpoint Creators

You knew that (didn’t you?), but managing the ACL per-endpoint wasn’t as straightforward as it is today.

The Roles tab in each Endpoint now has a much clearer view of the users’ assignments:

And adding an user is a much better experience now – with an immediate explanation of the role and the associated permissions:

What really strikes me here is the possibility of having the Access inheritance shown immediately – this is a very welcome change for me

A pipeline is not just as vertical fall! Triggers in Visual Studio Release Management

It is great to see people approaching the Pipeline model, but of course the more people adopt it the more we need to go deep into the products we use to get the very best value for us.

An example of this is when you start getting comfortable with pipelines. If you get too comfortable too soon, it is because your pipeline looks like this:

I am not saying it is wrong. There are countless situations where you want or need to keep it that way. What I want to stress is that it isn’t the only way to shape the pipeline!

For example, let’s say you are facing performance issues while deploying because of some reason, or you want to do something else (like initialise the database with real data while deploying your PaaS application, running certain tests while deploying other non-core components of your application, examples are countless here really) – can you do that?

The answer is a strong and definite yes.

Let’s say you want to do this:

“QA – deploy DB” happens first, and then I would like to execute “QA – initialise DB” and “QA – deploy app” in parallel. How? With a proper management of triggers in Visual Studio Release Management

The first environment is automatically triggered by a build, what is interesting is that you can set more than one environment to be triggered by another successful deployment:

Also, you can set an environment to be triggered by all of the previous environments:

So you aren’t forced to use a Niagara Falls pipeline, but something more akin to the estuary of a river

Too long forgotten, the Activity field in TFS

Team Foundation Server is around since 2005, and many features seem to be forgotten despite being in the same place as usual.

If I asked for a dollar/euro/pound every time I was asked this I would be a billionaire as of now:

Can I have a Development Task, Testing Task, Documentation Task Work Item Type in TFS?

You can definitely have such a WIT, but would this make any sense? Excluding any consideration about your methodology (this unfortunately is a question I keep getting regardless of Scrum/Agile/Waterfall/CMMI/etc.), why would you have a different WIT for different flavours of the same?

Usually reasons here vary, but one of the most consistent is this:

I would like to visually understand how the requirement is split and this also makes life easier for team members with different roles in the team.

I mean – the first part is fair enough. But as for the second… it is all about the human rejection of changes  

So, in my opinion the best way of tackling this request (I can’t even class it as a problem…) is to use the Activity field which every Work Item has. Simple as that.

Let’s take this for example:

This comes from the backlog, and all the children tasks are…tasks but leveraging the Activity field you can categorise these children tasks:

Needless to say the Activity list can be customised. Once you do that, you might want to apply some styling rules to the task board, leading to something like this:

And as a side-effect, if you use the Remaining Work field as well – as many do, regardless of the methodology as well, given that you might need to report on it – you’ll get a nice breakdown by Activity:

It is worth mentioning that this field is around since at least TFS 2008.