Azure Cloud Service - Swap staging to production if possible - does not update app Settings

Legacy Uncategorised
1

Hi,

It seems that app settings are only updated when a deployment is done, not when a swap is performed - is this correct?

If so - how do you handle the case where you want new configuration to be applied in Production?
Cheers
Joe

2

Hi Joseph,

Thanks for getting in touch! You are correct, and I’ve updated our documentation to provide more insight into how VIP Swap is used in Octopus: http://docs.octopusdeploy.com/display/OD/VIP+Swap

This is more of an Azure Cloud Service problem, and there is no automated way to change anything about the instances in your Cloud Service based on a VIP Swap - after all the VIP Swap is just a change in the inbound networking configuration in Azure.

Having worked with Cloud Services a fair bit, I would recommend configuring your application(s) so they can work agnostic of whether they are in the “staging” or “production” slot. This enables you to perform automated or manual tests against the instances in your “staging” slot before you promote to “production”. In this case what is in the “staging” slot is the next “production” candidate and should be talking to the same database etc.

If what you want is to implement multiple separate logical environments, like typical Octopus environments, where Production and Staging use different database instances… I would suggest you should be deploying into different Cloud Services, one for Staging and one for Production. Then you could consider whether you like deploying directly into the “prodcution” slot (which rolls through your instances by upgrade domain) or whether you would prefer to deploy into the “staging” slot and then VIP swap so you have a true Blue/Green deployment as described in the documentation page I linked earlier.

In some ways I find the names Staging and Production to be overloaded, and confusing when combining Octopus and Cloud Servies.

Hope that helps!
Mike

3

Hi Mike,

Thanks for clearing that up.

Cheers
Joe

4

Hi Joe,

No worries and Happy Deployments!
Mike

5

Mike,

I think we will approach as follows – I you can see any flaws with this approach please leave a comment :slight_smile:

Our Cloud Service is a WorkerRole that reads a Service Bus queue. That means if we have the same configuration then the Staging instance will be able to read from the “live” message queue.

I think I will configure the Octopus deployment step to deploy to Staging/Production via custom binding variable, with the option to “swap staging to production if possible”.

I will configure the deployment package with “qa” configuration – in this case a different queue name. That means that when we deploy to QA the package will be deployed to Staging slot with a test queue name & will not affect Live environment. Then when we use Octopus to promote to Live it will mean a manual step to update the configuration of Production instance and stop/delete the Staging instance.

Joe

6

Hi Joe,

Thanks for getting back to me! Yeah, Cloud Services, slots and VIP swapping make a lot of sense for Web Servers where the requests are inbound, or push-based.

Pull-based systems, like queue processors, you don’t really get any benefit from slots and VIP swapping. As soon as the queue processor can pull messages from the queue, it’s going to start processing them!

At this point I can make a couple of recommendations:

  1. Don’t overcomplicate things by using slots and VIP swaps unless you really feel like there is some benefit. Instead consider promoting your queue processors through logical environments and only promote them when you are happy.
  2. Add a “software level” remote-control to your queue processors which lets you configure them at runtime - but this might be more complex once you start digging in to it.
  3. This might seem crazy at first, but I’ve had a lot of success using this: https://github.com/MRCollective/AzureWebFarm.OctopusDeploy It configures your Cloud Service instances as deployment targets in Octopus which means you can deploy to them like they are VM’s, but get all the benefits of Cloud Services. This would work really nicely when paired with Elastic and Transient Environment support in Octopus 3.4+.

Hope that helps!
Mike

7

thanks Mike will take a look

8

Hi Joe,

No worries and hope you have success. :slight_smile:

Happy Deployments!
Mike