I have an Azure deployment set up on my projects. Recently I wanted to try out the VIP swap so I can deploy to Staging and then switch production over to it to minimize down time. If I enter slot Production then it deploys to production with down time. If I enter Staging then it deploys to Staging, but it never swaps. Am I missing something? See the log below:
@@@
2013-12-15 22:36:41 DEBUG [Azure Deployment] Script: C:\Octopus\Data\tmp\deployments-2753\BootstrapDeployToAzure.ps1
2013-12-15 22:36:41 INFO [Azure Deployment] Azure deployment parameters:
2013-12-15 22:36:41 INFO [Azure Deployment] Subscription ID: XXXXXXXXXXX4525
2013-12-15 22:36:41 INFO [Azure Deployment] Subscription name: XXXXXXXXXXXXa7065698bba
2013-12-15 22:36:41 INFO [Azure Deployment] Cloud service name: XXXXXXXX-query-dev
2013-12-15 22:36:41 INFO [Azure Deployment] Storage account name: XXXXXXXXXXdev
2013-12-15 22:36:41 INFO [Azure Deployment] Slot: Staging
2013-12-15 22:36:41 INFO [Azure Deployment] Package URI: https://XXXXXXXXXXXXXX.blob.core.windows.net/octopuspackages/XXXXery.Azure.1.0.0.456_XXXXXXXXXXXXXXXXX7.cspkg
2013-12-15 22:36:41 INFO [Azure Deployment] Configuration file: C:\Octopus\Data\tmp\deployments-2753\ServiceConfiguration.Cloud.cscfg
2013-12-15 22:36:41 INFO [Azure Deployment] Deployment label: XXXXXXX service (DEV) v1.0.0.456
2013-12-15 22:36:41 INFO [Azure Deployment] Allow swap: True
2013-12-15 22:36:41 INFO [Azure Deployment] Importing Windows Azure modules
2013-12-15 22:36:41 INFO [Azure Deployment] Loading the management certificate
2013-12-15 22:36:42 INFO [Azure Deployment] Setting up the Azure subscription
2013-12-15 22:36:42 INFO [Azure Deployment] Starting the Azure deployment process
2013-12-15 22:36:43 INFO [Azure Deployment] A deployment already exists in XXXXX-query-dev for slot Staging. Upgrading deployment…
2013-12-15 22:38:36 INFO [Azure Deployment] OperationDescription OperationId OperationStatus
2013-12-15 22:38:36 INFO [Azure Deployment] -------------------- ----------- ---------------
2013-12-15 22:38:36 INFO [Azure Deployment] Set-AzureDeployment 22f45a78-d8b4-37b5-XXXX… Succeeded
2013-12-15 22:38:37 INFO [Azure Deployment] Deployment complete; Deployment ID: 099fd6d9bc5c4b6XXXXXXXXXXXX
2013-12-15 22:38:37 INFO [Azure Deployment] WARNING: The default subscription is being removed. Use Select-Subscription
2013-12-15 22:38:37 INFO [Azure Deployment] to select a new default subscription.
2013-12-15 22:38:37 INFO [Azure Deployment] WARNING: The current subscription is being removed. Use Select-Subscription
2013-12-15 22:38:37 INFO [Azure Deployment] to select a new current subscription.
2013-12-15 22:38:37 DEBUG Deleting temporary directory C:\Octopus\Data\tmp\deployments-2753
@@@
You need to set up two environments in Octopus - Staging and Production - and then in the Slot setting, use #{Octopus.Environment.Name} instead of specifying Staging or Production. This way when you deploy to the Staging environment in Octopus, you are deploying to the Staging slot, and the Production environment in Octopus will be the Azure Production slot. Swapping will then work.
Aha, so the swap only happens when you do “promote” in Octopus? Any chance this will be more flexible in Octopus 2, this seems a little strange to me, afaik one way to use the staging in Azure is to just get the site/services running (JIT compile, etc) before you swap (then you can kill the staging instances). At least that’s how I wanted to use it.
Another way to approach this would be to copy the Azure deployment step in your project - first deploy the package to the Staging slot, then deploy it to the Production slot in the second step. But this means you would always deploy to both - there wouldn’t be a chance to deploy to staging, test it, then swap.
Hmm, so what determines that it can swap vs nothing happens? Is it just the promote action? If that’s the case, how can the scenarios below work, wouldn’t it just deploy to Prod without a swap?
Got it to work now, thanks! Now the only thing I’m missing is a way to (optionally) shutdown the staging machines after a promote. Any chance of that in v2?
“Another way to approach this would be to copy the Azure deployment step in your project - first deploy the package to the Staging slot, then deploy it to the Production slot in the second step.”
I don’t think this would work out of the box, as the DeployToAzure.ps1 uses the following check to see if swap is possible
$staging.Label -eq $OctopusAzureDeploymentLabel
The labels for two steps are never alike in Octopus 2.0. They are based on the step name and also the version. Since a release process cannot have two steps with the same name (this is rejected in the UI if you attempt it), a two-step staging to prod swap is not possible.
Hi Peter, nice work! Going to use your Delete-Staging-slot function
Would also recommend Steven Kuhns (chartek) WaitForRoleInstancesReady function. We use that as well as a simple http request to the staging slot to warm up the app in IIS before swapping to reduce the first request penalty time.
