Preparing for Application and Service Deployment-Application Life Cycle Management for Windows Azure

http://msdn.microsoft.com/en-us/library/ff803362.aspx

December 6, 2011

This chapter outlines an application life cycle management approach for Windows® Azure™ technology platform applications. Although specific requirements will vary between applications and across organizations, everyone develops applications, then tests them, and finally deploys them. This chapter focuses on where applications should be tested, and how the deployment process should be managed to make sure that only authorized personnel have access to the live production environment.

The Premise

Adatum have a well-defined set of processes for deploying applications to their on-premises servers. They use separate servers for testing, staging, and production. When the development team releases a new version of the application, its progression through the testing, staging, and production servers is tightly controlled. Very rarely, though, small fixes, such as updating the text on an ASPX page, are applied directly to the production servers.

Goals and Requirements

Adatum has a number of goals for application life cycle management for Windows Azure. Adatum wants to have a clearly defined process for deploying applications to Windows Azure, with clearly defined roles and responsibilities. More specifically, it wants to make sure that access to the live environment is only available to a few key people, and that any changes to the live environment are traceable.

You should have a clearly defined process for deploying applications to Windows Azure.

In addition, Adatum wants to be able to roll back the live environment to a previous version if things go wrong. In a worst-case scenario, they would like to be able to pull the application back to be an on-premises application.

Adatum would like to perform some testing on an application in an environment that is as similar as possible to the live environment.

Bharath Says:
	All Windows Azure environments in the cloud are the same; there's nothing special about a test or staging area. However, there are differences between the local Compute Emulator and the cloud environment, which is why it's important to test your application in the cloud.

Finally, Adatum would like to minimize the costs of maintaining all the required environments and be able to identify the costs of running the development and test environments separately from the live production environment.

Don't forget that any time you do something in Windows Azure, even if it's only testing it costs money.

Overview of the Solution

Adatum can use the local Compute Emulator and Storage Emulator for all development tasks and for a great deal of testing before it deploys anything to Windows Azure. However, Adatum must test its applications in the cloud before it deploys them to the live production environment.

To achieve this goal, Adatum has two Windows Azure subscriptions. One is an account used for testing, and one is the live production account. Becauseeach account has its own Windows Live® ID, and its own set of API keys, Adatum can limit access to each environment to a particular set of personnel. Members of the testing team and key members of the development team have access to the testing account. Only two key people in the Adatum operations department have access to the production account.

Both of these accounts are standard Windows Azure accounts, and because they are identical environments, Adatum can be confident that application code will run in the same way on both of them. Adatum can also be sure that application deployment will work in the same way in both environments because it can use the same package to deploy to both test and production.

Bharath Says:
	In Windows Azure, you can be sure that different accounts have identical environments—this is something that's very difficult to guarantee in your on-premises environments.

Adatum can also perform some testing by running the application on the Compute Emulator, but pointing the application at storage in the test Windows Azure environment. This is important because there are more differences between development storage and cloud storage than between the Compute Emulator and the cloud runtime environment. Also, cloud storage is relatively cheap to use as compared to other cloud resources.

Poe Says:
	Because development and testing staff don't have access to the production storage account keys, there's no risk of accidentally testing on live data.

Microsoft bills Adatum separately for the two environments, which makes it easy for Adatum to separate the running costs for the live environment, from the costs associated with development and test. This allows Adatum to manage the product development budget separately from the operational budget, in a manner similar to the way it manages budgets for on-premises applications.

Setup and Physical Deployment

Figure 1 summarizes the application life cycle management approach at Adatum.

Figure 1 

Adatum's application life cycle management environment

The preceding diagram shows the two separate Windows Azure environments that Adatum uses for test and production, as well as the on-premises environment that consists of development computers, test computers, a build server, and a source code management tool.

Windows Azure Environments

There are two ways to access a Windows Azure environment to perform configuration and deployment tasks. The first is through the Windows Azure Developer Portal, where a single Windows Live ID has access to everything in the portal. The second is by using the Windows Azure Service Management API, where API certificates are used to access to all the functionality exposed by the API. In both cases, there is currently no way to restrict users to only be able to manage a subset of the available functionality, for example to only be able to manage the storage aspects of the account. Within Adatum, almost all operations that affect the test or production environment are performed using scripts instead of the Developer portal.

