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).

Behind the scenes of the Work Items’ states: Team Foundation Server Metastates

Despite present since the RTM version, the metastates became notorious to the mainstream after the introduction of the Kanban Board. Why? Let’s see…

 

New, Approved, Committed and Done are metastates. Have you ever heard about them before? I don’t think so J

They are not something particular, but just an aggregator of various states for Work Item Types. Metastates are defined into the Process Template of course, in our case just for the Product Backlog Item Work Items:

As we see, we can have a Proposed (state) Work Item which can be either New or Approved.

This is the easiest sample, you can customize the board to show more metastates, you can report against them, and much more.

Web Access Licensing for dummies

With Team Foundation Server 2012 the licensing became way easier, in order to have a clearer path of adoption for the involved features. One big example of that is the new Web Access.

The new Team Web Access now features three levels of information access, dependent on the CAL you have:

These three levels exposes a different set of information to the user.

A user acceding the Web Access with a Limited Access level is roughly the same as the old Work Item Only View in Team System Web Access, so the user can access to what belongs to him without the need of a CAL.

The Standard level is for who has access to Visual Studio 2012 Professional, and it adds all the standard Web Access features plus the Agile Boards introduced with the 2012 release.

The Full level is for who has access to Visual Studio 2012 Premium and above, it enables every feature of the Web Access, so the Backlog Management Tools, the Feedback Management and – with the Update 2 – the Web Test Case Management.

A clarification on the Team Foundation Server Integration Platform support

Often many people think that as the Team Foundation Server Integration Platform is an open-source project, it has no support.

WRONG!

It is the only Microsoft supported solution for all the migration needs you might have.
But only if you download the Visual Studio Gallery package, which is the stable and supported version. If you have an issue with it, you can raise a call to the Customer Support Service.

If you download the Codeplex package (with the source code), you might get the betas, which are obviously not supported.

I hope this clarifies a bit around this really important topic

Solving mess on behalf of others: tf undo

Sometimes it happens the TFS Administrator has to solve problems caused by unexperienced (or untrained) users, and maybe the most common is to undo ‘ghost check-outs’.
Here’s the answer: Attrice Corporation Team Foundation Sidekicks. Cool. But sometimes you can’t use third-party tools, and you only have to rely on what Microsoft provided in the OOB installation.

So here’s the real answer, since Team Foundation Server 2005: fire the Developer Command Prompt, and launch the tf undo command with the proper switches.

Here there is the relative documentation.