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 IconsOne 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:
|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|
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)')"/>
Technique #2 – Configuration-specific application nameAnother 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.
|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|
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
- Fancy App [DEV] Support Request