Poe Says:
	We use scripts because it means that we can reliably repeat operations. We're also planning to enhance some of our scripts to record when they were run, by whom, and what parameters were used.

Note:
For information about the Windows Azure Service Management API, see Chapter 5, "Phase 2: Automating Deployment and Using Windows Azure Storage," of this guide.

Within Adatum, only key developers and key members of the testing team have access to the test Windows Azure environment. Only two people in the operations department have access to the production Windows Azure environment.

The Windows Live ID and API certificates used to access the test environment are different from the ones used to access the production system.

Production and Staging Areas

In Windows Azure, you can deploy an application to either a staging or a production area. A common scenario is to deploy first to the staging area and then, at the appropriate time, move the new version to the production area. The two areas are identical environments; the only difference is in the URL you use to access them. In the staging area, the URL will be something obscure like http://bb7ea70c3be24eb08a08b6d39f801985.cloudapp.net,while in the production area you will have a friendly URL like http://aexpense.cloupapp.net. This allows you to test new and updated applications in a private environment that others don't know about. You can also swap the contents of the production and staging areas, which makes it easy to roll back the application to the previous version.

You can quickly roll back a change in production by using the swap operation.

Bharath Says:
	Don't forget, Microsoft will bill you for using the staging area as well as for using the production area.

Note:
The swap is nearly instantaneous because it just involves Windows Azure changing the DNS entries for the two areas.

For information about rolling upgrades across multiple role instances and partial application upgrades that upgrade individual roles, see the MSDN documentation at http://msdn.microsoft.com/en-us/library/ee517254.aspx.

Deployment

To deploy an application to Windows Azure you must upload two files: the service package file that contains all your applications files and the service configuration file that contains your applications configuration data. You can generate the service package file either by using the Cspack.exe utility or by using Visual Studio if you have installed the Windows Azure Tools for Microsoft Visual Studio.

Markus Says:
	We use the command-line utility on the build server to automate the generation of our deployment package and configuration file.

Adatum uses the same package file to deploy to the test and production environments, but they do modify the configuration file. For the aExpense application, the key difference between the contents of the test and production configuration files is the storage connection strings. This information is unique to each Windows Azure subscription and uses randomly generated access keys. Only the two key people in the operations department have access to the storage access keys for the production environment, which makes it impossible for anyone else to use production storage during testing accidentally. Adatum uses a set of scripts to perform the deployment, and one of the tasks of these scripts is to replace the local development storage connection strings in the configuration file with the specific connection strings for the cloud-based storage.

Note:
For more information about the deployment scripts, see Chapter 5, "Phase 2: Automating Deployment and Using Windows Azure Storage."

Testing

Adatum tests its cloud-based applications in a number of different environments before it deploys the application to the live production environment.

Developers run unit tests and ad-hoc tests on the Compute Emulator running on their local computers. Although the Compute Emulator is not identical to the cloud environment, it is suitable for developers to run tests on their own code. The build server also runs a suite of tests as a part of the standard build process. This is no different from the normal development practices for on-premises applications.

Most testing can be performed using the Compute Emulator and Storage Emulator.

The testing team performs the majority of its tests using the local Compute Emulator as well. They only deploy the application to the Windows Azure test environment to test the final configuration of the application before it is passed to the admin team for deployment to production. This way, they can minimize the costs associated with the test environment by limiting the time that they have an application deployed in the cloud.

Jana Says:
	You can deploy an application to your Windows Azure test environment just while you run the tests. You only get charged when you use the environment. However, you are charged by the hour, so a 15-minute test will cost the same as a 55-minute test.

More Information

MSDN® contains plenty of information about Windows Azure. A good starting to learn more about deploying applications to Windows Azure is at http://msdn.microsoft.com/en-us/library/dd163896.aspx.

The Windows Azure Getting Started page (http://www.microsoft.com/windowsazure/getstarted) contains links to plenty of resources to help you learn about managing applications in Windows Azure.