Troubleshooting for dummies with Team Foundation Server

I have been asked how did I manage to understand the issue with the Work Item Synchronization Service I posted before, so maybe a broad answer could be better than a one-to-one.

At the very beginning, I have been notified by a user which didn’t manage to see his Iterations in the proper way after some amendments.

After asking to clean the client cache – an unsuccessful try - I tried refreshing the Data Warehouse, and eventually rebuilding it. No luck again.

When this sort of issues happen, it can be nasty. My suggestion is to avoid running some scripts you may find on the web, as touching the TFS databases without the consent of a Microsoft CSS man would be very dangerous and can put your installation in an unsupported situation or even worse, it can be damaged.

You can have a look in the Event Viewer for issues, it is time consuming but often useful.

Or you can do as I did, logging into the Administrative Page (the informally called _oi) which contains a lot of informations about everything running on the Team Foundation Server, in a almost real time state.

In this case, I noticed the user raised some service calls with –1 as a result, which means error. Opening the log I looked at the error detail, so I managed to get in touch with Microsoft. Luckily the RC of the Update 3 went live shortly after the issue, so applying it was a matter of a very short time.

I strongly suggest looking at _oi very often, as it is not just a troubleshooting tool, but it is a real live look at the servers’ health, with detailed reports etc.

How Developer Operations fit into the Agile picture?

It looks like one of the buzzwords this year is DevOps.

But what is it? It is the merge of Developer and Operations, which basically means everything that happens while running an application inside the boundaries of the production systems.

It represents a great leap from the standard, reactive way of managing production applications and services on a alert basis, to the new agile, proactive way – which means the Operations teams actively collaborate with the Development teams in order to get better and higher quality products.

The heart of Developer Operations is its principles. They are the incorporation of the Agile development practices in the IT environment, plus a huge enhancement in collaboration which involves Development teams, QA teams (where separated by the Development teams) and Operations teams.

The main tools for achieving this are:

· An automated systems infrastructure, which allows the removal of many of the human interactions and thus points of failure.

· A broad ALM platform, enabling developers to have a shared Version Control System, an automated build server, etc.

· Designing software leveraging on Feature Flags, so that if something is faulty it can be easily disabled while investigating on the issue – without impacting the non-faulty areas of the application itself.

· Continuous Delivery.

· Shared metrics aimed at measuring and improving both the overall and the detailed quality of the application/service.

Of course it is not just about tools. For reaching a good DevOps proficiency every role in the team should collaborate in the proper way from the first inception of the project, in order to have a seamless experience among everybody. DevOps don’t start at the delivery, but at the very first sprint.

Feature flags are a very bright example of this approach. It is a development pattern which directly affects an operations’ topic: configuration. If a team commits to use feature flags in an application involving the DevOps people, the latter must be aware about feature flags themselves and they will know how to proactively manage potential issues.

Everything rely on communication. To get properly working Developer Operations the Ops team must be open to a huge mind shift – from stability to agility, as the change referred here is not a breaking change but an evolutionary change, often required by the business itself. The existing boundaries between Development teams and Operations teams should be removed, with their disruptive behaviors.

The natural evolution of Developer Operations would be the Agile Operations – the Operations team would then use some of the core Agile principles (Kanban or Scrum derived, like backlogs) together with some specific developer tools like a Version Control and a Build Server for their own deployment efforts.

This second step of course needs a lot of prerequisites – as opposite as the Developer Operations one which is pretty easy to start – but benefits would be huge. Concepts like the Daily Scrum applied to an Operations environment empower productivity because of the direct communication flow happening beneath.

So, answering the title: How Developer Operations fit into the Agile picture? By incorporating the Agile development lifecycle, applying concepts and principles from the methodologies (usually Scrum) to a completely different topic – Production Operations.

Migrating distributed branches from Git to Team Foundation Server

If you have to migrate (like me, today) a huge Git repository to Team Foundation Server, it’s very likely that you are going to hit one of the most common walls while migrating a distributed VCS to a centralized one: understanding the branches’ lifecycle.

Briefly, in a DVCS you won’t have the common branches you might find in a VCS like Team Foundation Server, because of the nature of the DVCS itself which tends to have a number of branches for making offline working easier and smoother. Of course you won’t be able to clone this structure inside the Team Foundation Version Control, but there is a way to mitigate it.

I am using Git-Tf, the Microsoft’s tool for migrating Git to Team Foundation Server. After you configured your repository, you should perform a git-tf checkin –deep in order to replicate every single changeset instead of a big bulk one. But you’d get an error:

Here is what I meant: if you have multiple parents for a commit, you cannot replicate it inside Team Foundation Server. If you rebase, you are going to edit the history, which is wrong from a preservation point of view.

So you should use the –autosquash switch, which is going to create a linear history without editing it. How? By finding out the HEAD revisions.

Work Item Synchronization issue with Update 2

After installing the Team Foundation Server 2012 Update 2 it can happen that the Work Item Tracking Synchronization Service suddenly stops working, so that you can’t see updated areas and iterations neither in Visual Studio, Web Access, Excel, etc.

These are the symptoms…

To help us troubleshooting this nasty – but known – bug, the _oi Activity Logs are very helpful…

  We see that from a certain point, a number of Work Item Tracking Integration Synchronization jobs are failing…

…and the Job History Details show a System.NullReferenceException. Here is the problem!

The Team Foundation Server 2012 Update 3 contains a fix for this, as detailed into the changelog (see the Work Item Tracking paragraph into the Team Foundation Server fixes).