This is how I manage my production/acceptance/test environments (note that I'm not using the word staging). For each environment, I create the following (depending on the project):
- Cloud Service
- Storage Account
- SQL Azure Server + Database
- AppFabric (ACS, ...) Namespace
- Virtual Machines
So let's assume I have an app called myapp, then my environments would look like this:
- Production
- Cloud Service: myapp-prod.cloudapp.net
- Storage Account: myapp-prod
- SQL Azure Server containing 1 database: MyApp
- Acceptance
- Cloud Service: myapp-acce.cloudapp.net
- Storage Account: myapp-acce
- SQL Azure Server containing 1 database: MyAppAcce
- Test
So all environments have a version of the app running in the production deployment slot. I only use the staging deployment slot whenever I want to do a VIP swap for my production environment (note the difference between production deployment slot and production environment).
There are a few advantages to this approach where you have dedicated components (like storage accounts) per environment:
- It's easy to test new releases without impacting the real application.
- You can have different security per environment (for example, all developers have access to the keys for the test storage account)
- If you're testing your application you can work with real URLs + SSL instead of that long and ugly staging URL.
- It's easy to test the integration with ACS since each environment will have its dedicated namespace.
- Using Visual Studio you can easiliy manage settings per environment.
- And last but not least, you have to know that the scalability targets of Windows Azure Storage apply to the storage account level. This means that if you use a single storage account for all your environments, you might be reducing the performance of your app in production because you're doing stress tests on the app running in staging. If you use a storage account per environment, you won't impact other environments when you do something.