Azure deployment targets and variables in 3.0

We have 20+ Azure cloud services and websites per environment (3 environments). Rather than having to create 60+ deployment targets, I’d like the ability to use variables in the Azure deployment target to specify (at the very least) the cloud service (or web app) and storage account to deploy to. This also allows me to bring new cloud services/web apps online without having to create even more targets. In other words, I should be able to reuse one cloud service and one web app deployment target for everything that I do. Short of that, there is not even a “clone” option for a deployment target.

I’m afraid I might be missing something here since I’m kind of confused about the above issue combined with the fact that the data migration from 2.6 -> 3.0 failed with the following (do you not support upgrading projects that already use Azure?):

Error importing DeploymentProcess ‘’ (deploymentprocess-projects-195-snapshot-2):
Azure package deployment steps are no longer supported, please remove them and create a new backup

Hi Page,

Thanks for getting in touch, and I’m sorry the feature redesign for 3.0 Azure doesn’t seem to have had the benefits for you that I thought it would. While the deployment targets are a little extra effort to add than variables, they do have the benefit of being able to add a new target with the same role, redeploy, and now multiple targets can be deployed in parallel. That said I can understand that it adds extra effort to maintain which isn’t good.

To fix this I’d really like to understand your scenario better. Would it be possible to do a screen sharing session to discuss it? This link should help to pick a time that works for both of us:


Thanks Paul. I’ve set up a time for the discussion. I’ll be ready to show
you our current Octopus implementation. Hopefully I’m just not familiar
with the new 3.0 features and there will be a quick/easy resolution.


Am also very interested in having this capability - while I like having the ability to deploy to Azure directly from the Octopus server (instead of a Tentacle), I think manually adding the deployment targets for every cloud service and for every environment will become a significant maintenance overhead for us.

We had a similar set-up:

A tentacle that was designated for Azure deployments, and then a number of variables to define:

  • Deployment Slot (production/staging)
  • Azure Subscription (we have multiple subscriptions ranging from developer MSDN subs for dev/test, through to in house subscriptions for dedicated QA/UAT and then client managed subscriptions for actual production deployments)
  • Cloud Service (the names don’t always match across environments)
  • Storage Account (ditto).

I can see there are benefits to the way the services are configured in 3.0, but it feels like a lot more work to set up these targets for every cloud service and environment combination.

Typically I don’t need to deploy to Dev, QA , UAT and Production simultaneously, as I like to test the releases before I promote to the next environment.

We’re going to reverse direction and go back to the 2.6-era way of deploying cloud services (and Azure web apps). This post has the details:

Thanks everyone for the feedback on this!