7

We're using Azure Cloud Services and would like to have a workflow where deployments flow as

Cloud Service #1: testing/QA => staging => production

Currently Azure Cloud Services only have staging and production environments where you can swap the deployments. How are folks accommodating a more traditional 3 stage approach as shown above?

We currently do the following

Cloud Service #1: testing/QA => Cloud Service #2: staging => production

but this is painful and feels kludgy since going from Cloud Service A => Cloud Service B is essentially a full redeploy rather simply switching IPs or swapping behind the load balancer.

Improve this question
3
  • 1
    As written, this question is off-topic because it is asking how to set up a development/staging environment in a specific vendor's cloud service. If you can rewrite this to be vendor-agnostic it would help: i.e., "given these constraints, how would one set up the environment to achieve goal X?"
    – user22815
    Oct 22, 2015 at 2:04
  • 1
    But the issue is vendor specific, although for one of the largest clouds on the planet. E.g. Windows issues will be vendor specific with no generalized Q&A. What's your idea?
    – DeepSpace101
    Oct 22, 2015 at 2:56
  • I would suggest testing, staging, and production environments be three separate cloud services where each has a staging slot and production slot. Slots are good for validating environment-specific configuration prior to the ip swap. Environments will vary based on the maturity of the deployment package as well as (Hopefully!) on things like keys and certificates. (I definitely want my staging environment to have keys and certs that are distinct from my production environment, e.g.!)
    – Greg D
    Dec 21, 2015 at 22:26

1 Answer 1

Reset to default
1

We are developing a number of services hosted as azure web apps. Some of the services have testing, staging and production web apps. These are different web apps. In addition each of these have preview and production slots for deployment with no or minimal downtime. In addition to this we have primary and failover instances behind a traffic manager so to sum up. One logical service can have up to 12 web apps. This is all streamlined with deployment through git triggered from teamcity with a clear hierarchy enforced where a commit must have been deployed to testing and staging before hitting production.

All this is possible because web apps are same price for one or multiple. I realize you are using cloud services and not web apps but the same applies where they are seperate services. We don't use the slot feature for staging.

Improve this answer
1
  • That approach worked for me, too.
    – marstato
    Oct 12, 2017 at 11:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.