Tuesday 28 October 2014

Impact of the new Visual Studio Online European Region

With the latest update Microsoft addressed one of the most repeated requests about Visual Studio Online. It isn’t a specific feature or capability, but it is a EU-hosted region for it!

Up to yesterday, you did not have any choice on where your VSO data is hosted - the VSO tenants were only in Chicago, San Antonio and West Virginia.

It wasn’t a matter of performance or latency – I personally never had heavy problems unless a service-wide problem arised – but it was all about governance. If you are a EU-based company or anyway you have operations in the EU, you know data protection it is a pretty important matter.

We are not talking about Microsoft snooping into your source code and looking at your intellectual property, not at all, but depending on what you work on you might have strict regulatory policies to apply. In detail, if you have EU operations (which means even a single server running in the EU), the EU Data Protection Directive applies, and it is stricter than the US counterside, especially on when data leaves the EU.

Visual Studio Online is covered by the Safe Harbor since I recall its existence, a bilateral agreement between the US Federal Trade Commission and the European Commission providing reciprocal protection to personal and sensible data, but for certain businesses or countries it was just not enough. Germany is a good example, where its privacy laws are way stricter than the general EU umbrella.

Eventually, if you store your data – whatever it is – on a US hosted service, your data could be inspected by the US Law Enforcement agencies under the PATRIOT Act.

So, introducing a EU-hosted region (in Amsterdam, for completeness) means a lot in terms of governance, as all of your intellectual property hosted there is subject to the EU DPD as such, and that’s all.

What you will be lacking today is Application Insights – but it would reach the EU VSO in time for its General Availability.

Thursday 23 October 2014

Can I host multiple Git repositories in Team Foundation Server?

Of course you can!

I am in the middle of a migration project, and the team I am helping with has several Git repositories (converted from other version control systems) to upload to their Team Project.

It isn’t extremely intuitive – you need to open the Control Panel for your Team Project (https://yourserver.domain.tld/yourcollection/yourteamproject/_admin/_versioncontrol)

image

and from there you can create a new repository.

image

That’s all!

image

When you’ll navigate to the newly created Git repository you will get the Getting Started page as well, which is very helpful for first-time users.

Thursday 16 October 2014

Again on the logs: are errors in the logs going to stop an upgrade?

A quick but interesting question came out this week: “if I see an error in the Event Viewer of the Application Tier, is it going to break a TFS upgrade?”

Generally speaking – no. The errors you see in the Event Viewer are client-side logs reported to the server. You might see an error on a client not able to connect, another one because of a non-existent user or value in the Work Item query, or more critically an error because you cannot contact your data tier.

It is the data tier which contains all the meat. All the data is stored over there and, if you look at the Configuration logs after an upgrade, the big show is there.

Of course there is a correlation between the data tier’s schema and the application tier version – everything is handled by the same binaries.

Thursday 9 October 2014

Logs, logs, logs…

Team Foundation Server is by no means an easy product – especially with large deployments. One of the most important aids in the daily maintenance is taking care of the logs, which are very descriptive.

Apart from the usual suspects (IIS, SharePoint, SQL Server, SCVMM) inside the Event Viewer you are going to find all the logs related to the TFS Services – these logs are especially invaluable when it’s time to troubleshoot a client issue, because they will contain exactly the error the user experienced plus many information about his environment (in particular which client triggered the error).

One example is an error like this:

logs2

“TF10158: The user or group name <group> contains unsupported characters, is empty, or too long" Once it is logged inside the Event Viewer I am going to get the error itself, plus who (the user account) and from which client (Visual Studio, a browser, MSTest, MTM, etc…) experienced that – guess what happens if you receive a question on such a group Smile

But what about setup or update logs? They are elsewhere – you are going to find the link into the TFS Administration Console.

logs1
What is amazing is their verbosity – did you ever try opening one of them?

logs0 
They are pretty self-explanative, and when it comes to a version update you will find detailed information about every step the setup does. This explains many things…for instance, did you know that the 2013.3 update which enabled Test Suites and Test Plans customisation has much of its foundations in the Update 2 bits?