About 9 months ago, I started experimenting with Visual Studio Online for my company’s source control system. Initial results were very promising – the system required little maintenance (mainly just adding/removing accounts and projects), and was full of great features. External collaboration with customers was a snap, as I just needed to add their Microsoft Accounts – no complicated ADFS or trust setups involved.

However, as a software consultancy working with many different clients (and having to adhere to strict confidentiality and non-disclosure agreements), several points of data leakage in the product made it unsuitable for use in this kind of an environment. We have now performed the migration from cloud back to on-prem using the time-limited export option in VSO. Following are some of the reasons for this move back.

Leaking User Information

The nail in the coffin for VSO was the leakage of User information across projects. Visual Studio Online only provides you with a single Team Foundation Project Collection (called “Default Collection”). Project Collections contain projects, users, and settings, and are a security and isolation boundary very similar to SharePoint Site Collections.

In TFS on-prem, you can create multiple project collections. If you work with multiple customers, you can have a collection per customer, and ensure that you have isolation such that only projects and users from that customer are in the collection.

In Visual Studio Online, all your users and projects are lumped into a single project collection, and this presents an opportunity for one customer to see the other customers you are working with.

I was very shocked to see that the Users tab, which is available for everyone in the collection, shows ALL the users in the collection. I assumed that the list of users would be filtered somehow to the users from the projects you had access rights to, but it is an all-up list, and completely possible for one customer to see the other customers in the system.

The Users tab, showing all collection users and email addresses.

In addition to the Users tab, the Assigned To fields on work items were another source of leakage. When typing in a name in the Assigned To field, it’s possible to assign users from any of the users in the project collection, not just members of the current project The autocomplete will happily resolve the names cross-project.

Once we found this out, this user leakage became a non-starter for us.

Cross-Project Work Item Linking

Since most of our consultants work on multiple client projects, they have access rights across the various projects. When working with Work Items, it is often desired to link work items via Parent-Child relationships. The Add Link dialog enables typing work item IDs, and then seeing a preview of the work item before creating the link. You can type in a work item ID from a different project and create cross-project links. In this respect, Visual Studio Online handles this better – it doesn’t allow you to see the work items from projects that you don’t have rights to access:

However, it’s possible for our consultants to accidentally create a cross-project (cross-customer) link between work items, which can create a confusing experience for our customers. In the screen below, the linked work item shows as “getting details…”, but it never actually gets the details.

It would be better if it told you that you didn’t have rights, like it does when you click into the item:

Summary

While VSO is a fantastic platform, at this time it doesn’t work well as the sole repository for a software consultancy that works with multiple clients, and needs complete isolation between client information.