Anyone who has worked on a software development project will be familiar with the concept of an “environment”. Simply put, an environment is a set of infrastructure that you can deploy your application to, supporting a specific activity in your software development lifecycle. Any significant project will have multiple environments, generally with names such as “Test”, “UAT”, “Staging” and “Production”.

When teams first start working with Windows Azure, they are often unsure about how to effectively represent the familiar concept of  “environments” using the capabilities of the cloud. They note that every deployment has a “Production” and a “Staging” slot, but what about all their other environments, such as Test or UAT? Other teams ask if they should host some environments on their own servers running under the compute emulator.

Tom Hollander from Microsoft Services’ Worldwide Windows Azure Team has put together a post that explains how to use Windows Azure abstractions such as billing accounts, subscriptions and hosted services to represent different environments needed throughout the development lifecycle. With some careful planning, each team and activity should be able to use their environments with an appropriate mix of flexibility and control.

Click here to read the full post and learn how to plan environments for your next Windows Azure team project.