Using the old process model for Azure Web Apps we were able to bind the web app name to a variable, so that we could deploy to different deployment slots for different environments.
It looks like the documentation hasn’t been updated to reflect the new Octopus Azure App Service deployment model where web apps are treated as separate deployment targets. I’m on v2018.5.7, and I don’t see where we can bind the web app name to a variable. We also can’t bind the Azure account to a variable.
Does this mean we would have to create a deployment target for each deployment slot for each web app? For us, we use deployment slots for dev, test, smoke testing, staging, and production. It seems like this will gobble up quite a few of our deployment target licenses.
Am I missing something, or are there plans to allow variable binding for Azure Web App names and Azure Subscriptions?
I see that deployment slots were addressed in 2017.7.0, but what about being able to bind the azure subscription to a variable. We use different subscriptions for test versus production because Azure discounts dev/test subscription costs.
Hi Stephen,
Thanks for getting in touch.
You are correct. In version 2018.5.7 you would need to do this by multiple targets, which as you say, is not ideal due to licensing.
In version 2018.7.0, we added the ability to define a deployment slot on the step (as well as the target) to counter this exact problem. So you’ll have the option of setting up one target (without a slot defined), then having multiple steps each with their own slot preferences. Any slot defined on your target will take precedence.
Account selection has moved to the deployment target now (as this enables a lot more flexibility with regards to dynamic infrastructure and provisioning) and we currently have no plans to allow variable binding on the WebApp name or Azure account. If you have multiple Azure subscriptions, you will need multiple deployment targets.
If Octopus on-prem licensing (per-target) is an issue moving forward, would our per-user pricing of cloud hosting be an option you could consider?
Unfortunately we’ve had to pull the 2018.7.0 release, as there’s been several problems when upgrading from older versions of Octopus, but once we’ve fixed those issues and released a patch to 2018.7, deployment slots on steps will be an option for you.
With that said, if this is not urgent for you, I’d recommend waiting until you see several patch versions available on the next 2018.7 release (to make sure this is stable for you - especially since you’ll be upgrading from an older 2018.5 version).
Hope this helps.
Cheers
Mark
I’m facing a similar issue trying to get deployment slots working properly with an Azure site step. I’ve created a deployment target for my Azure site and have set the slot to “staging” in the step template. This works fine and deploys to staging properly.
What I need now is a step that swaps the slots from staging to production. I know there’s a script to do that via Powershell, but how would I go about referencing the deployment target’s properties that are needed by the script? Here’s the script:
Switch-AzureRmWebAppSlot -ResourceGroupName #{ResourceGroup} -Name #{Website} -SourceSlotName Staging -DestinationSlotName Production
Assuming I hard-code the slot names, which is fine for me, how would I go about getting the resource group name and web site name from my azure deployment target (or targets if this were done on behalf of multiple targets)? Can I access the target’s properties in the script?
Perhaps a Swap Slot step would be a great addition to the built-in templates that simply takes an Azure deployment target and the two slot names as variables and does the rest.
Thanks
Hi Brian,
Thanks for reaching out.
The resourcegroup and websitename need to come from variables, we have provided a step by step example on how to do this, read https://octopus.com/docs/deployment-examples/azure-deployments/deploying-a-package-to-an-azure-web-app/using-deployment-slots-with-azure-web-apps
I hope this helps
Regards
John
Hi Brian,
Me again!
So we actually expose these as output variables if you are running the Azure Powershell step on behalf of a web app role:
The parameters exposed are documented in https://octopus.com/docs/deployment-process/variables/system-variables#Systemvariables-AzureWebApps
Hope this helps.
Regards
John
Excellent! I’m glad to hear I can pull out the variables. This makes considerably more sense than “polluting” the deployment process with variables that might get out of sync with the actual targets. I’ll give it a try.
This works perfectly, thanks. I still think it would be an awesome template to build somehow since it is such a frequent use-case.
Hi Brian,
I am glad you got it sorted.
Regarding making this a step out of the box, there is https://library.octopus.com/step-templates/7c39a530-6d16-4294-8ff5-74663ea13131 community step, but it looks like it does not support roles.
Maybe you want to add your support behind https://octopusdeploy.uservoice.com/forums/170787-general/suggestions/6939372-make-the-blue-green-model-the-gold-standard-of-dep ?
Cheers
John
