V2018.5.1 Azure Web App Deployment Targets

Hello,

First of all as someone who deploys both IaaS and PaaS (moving more towards PaaS) let me say i am glad Octopus is improving its ability to deploy to the cloud. I was rather excited when I read the .5 release notes.

After installing (.5.1) and having a play around i would just like to raise some issues I have when using the new Azure Web App deployment targets. For some context I will try and explain my current setup and how we use the (old) Deploy Azure Web App step. We have a project in Octopus called DAM, Environments called Dev, UAT and Live, and Web Apps in Azure called Dam-Dev, Dam-UAT and Dam-Live. We also use channels for different releases currently 260,262 and 264.

Using the new deployment targets I can create a target for each of the Web Apps and scope them to each of the environments. Perfect. However the issue is when we throw channels and slots into the mix.

Dam-Dev has a slot for each of the channels (260, 262, 264). Currently the Deploy step is not bound to a single web app but is as dynamic name: #{AppName}(#{Octopus.Release.Channel.Name}). The AppName resolves to Dam-Dev and the channel name is the same as the slot name. Therefore I can have 1 deploy step to deploy to cover all channels, based on the channel. For UAT the AppName resoles to Dam-UAT etc.

Using the deployment targets I can only scope 1 web app to an environment. Therefore I can target Dam-Dev/260 OR Dam-Dev-262 and scope it to Dev. But all the channels will deploy to that 1 webapp.

On the UAT environment we deploy to a Staging slot then use a power shell script to swap into production. The deployment target for the UAT environment can be Dam-UAT/Staging and it will still work.

Is there anyway we can target a webapp (Dam-Dev) and then in the deployment step target a slot within the web app using the same bind/unbind feature?

Thanks

Scott

Hi Scott, thanks for providing such valuable feedback.

This is an oversight which we will be looking to address as part of this github issue as a priority. At this point in time we can only recommend not changing the step i.e. not changing to the new Azure deployment targets, until we have the fix in place which should enable this sort of scenario.

Sorry for any inconvenience this has caused!

Regards,
Shaun Marx