As mentioned in a previous blog post here, I wanted to provide some thoughts, and potential deployment scenarios, with Azure artifacts (mostly Azure Automation related) and VSTS.

Managing the Azure subscription itself via ARM template for management purposes

Having a backup ARM template for an automation account or other services should be required – there should be no reason not to have one ready. Use VSTS as the primary starting point to re-deploy your subscription and resources by creating a build definition to release artifacts from an ARM template. Lets dive a little deeper into what that might look like:

• ARM Template Deployment
  • This is a completely declarative situation – essentially a make it so concept
  • You don’t need a script – it all boils down to a JSON file (hopefully you have a JSON editor) that Azure can consume and provision assets or applications into the respective service
    • Visual Studio Code is a huge help here with its Azure Resource Manager Tools extension (grab the extension here)

​

• The ARM template can be tracked with source control repositories! Don’t you see? This is a full circle effect – “back up” your work by tracking it with source control since branching and history can be your friend in this situation. This is especially useful for a system administrator that wants to manage and track administrative templates that manipulate your cloud infrastructure (hopefully in a good way)
  • As a side note, when authoring Azure Resource Manager (ARM) templates, there are numerous resources that can be edited/provisioned with the Azure SDK. Simply download a template and open the schema link at the top to reveal resource types that are available to you!
    • TIP: when editing JSON in Visual Studio Code, simply use this hotkey to auto-format your JSON:  Alt + Shift + F
    • The JSON should transform from a single line of code
    • Into this:
• Be aware that the ARM Tools extension may advise that some values are not accepted – but typically Microsoft requires the original schema syntax. This was the case for me when I authored some Scheduler templates. See below for a before and after:

 

• Think about utilizing variables or parameters as part of the ARM template deployment – these can be extremely helpful since code won’t have to change, just a data value

 

Write a custom script to deploy runbooks and other assets

• Build definitions within Visual Studio Team Services allow you to write simple or complex deployment processes
  • This could be a simple build definition with one task that simply executes a PowerShell script or something similar to achieve the same result
  • The possibilities are endless with packaging your contents and shipping them out to Azure
• External sources can be targeted within this process (e.g.: NuGet server)
• A custom script may be the preferred method to ensure that backups, versioning, etc. is covered within your release process. However, ARM templates do give you the opportunity to specify build versions, but this may not be enough for custom in-depth deployments
• Keep in mind that the custom script may grow in size and may become harder to manage, so the first scenario seems ideal – but it’s truly up to you

Thanks for reading!