Engineering: How to deploy solution to different instance size for Azure environments
Let me continue from where we left the last blog post – Simplified Azure ServiceConfiguration Best Practices. The previous post in this series demonstrated how to create transformation file set for various build definition.
Let’s add another objective to the best practices, how to configure different instance size for various environment, and why would like to do that? – simple answer is “Computomatics”, an economics of computing.
- Environment other than production are subject to internal development lifecycle and significantly smaller audience would access these environment, thus you may want to scale down the instance size of such environment (Testing, Staging, etc.)
- If your project is not on continues development or your development teams are not dependent on Azure Instances, then you may choose to turn-off these instances.
Let’s leave that argument, and I’d like to suggest and additional step into my previous blog post Simplified Azure ServiceConfiguration Best Practices.
<?xml version="1.0"?> <sc:ServiceDefinition name="NilayCornerService" Xmlns:sc="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition" schemaVersion="2015-04.2.6" xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform"> <sc:WorkerRole name="WorkerRoleName.Role" vmsize="Medium" xdt:Transform="SetAttributes" xdt:Locator="Match(name)" /> </sc:ServiceDefinition>
This technique can be ported and extended as needed with MSBuild or custom Continuous Integration or Continues Delivery pipeline.
Any views or opinions expressed are solely those of the author and do not represent any other person or organisation. THE ARTICLE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND. IN NO EVENT SHALL THE AUTHOR(S) OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY.