++ to Ryan Anthony's idea, we've run into the same issue and had to roll our own code to pull the output of a previous Azure deployment step and select subscriptions and whatnot in a custom PS script.

FWIW I think #2 is a hairy idea to implement - cracking open a binary to modify it means you now no longer have the assurance that you are deploying the same binary to all environments (in fact, you've guaranteed you aren't). If an issue crops up with a deployment to one environment, you can no longer isolate the issue to the configuration alone as the binary could have changed as well. You could argue that the web.config isn't really part of the binary, but if it's in the cspkg, I would classify it as such.

In addition, I'd like to see a "Run a PowerShell script for Azure" step type that does a similar job that BootstrapDeployToAzure.ps1 does when you do a "Deploy to Windows Azure", only it just runs a custom script.

We have a situation where we are pushing the same cloud service to multiple regions (all behind Azure Traffic Manager), and would like to Swap all of the Cloud Services once they are all running (i.e. WaitForRoleInstancesReady).

Not sure if this was covered elsewhere, but a way to speed up Azure deployment (with multiple instances) would be not trigger all updates, but not wait for the result until the last step (like an async-checkbox on the steps that are started in the background). I have several instances (different cloud services) that I have to do sequentially today because there's no other option in Octopus, but if I could trigger them all and then wait for them all to finish then I could significantly cut my overall deployment time.

For variable substitutions, you'll want to consider the fact that a single web role can contain multiple sites. For proper support, you'd need to add another axis to your scope or some other strategy for defining distinct substitutions per site for a given role.

Supporting something like https://github.com/MRCollective/AzureWebFarm.OctopusDeploy natively would be fantastic. We're currently building out tooling around this at FunnelFire, because Azure deployments are slooooow and using Octopus to do the deploy would be much faster, not to mention better for release management.

Support for Azure Pack would be nice as well.

Some other nice features we have added manually by modifying DeployToAzure.ps1 is:

- Wait until all instances are ready before executing the swap. We don't want to swap our staging to production if they are not a) Reporting state Ready b) IIS is warmed up. We've solved this a) polling the Azure instances for their state and b) doing http requests against the staging slot on a set of URLs, so that the first user does not get the usual warmup penalty hit.

A bit like this fork of DeployToAzure.ps1, but we added smoke tests to the staging slot as well.

https://gist.github.com/plillevold/9068433

+1 to both

I'd also love to see a "shutdown staging after X minutes" option.