Before reading this article, I highly recommend reading the following previous parts:
Windows Azure typically offers two separate environments for each hosting cloud service, the Production environment and a Staging environment. Staging and Production can use different models, configurations parameters and have a different number of instances. You can configure the Staging environment with a smaller instance number sufficient for testing the application. Further, the connection string and path employed in staging is rather different than production resources. You receive a temporary URL that is accompanied by a GUID followed by your server name when deploying services in the Staging environment.
Moreover, you can swap Production and Staging environments whenever you want, just by pressing the VIP Swap button to move the Staging version to the Production environment and the old Production code to the Staging environment. If something goes wrong, you can immediately swap the two environments again to return to the previous situation and investigate the problem. Remember, the Staging cloud is not free. The Azure billing system starts to calculate usage time when you deploy a service even if in a Staging environment because the Staging environment is identical to the Production environment in terms of the types of servers, network capabilities, processor types and so on.
The cloud services are typically tested for Production readiness in the Staging environment. After testing the service, you can then synchronize it with the Production environment. The Staging option can be found in the deployment setting from the Azure portal as in the following:
![]()
The process of deploying a service to a Staging environment from testing is quite similar to Production deployment. During the deployment, Windows Azure extracts all the assemblies and files from the package and also reads the service configuration file to keep the package ready to run. The following image shows that the service package is being deployed to the Staging environment.
![]()
It is advisable to use 2 different subscriptions for both the Staging and Production environments because the person with access to your Staging environment would also have access to your Production environment. Apart from that, an important point to remember is that the Staging deployment requires a special upgrade regarding Azure subscription. A normal subscription, for example the free trial, can't have the Staging deployment strategy. The Visual Studio IDE even enables you to do Staging deployment from its IDE. Here, you can choose this option from the drop down as in the following:
![]()
So, the sole objective of this small article was to provide you a high-level overview of the Azure cloud services Staging deployment strategy. Here , you acquired an understanding of the importance of a Staging deployment before the final Production in terms of both cloud and ASP.Net services, moreover got an overview of developing and deploying a Windows Azure cloud service in the Staging environment.