Saturday, 6 February 2016

A new experience with Work Items deletion in VSTS

With Team Foundation Server you can either remove a Work Item by changing its state (leaving it on the backlog then, not really a removal) or permanently destroy it. No middle ground, no real choice if you need to clear the backlog.


With Visual Studio Team Services instead you have this middle ground, with the Recycle Bin.


It is literally that – you can now delete a Work Item via the context menu and it would be gone, moved to the Bin. Pretty much like a file.


Of course it isn’t actually destroyed (only witadmin destroywi can do that, and it needs confirmation for doing that), but it is only hidden from the backlog. All the traceability is retained, which is very handy.

Friday, 22 January 2016

Help, the backlog is gone!

Just beware – if you are migrating stuff from a Team Foundation Server to Visual Studio Team Services, it might happen that despite correctly moving all the Work Items involved in the migration you can’t see the backlog as you would expect.

But don’t panic, this doesn’t mean data is lost, it just means that data is not showing up – a completely different matter. That is confirmed by creating some custom queries asking for all of a certain type of Work Item Type (all PBIs for example): you would get all the Work Items you are looking for.

So, what is the problem here? Look at the areas: if you do not allow areas to automatically link sub-areas, your backlog is not going to show what you want.

Lots of panic for nothing Smile

Thursday, 14 January 2016

Where are TFS and VSTS heading?

This week Microsoft made published an update to the Team Foundation Server and Visual Studio Team Services roadmap, and it looks very promising.

As we already know, TFS and VSTS are an ever evolving platform. This is true for both on-premise with regular updates delivered roughly every quarter and for the cloud service, where the new features are always delivered first.

There are already a few set of features slated for TFS vNext – this is neither a surprise nor a defeat admission, the amount of work for such features is very big – think at the listed improvements for Work Item Tracking alone.

But it isn’t everything for vNext – there is a lot coming in Update 2 and Update 3 as well. The Lab Management overhaul is one of these features, coming in Update 2, like extensions on-premise and the new Release Management.

Keep an eye on that page for TFS and VSTS, because it is updated on a regular basis and it is a great source of information for planning well in advance.

Wednesday, 6 January 2016

A cryptic story around Git, VSTS and Azure Active Directory

This is a short and easy tip with an interesting background.

If you try to push stuff to a Git repository hosted in a VSTS account, where this account is backed by Azure Active Directory and you are not logged on with the relevant credentials, you are going to get a quite cryptic error:

The Output window is not quite helpful either:

What is going on here? The reason, as I stated, is simple – I wasn’t using the right credentials. But the problem is that Visual Studio is not warning me, while instead the command line would just ask for the credentials.
One of these things you need to just know, I assume Smile

Monday, 14 December 2015

I updated Release Management and my builds fail: now what?

This is a quick but worth tip to remember.
If you upgrade Release Management, you always need to update the Client. Up to this, fair enough.

But you are going to start getting errors like “The account running the TFS build service needs to be added as a system user in the Release Management Server” in your build.

What you might be missing is that in order to allow communication between the two you also need to at least open the client, and if you keep getting errors you might also want to remove and re-add the Release Management URL into it.

This operation will recreate the authentication tokens and you can use VSRM again.

Sunday, 6 December 2015

Things to remember when you work with Azure and the new Team Build

Azure is an amazing piece of technology – its capabilities are immense and there is always something new to learn and use for solving our problems.

It is quite a while I am spending time on it, together with the new Team Build and a few other bits and pieces all around. I thought about summarising these little issues you might face as well, so you should save some time Smile

First of all, please remember this: if you don’t have a build task OOB, and you don’t want to write your own, you can still use PowerShell! Never forget how powerful it is, because it can be used in literally thousands of ways.

If you are working with TFS 2015 RTM you won’t have the new build tasks bundled with the Update 1 or support for Service Principals, but don’t worry – you can achieve the same results with a bit of PowerShell.

For example, bearing in mind that creating a Service Principal for your Azure Active Directory is as easy as the first part (steps 1, 2 and 3) of this blog post, this is all you need to do in a PowerShell script to use the Service Principal for authentication:


At the moment support for Service Principals is limited to Azure Resource Manager, so for deploying any components you might want you still need to rely on the old certificate-based authentication.

The issue here is that the combobox in the build task for Web App Deployment (VSTS or TFS 2015.1) doesn’t specify anything like that. What I suggest is to follow the following approach and add the Azure subscription with both authentications:


So you would get a subscription in the comboboxes anyway, regardless of the authentication method you chose.

Eventually, bear in mind that the new build agents expose capabilities – so if you want a specific agent with Azure PowerShell installed you would need to specify AzurePS as a demand in the build definition.

Thursday, 3 December 2015

What’s happened to the Visual Studio installer?

Well, they sorted it out! The Visual Studio 2015 installer is now componentised:


It is now very straightforward to understand, especially for upgrades. This is true also for the third party components like the Android development stuff.


How was that possible, given the monolithic ISO that Visual Studio was? Let’s have a look at the packages:


And then there is a file for the external, downloadable components. It is the feed.xml file, this is an extract:


Kudos to the team!