DevOps 101: IntelliTrace to the rescue

We have seen how to fix the gap between development and operation teams in a quick&dirty way. There is a lot more to do, and tons of tools which can help us: the main one is IntelliTrace.
When we create an Operational Issue, an IntelliTrace log is attached to the work item itself:

but it features just the minimum subset of information related to the alert.
The first way would be manually get a .iTrace file with our custom collector. Nothing that difficult, but if the main motto of DevOps is “automate everything”, we are going against it.
Or – way better – I can ask the Ops folks to record a detailed IntelliTrace log, of course everything integrated with Team Foundation Server. It’s just needed to set the work item to “awaiting evidence” with a resolution note telling them to provide me a better IntelliTrace log:

Then the Ops guy is going to use the IntelliTrace Tasks tab to gather what Engineering wants. Definitely easy!

He can collect a snapshot of the current state of the involved application pool, or better he can start collecting a new IntelliTrace file, replicating/let someone replicate the scenario on behalf of the user, and then the new IntelliTrace file is going to be attached to the related Work Item.
All the IntelliTrace files are going to be stored into a network share, one folder for each alert, so remember to keep an eye on the storage size!

DevOps 101: Managing Operational Issues

As we’ve seen, once Operations send to Engineering issues, they are just Team Foundation Server’s Work Items.

This specific Work Item Type is tailored on the need of explaining a production incident, probably a bug, so it features several useful information out-of-the-box. It’s tied to the AVICode informations, and the most important thing here is the state:

After we acknowledge we are on the Issue itself, we have a broad range of states to be set: this is essential for organizations with a structured process (think about ITIL).

Apart from that, it’s a standard WIT, so there is not so much to say on the Engineering side. Hey, we are who were already working with Team Foundation Server!

There is an IntelliTrace file too, as mentioned. In the next post we are going to see how to better capture all the information we need.

DevOps 101: from production errors (ouch!) to Engineering

I decided to name this series after the classic introductive American class: 101. We are talking about DevOps (with Visual Studio ALM 2012), so DevOps 101

KABOOM!
The first step toward Developer Operations is allowing production errors to get intercepted and stored into Work Item Types for the Engineering team. As we saw in the last post, there is a new, dedicated WIT for that: Operational Issue.
Once we hit a bug in production, one (or more, depending on what caused the error) alert is raised. This alert can be sent via email, too, in order to trigger both a formal (via the SCOM Console) and informal (via email) communication.

It’s not just a simple ‘alert’: it features all the information we are going to push to the Operational Issue.
 
Once we modify the status to Assigned to Engineering, it is pushed. Aside from all the tabs (it wouldn’t be a 101 post otherwise ) let’s have a look at the Alert Description box. It features an hyperlink to an URL which uses port 45451. What’s that?!

It’s the result of the Microsoft’s acquisition of AVICode. A full-featured application monitoring system has been integrated inside SCOM, and the information it gathers are rendered by this service, capturing every kind of stuff you can think at the surface level.
Beware: an IntelliTrace file is added to the work item, but it’s not that huge. We are going to see in a separate post why, and how to integrate IntelliTrace in our DevOps workflow.
The next post is going to the other side, so what happens in Engineering when a Operational Issue is raised in Team Foundation Server. Stay tuned

Basics on Developer Operations with Team Foundation Server 2012

As we saw in the last post, the DevOps movement is making so much noise in the IT world and of course Team Foundation Server is not behind: here is the basics on the integration with System Center Operations Manager in order to integrate the two worlds.

First of all, we need to set the server and the Team Project Collection for the application we want to monitor:

 

Then we can set the Projects where the new Work Item Type – Operational Issues – are going to be stored. We can set the appropriate Area Path.

 

Apart from the connection between SCOM and TFS, a huge aid in bridging Operations to Engineering is brought by Alerts. Whenever the state of a Operational Issue changes, an alert is triggered for the Operations administrator:

Then we have a dashboard recapping all the information we entered. I highlighted the possibility of importing Operational Issue work items: this is really important when it comes to consolidation, an often under considered topic.