January 27, 2013 3 ways to remember which build you're running

Often when building software we have to juggle several different build configurations, each pointing at different services, accessing different data, etc. During development it can be a huge time saver to have an easy way to know which build you’re looking at. I find this to be important when tracking features, defects, bug fixes, and deployments, for example, or that moment when you pause before submitting an order to check if it will actually be charged to the valid credit card number you’re using for integration testing.

Technique #1 – Color-Coded Icons

One of my favorite techniques for differentiating between builds during development is to use color:

In this case you see five different versions of the same icon, each one representing a different build configuration of the software my team is working on:

In our solution we have each icon named according to it’s configuration:

We’ve used the VSCommands extension to group the configuration-specific ICO files “underneath” the one that the application is configured to use at build time.

We also use the following MSBuild target as a pre-build step to copy the configuration-specific icon into the right spot for the build to pick it up:

  <PropertyGroup>
    <BuildDependsOn>
      CopyEnvironmentSpecificAssets;
      $(BuildDependsOn);
    </BuildDependsOn>
  </PropertyGroup>

  <Target Name="CopyEnvironmentSpecificAssets">
    <ItemGroup>
      <AssetToUse Include=".\Application.$(Configuration).ico">
        <AssetToReplace>Application.ico</AssetToReplace>
      </AssetToUse>
    </ItemGroup>

    <Copy SourceFiles="@(AssetToUse)" DestinationFiles="@(AssetToUse->'%(AssetToReplace)')"/>
  </Target>

Technique #2 – Configuration-specific application name

Another technique that is useful is to add the configuration name to the application name that appears in the install shortcut, the window title, the add/remove programs dialog, etc.

We use this naming convention in our main WPF window, having it’s viewmodel read the title in dynamically from an application.resx resource file, though you could just as easily store it in an appSetting in your app.config file.  In either case the XmlTransform target is a handy way to use Web Config Transforms to swap in configuration-specific appSettings as a pre-build step.  And remember that RESX files are simply XML files:

so the Web Config Transform tooling works just great on those also:

Technique #3 – configuration-specific emails

In our case we have one email address to handle support requests. When a support or activation request email comes in it is important to know which build configuration sent it so that we can triage the email appropriately.

In the screenshots above you’ll notice that we transform the subject of our support email from:

• Fancy App Support Request

to:

• Fancy App [DEV] Support Request

or whatever other configuration we are targeting.  This let’s recipients quickly identify those emails that are sent by devs during integration testing (i.e. those with [DEV] in the subject line) and those that are sent by stakeholders (i.e. those with [UAT] in the subject line) and trim them out of emails without a configuration tag in the subject line that are sent by customers in the field.