Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Azure

Application Life Cycle Management

11/27/2011 11:34:10 AM
- How To Install Windows Server 2012 On VirtualBox
- How To Bypass Torrent Connection Blocking By Your ISP
- How To Install Actual Facebook App On Kindle Fire

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.

2. 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.


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.

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 development fabric and the cloud fabric, which is why it’s important to test your application in the cloud.

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.

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.

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.


Other -----------------
- Sharing Digital Photographs : Exploring Photo-Sharing Communities
- Sharing Digital Photographs : Exploring Online Photo-Editing Applications
- Surfacing SQL Azure Data in Bing Maps by Using the Client Object Model
- Storing and Sharing Files and Other Online Content : Exploring Online Bookmarking Services
- Storing and Sharing Files and Other Online Content : Understanding Cloud Storage & Evaluating Online File-Storage and -Sharing Services
- Integrating the SharePoint Server Object Model and the Entity Data Model (part 2) - Create a Meeting Scheduler Visual Web Part
- Integrating the SharePoint Server Object Model and the Entity Data Model (part 1) - Create a Console Application to Write Data to a SharePoint List
- Collaborating on Presentations : Evaluating Web-Based Presentation Applications (part 2)
- Collaborating on Presentations : Evaluating Web-Based Presentation Applications (part 1)
- Securing the Connection to SQL Azure (part 3) - Surface SQL Azure Data in a Visual Web Part
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
- First look: Apple Watch

- 3 Tips for Maintaining Your Cell Phone Battery (part 1)

- 3 Tips for Maintaining Your Cell Phone Battery (part 2)
programming4us programming4us
Popular tags
Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 windows Phone 7 windows Phone 8
programming4us programming4us
 
programming4us
Natural Miscarriage
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Game Trailer