Azure Web App deployment with multiple environments and a single subscription/web app using deployment slot

Legacy Modelling
1

We currently have a single Azure subscription and intend to leverage Web App deployment slots for lifecycle management. It appears that an Azure Web App corresponds to a single environment within Octopus, which would require some duplication of Web App links to have a project lifecycle in Octopus?

I’m currently thinking I would like deployment to flow like so:

Dev creates nuget package for Web App and new release of Octopus Project
Web App is immediately deployed to the staging deployment slot in Azure via the Octopus STAGE environment as lifecycle step one with continuous deployment
Users and Dev test newly deployed staging code in Azure
Dev kicks off promotion to PRODUCTION environment in Octopus for final lifecycle step
Octopus “deploy’s” via Powershell to execute a slot swap, effectively “promoting” the stage slot to production

 (Invoke-AzureRmResourceAction -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots -ResourceName [app name]/[slot name] -Action slotsswap)

It seems like this would require the following objects in Octopus:
STAGE environment (pointing to the webapp in Azure)
PRODUCTION environment (pointing to the SAME webapp in Azure - this being my duplication)
LifeCycle with continuous deployment to STAGE and manual deployment to PRODUCTION
WebApp project with Deploy Web App step scoped to the STAGE environment and SlotSwap step scoped to Production

Does it make sense to duplicate WebApp information twice within Octopus and then use Project step scopes to limit functionality, or is there a more out-of-the-box approach that I’m missing? Is there a way to tie my STAGE environment to the stage slow within the Web App?

2

Hi Justin,

We have a demo project setup on our demo site that should fit your scenario pretty well with a few modification, the slot creation step is optional and you’d scope the web app deployment step to
your staging environment and the web app slot swap to your production environment.

To tie your staging environment to the staging slot, you can create a project variable for your slots and then scope them to each environments and then use that to bind the web app name in the deployment step (so you would have a variable for your web app name and one for the slot) using the following syntax #{WebAppName}(#{WebAppSlotName}).

I hope that helps!

Thank you and best regards,
Henrik

3

Man, I hadn’t found that with my research. That clears the picture up quite a bit. It looks like, using the variables, I should even be able to leverage my Azure Stage environment for multiple sites in Azure rather than an environment per site. And it sounds like there’s no sniff test failure of duplicating the environment to get an Azure Production environment as well. I think I can move forward with that.

Thanks for the help!