1. 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.
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.
Note:
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.
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.
3. Overview of the Solution
Adatum can use the local development fabric and storage 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. Because each 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.
Note:
Don’t forget that any time you do something in Windows Azure,
even if it’s only testing it costs money.
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.
Adatum can also perform some testing by running the application on
the development fabric, 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 development fabric and the cloud runtime environment. Also, cloud
storage is relatively cheap to use as compared to other cloud
resources.
|
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.
|
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.
| 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. |
4. Setup and Physical Deployment
Figure 1
summarizes the application life cycle management approach at
Adatum.
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.
4.1. 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.
| 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. |
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.
4.1.1. 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://bb7ea70c-3be24eb08a08b6d39f801985.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.
Note:
You can quickly roll back a change in production by using
the swap operation.
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.
| Don’t forget, Microsoft will bill you for using
the staging area as well as for using the
production area. |
4.2. 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.
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.
| We use the command-line utility on the build
server to automate the generation of our deployment package
and configuration file. |
4.3. 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 development
fabric running on their local computers. Although the development
fabric 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.
The testing team performs the majority of its tests using the
local development fabric 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.
Note:
Most testing can be performed using the development fabric and
development storage.
| 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. |
