The Azure DevOps (VSTS) team have published the promised postmortem on the outage on the 4th of September.
It gives good detail on what actually happened to the South Central Azure Datacenter and how it effected VSTS (as it was then called).
More interestingly it provides a discussion of mitigations they plan to put in place to stop a single datacentre failure having such a serious effect in the future.
Great openness as always from the team
Updated 3 Feb 2018 – Also see Versioning your ARM templates within a VSTS CI/CD pipeline with Semantic Versioning
Azure Resource Templates (ARM) allow your DevOps infrastructure deployments to be treated as ‘content as code’. So infrastructure definitions can be stored in source control.
As with any code it is really useful to know which version you have out in production. Now a CI/CD process and its usage logs can help here, but just having a version string stored somewhere accessible on the production systems is always useful.
In an ARM Template this can be achieved using the ‘content version’ field in the template (see documentation for more detail on this file). The question becomes how best to update this field with a version number?
The solution I used was a VSTS JSON Versioning Task I had already created to update the template’s .JSON definition file. I popped this task at the start of my ARM templates CI build process and it set the value prior to the storage of the template as a build artifact used within the CD pipeline