We recently made big changes to deployment targets and Azure cloud services in Octopus 3.0, and it turns out we got our design wrong. In 3.1, we'll be reverting to the 2.6-era way of deploying Azure cloud services. This change will also affect the way we deploy Azure web apps.
In previous versions of Octopus, Azure cloud services were deployed using a special step type:
The subscription ID and other fields could be bound, letting you use different values just by changing project variables. It worked nicely, but it always felt "different" to how the rest of Octopus works.
In 3.0 we added support for different deployment targets other than Tentacles, and decided to make Azure cloud services a deployment target:
As developers, this felt like a cleaner design since it unified how we deal with all deployment targets. But in reality, while Tentacle and SSH targets are reusable (you might deploy multiple applications to them), Azure cloud services and Azure web applications aren't; the old approach using variables worked much better for many people. Making Azure cloud services and web applications work like Tentacles is a leaky abstraction, and we got the design wrong.
Rather than stick with a bad design, we're going to reverse the decision. For Octopus 3.1, we'll bring back the old Azure step type, and let you use variables instead of machines to control the target. We will be keeping some features of the work we did in 3.0:
- Octopus server will still run the deployments (no need for a separate Tentacle worker)
- Configuration transforms and substitutions will still work on .cspkg files
- We'll still provide a nice UI to choose the target, but let you override it with variables
- There'll be a really nice experience for running Azure PowerShell scripts
What this means for you
If you use Azure web sites or cloud services, stick with 2.6 for now. We'll make sure there's a migration path for Azure steps from 2.6 to 3.1. If you're not using the Azure steps, then go ahead and upgrade.
