{{'2017-11-21T12:05:47.3807961Z' | utcToLocalDate }}
Simon Sabin

Azure Powershell 4.0 may break your scripts

Ensuring backwards compatibility is something that one has to consider very carefully when doing continuous delivery. We are all to well aware of the challenges of this with database systems as, generally, the database lives much longer than the apps that interact with it and thus one has to maintain the data. SQL has far too many “legacy features” that can’t be changed due to potential breaking changes. Thankfully the SQL team now have a more robust way of managing change and that’s through the compatibility level for the database. This allows you to upgrade to the latest runtime but still use the old behaviour, if you want to use new features then you can start doing that.

Having said that breaking changes to remove technical debt and enable you to move forward are often unavoidable and that’s whats happened with AzureRM powershell. So you might end up with results like

The property 'SubscriptionId' cannot be found on this object. Verify that the property exists

If you are using AzureRM module in your powershell scripts then be warned that with 4.0.0 there are large set of breaking changes. Unfortunately discovering them isn’t that straight forward. To save you the time here is the link

The issue we had are was using the default RM deploy script generated from the azure portal. This uses Get-AzureRMContext to get the subscription you are connected to. Unfortunately the script expects the output to have attributes SubscriptionName and SubscriptionId but in 4.0 these got changed to Name and Id respectively, and within VSTS the script would fail on the following line

$StorageAccountName = 'stage' + ((Get-AzureRmContext).Subscription.SubscriptionId).Replace('-', '').substring(0, 19)

You can see the difference in the output



Interestingly there is an alias and if you run locally the subscriptionId is found. So there is something odd happening but the good news is that in VSTS you can change the version of Azure Powershell you use in your deployment. This gives you the best control. If you are developing tooling, or using external tooling, always allow you to select a version. Always taking the latest will eventually get you in to hot water.


comments powered by Disqus