Thursday 20 October 2016

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…

image

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:

image

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.

Tuesday 11 October 2016

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 Smile

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:

image

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

image

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

Thursday 6 October 2016

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:

image

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:

image

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 Smile

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:

image

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

image

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