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:





Friday 7 April 2017

“We don’t ship so often”: why? A reflection on Delivery hurdles.

The last Stack Overflow Developer Survey Results shows that the more a developer ships the happier (s)he is. 
Of course we see a huge amount of people checking in multiple times a day, but also a large amount of people checking in (so potentially building and deploying) much less than that.

So, looking at the other side of the medal: why aren’t you shipping often?

Reasons – as usual – are varied. There might be process constraints (certifications, etc.), hard requirements, but I’ve often seen a heavy reliance on older deployment procedures which are considered too expensive to be replaced by automation. Don’t touch what works, right?

Web applications are a stellar example of this. You might have the most complex web app in the world, but why should you manually move stuff around when you can pack everything in a MSDeploy package?

But that is for Azure and cloud technology and stuff!

Wrong answer! MSDeploy is around since 2009 and it is well supported on-premise as well! So why aren’t you using it for your existing application? It is, after all, the same concept Tomcat uses for its .war files.


This isn’t about throwing years of valuable content in the sink. It is often a matter of trying to split the larger problem into smaller components, and approaching different delivery vehicles. You can retain your existing application as-is, just replacing how you bring it into your production environments.

Sunday 2 April 2017

How can I monitor my AlwaysOn synchronisation status?

As a Team Foundation Server administrator it is critical to have knowledge of all the components involved by your deployment, and SQL Server is the lion’s share (of course).

As you know I am a huge fan of SQL Server AlwaysOn, a really brilliant High Availability solution. I was wondering if there is a way of having an estimation of where the Database Engine is when you see the Synchronizing state in the AlwaysOn dashboard…








I found out there is a way, and it doesn’t even require any SQL at all. All you need to do is to add the Last Commit Time column on the Dashboard, so you will see the time of the last synchronised commit from the Primary Replica to the Secondary.














Of course it is not an ETA, but it gives a rough idea of how much work is left for the synchronisation.

During this state Team Foundation Server is still available because it relies on the Primary Replica, but remember to not perform any failover otherwise you are going to lose data! If it is a long synchronisation you are doing I strongly suggest to set the Failover Mode to Manual, downtime is always a better trade-off than data loss.