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?