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 Profiles\ProjectName.azurePubxml
.
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:
ProjectName.azurePubxml
Step 4: Add PreBuildEvent
to the Azure deployment project by editing it further. This script should:
- Fill
<AzureDeploymentLabel>
XML node inazurePubxml
with a content of your choice (optionally grabbing output ofgit describe
). - Fail gracefully if there is no git available.
- Fail gracefully if there is no
azurePubxml
file.
In other words, we just take output of git describe
command and put it inside the match of:
new Regex("<AzureDeploymentLabel>.*</AzureDeploymentLabel>", RegexOptions.Multiline);
MSBuild 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.