When do the ALM Rangers [not] ship source code–Part 9

We have been asked as to when or why we are releasing the source code for our solutions. To find some answers we will start a discussion around the types of solutions we are working on, when/how we typically release the source code and explain some of the anomalies that are probably ruffling some feathers.

Types of “projects”

The following table summarizes the three main types of ALM Ranger projects and which deliver binaries and source code:

Why No and Possibly?

1. We never ship binaries for quick response sample solutions or practical guidance as binaries require a stringent quality and signing process, which would delay solutions unnecessarily without adding any additional value.
   Example projects: Visual Studio Coded UI Microsoft Word Plug-in and Quick Response Sample Solutions
2. Practical guidance may introduce source code created for samples, hands-on-labs and automation of guidance, all of which will be included and shipped with the guidance.
   Example projects: Branching and Merging Guide and Team Foundation Build Customization Guide
3. Tooling is based on source code, which is usually not shipped with binaries until there is a definite demand for the source code. The reason for the deferred release of the source code is to allow us to ensure that the tool reaches a high-quality and feature bar, which we believe is in the best interest of the community.
   Example project: Team Foundation Server Word Add-In

Types of “source code”

The following table summarizes the two types of source code created by the ALM Rangers and the associated quality processes. The first (MSFT QP) is the quality process any Microsoft binary needs to pass, which is very comprehensive and therefore requires additional time and bandwidth. The second (Ruck QP) is the *lite* process which we introduced in the latter part of 2012 as part of our Ruck dog-fooding, to verify and raise the quality bar for primarily sample code.

Why Possibly?

1. When we release the source code for the tooling solutions, we additionally go through the ALM Rangers Ruck Quality Process to verify that we meet our stringent quality bars for sample code.

Quality process for source code

The following diagram lived on my wall and outlines the ALM Rangers Ruck Quality Process, split into a preparation, a raise quality bar and an optional installers phase, What is important is that phase 2 usually takes a long time and huge effort if the team has not pro-actively worked with the quality checkpoints in mind … especially the StyleCop analysis, which has delivered some spectacular *scares* to date.

See ALM Rangers – Raising the Quality Bar for Tooling (Part 1) and the ALM Rangers Ruck Guide for details. Best enjoyed over a coffee made from freshly ground coffee beans.

What happens when we release tooling source code?

When we start a tooling project we typically start a new team project or a team within a single team project on https://tfs.visualstudio.com, releasing the documentation and binary deliverables, but not source code as outlined above, using a www.codeplex.com project.

When we reach the stage where we also share the source code we are currently considering the following process:

1. We copy the tip of the iceberg (latest source code version with no history) from our private TFS environment to the public CodePlex version control. No work items are copied and the team switches its working environment to CodePlex.
2. We keep the private TFS environment running as a read-only reference site for some time.
3. Eventually we delete the private TFS environment.

See for posts in our dog-fooding series, especially ALM Rangers ALM Dogfooding and the “Angst” Factor – Part 3 which is focused on the above mentioned Single Team project model.

As always we appreciate your candid feedback to help us learn from our dog-fooding and ensure that we continuously improve :)