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:

image

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:

Configuration Description Color
DEV development/integration builds Red
QA internal releases to our QA/testing team Gold
UAT internal releases to our stakeholders Green
STAGE pre-releases to an environment that mimics production as closely as possible Purple
PROD production releases to our customers Blue
In our solution we have each icon named according to it’s configuration:

imageWe’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>

&lt;Copy SourceFiles="@(AssetToUse)" DestinationFiles="@(AssetToUse-&gt;'%(AssetToReplace)')"/&gt;

</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.
Configuration Description Application Name
DEV development/integration builds Fancy App [DEV]
QA internal releases to our QA/testing team Fancy App [QA]
UAT internal releases to our stakeholders Fancy App [UAT]
STAGE pre-releases to an environment that mimics production as closely as possible Fancy App [STAGE]
PROD production releases to our customers Fancy App
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:

image

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

image

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.