Octopus update introduces breaking UI constraints

Legacy Cloud
1

As the title states, recent Octopus updates introduce constraints in the UI that breaks compatibility with how we handled our CI process.

Our Process:

  1. Team City builds latest of master branch and pushes packages to Octopus
  2. Octopus begins deploying the received package in a test environment within Azure
    1. Test resource group created for specific release
    2. ARM template run to create infrastructure resources within Azure
    3. Octopus ‘Deploy Azure Web App’ step used to deploy package to target App Service
  3. Testing occurs in that environment - if successful, environment torn down and package deployed to production

The problem:
Unfortunately, the UI of the ‘Deploy Azure Web App’ step now requires us to define a scope that the step is invoked on behalf of. This scope requires a deployment target, which in turn requires a web app. Due to our process, the web app won’t exist until the ARM template is run, which puts us into a bit of a Catch 22 situation. We can create a deployment target in a Powershell script in a step before the ‘Deploy Azure Web App’ step, but since the scope doesn’t exist before the deployment begins, the UI will not let us proceed without a suitable deployment target already available.

Note: this is only affecting us in creating new deployment processes. Our already-defined processes are still working successfully, which makes me believe this is an unintended consequence of some UI updates, and not a genuine, new requirement from Octopus.

Please let me know if there’s some update we need to bring about in our process, or if you require any more information. Thanks.

3

Hi Matthew,

Thanks for getting in touch.

With the new dynamic provisioning available in Octopus, you can now define a role on your step (even if that role doesn’t exist yet). When you start typing in the role selector on the step, it will give you the option to “add role”, just like the role selector on your deployment targets.

^ This is not entirely clear and is something we’re looking to make more intuitive.

We published a blog article recently that delves into a pretty full-on example, but the general process would be:

  • Enable dynamic provisioning for your project and environment, E.g.
    • Under your project settings, change “Dynamic Targets” to “Allow deployments to be created when there are no deployment targets”
    • Under your environment(s), make sure you’ve opted in to “Allow managing dynamic infrastructure”
  • Create your Azure Web App as part of your deployment process (you can see an example of how to do this in our dynamic infrastructure documentation), E.g.
    • Add a PowerShell script step and customise the example script found here, specifying your desired role (“my-new-role”)
  • You can then create an Azure Web App step, and manually create a role “my-new-role” using the role selector

When you call this New-OctopusAzureWebAppTarget cmdlet (from your earlier provisioning step), it will take care of creating the target, running a health check and then when your Azure Web App step runs, it will be available as part of the role scoping you defined.

I hope this helps and will work in your scenario. Let me know how you go.

Cheers
Mark

4

Hi Mark,

Thank you for the prompt response.

I will get back to you in the next few days once this has been implemented our side and let you know how it goes.

Regards,
Matthew

6

Hi again,

I can confirm this worked for our requirements. Thanks again.

Regards,
Matthew

7

Awesome, thanks for letting us know Matthew. Glad you got it sorted.

Cheers
Mark