We use feature branches, and build all of them on our TeamCity CI setup. Every build can be deployed on our test servers, but it’s useful to be able to quickly distinguish which ones came from master and which came from other branches. I took a script from here and edited it to simply append -alpha to the end of the version number for any non-master build:
$branch = "%teamcity.build.branch%"
$branch = $branch.substring($branch.lastIndexOf("/") + 1)
Write-Host "Building from $branch branch"
if ($branch -ne "master")
$buildNumber = "%build.number%-alpha"
Write-Host "Appending alpha to build number"
Write-Host "##teamcity[buildNumber '$buildNumber']"
Write-Host "Leaving build number as-is"
This makes it really obvious when a build has come from a feature (or other) branch, to avoid accidentally deploying it etc. You could probably easily extend this to pull a version number from the branch name as well, or similar.
To use this across multiple builds, I just set up a build template with the script stored in the first build step, which you can then apply to builds either individually or across a project.
One of our builds just failed with this fairly cryptic error:
[File content replacer] no net in java.library.path
java.lang.UnsatisfiedLinkError: no net in java.library.path
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)
Turns out we’d manually updated Java on the machine that the build agent was running on. If you do that, you should also restart the build agent service so that it picks up the new version correctly.
It’s useful to include a version in DLLs that you deploy, to make it easy to check what code is actually being used where. We build our projects using TeamCity, and it’s possible to write build scripts that grab the version from an environment variable that TeamCity sets in order to insert into your AssemblyInfo.cs files. However, if you have a fairly standard project setup and are using TeamCity, there’s an easier way to do this using the AssemblyInfo Patcher build feature that TeamCity provides. This will run after all files have been checked out, automatically searching for all AssemblyInfo.cs files and replacing relevant versions (e.g. in the [assembly: AssemblyVersion("184.108.40.206")] attribute) with the current build number, before then proceeding as normal with the build, and reverting the changes once the build has finished.
To enable this feature, simply edit the configuration settings for the build you wish to add it to, click “Build Features” in the sidebar on the left, then click the “Add build feature” button and select “AssemblyInfo patcher” from the options. Configuration is fairly minimal but will allow you to customise the format of the version that will be used for various different attributes, if you don’t want to just use the default build version.
The AssemblyInfo Patcher is just a pre-configured version of the TeamCity File Content Replacer build feature, which you can use if you have more advanced needs.