Using Git Revision in Windows Azure Cloud Deployments
Here's a quick approach for including git versions of your codebase into Windows Azure Deployment labels (as visible in the Portal). This applies to Azure SDK 1.6 and probably higher. Versions are appended automatically whenever you trigger a publish from Visual Studio.
git versions usually are reported by
git describe and could look like
r40 (if there is
r40 tag on the last commit) or
r39-31-g48ac07c (if last tag
r39 was 31 commits ago).
It works like this.
Step 1: Create new Azure Deployment profile for your deployment project. It will be saved somewhere to
Step 2: Save project and then edit deployment project file to include this profile file only if it exists
<ItemGroup> <PublishProfile Include="Profiles\ProjectName.azurePubxml" Condition=" Exists('Profiles\ProjectName.azurePubxml') " /> </ItemGroup>
Step 3: Drop a
.gitignore file into the
Profiles folder so that changes will not be tracked. Contents will be straightforward:
Step 4: Add
PreBuildEvent to the Azure deployment project by editing it further. This script should:
<AzureDeploymentLabel>XML node in
azurePubxmlwith a content of your choice (optionally grabbing output of
- Fail gracefully if there is no git available.
- Fail gracefully if there is no
In other words, we just take output of
git describe command and put it inside the match of:
new Regex("<AzureDeploymentLabel>.*</AzureDeploymentLabel>", RegexOptions.Multiline);
PreBuildEvent script can be wired to our process via editing of
.ccproj file (or you can just fill that via Visual Studio UI - Deployment | Properties | Build Events):
<PropertyGroup> <PreBuildEvent>"PathToReplacementScript" "$(ProjectDir)\Profiles\ProjectName.azurePubxml"</PreBuildEvent> </PropertyGroup>
For the actual replacement script you can use scripting environment of your choice or even C#.
By the way, there are two interesting twists upon this concept.
Twist 1: You can leverage git's super powers to print all changes in the code between any two deployment labels. They will be nicely formatted by committer, too.
git log r39..r40 --pretty=short | git shortlog
That's how we publish releases at Lokad.
Twist 2: You can set your system to publish
InstanceStartedEvent with the following schema:
InstanceStarted!(string codeVersion, string role, string instance)
The latter can be used to link your code version trees directly with the event streams and life-cycle of a distributed system deployed to the cloud. This immensely simplifies post-mortem debugging of such systems along with adding a few maintenance tricks to your sleeve.