One frequent question we get is around “process guidance”. Also known by the more modern and fancy acronym “ALM”: Application Lifecycle Management, which replaced the old SDLC term, which in turn (and only if you are old enough like me) meant something completely different, but I digress….

Application lifecycle management on Windows Azure has some special considerations. Among the three things that clearly impact ALM from my perspective are the following:

1. Deploying an application on Windows Azure is a very specific set of tasks. You don’t really have a lot of options.
2. Any resource that you acquire on Windows Azure costs money.
3. The notion of an “environment” in the cloud (think “production”, “test”, “beta testing”) is an illusion.

Let’s look at each of these.

#1 is just a consequence of the available interfaces that Windows Azure exposes. You can’t copy files or deploy an MSI on Windows Azure. You have to package your app with a set of specific tools and then either using the portal or the management APIs upload the result of that packaging to Azure for processing. This is conceptually very similar to what I described years ago on my post about Northwind Hosting on-boarding.

#2 is pretty obvious. You will pay for servers and databases and storage even if you are just testing your application. Windows Azure doesn’t care and doesn’t know you are “just testing”. Which leads to #3: the notion of “production” or “staging’ or “testing” is an illusion. From Windows Azure perspective everything is production.  Even today’s “production” “staging” labels are just DNS tricks. You pay the same, the VM is the same, etc.

One last thing that impacts lifecycle is the lack of ACLs on any management tasks. The LiveID account defined for service management can do anything. It’s a root user and you can’t define finer grained access to the service. For example, you can’t say “LiveID1” can create storage accounts, “LiveID2” can delete" services, etc.

Note: for an excellent overview of the account model, see Patrick’s post here.  

And there’s only 1 service management LiveID per subscription. If you are working on a team, it means all member of that team that needs access to Azure Portal will have to share that account.

This limitation is partially alleviated by the fact that the Management API uses a different authentication mechanism: certificates. And yes, you can have a few of those. Yet, each will grant access to everything.

Our own current environment looks more or less like this:

• Our dev team typically runs against the local dev fabric.
• All code is checked-in on TFS (our source code management tool).
• The build server runs tests locally too.
• Packaging and deployment to Windows Azure is automated (scripts are included in the last drop and see Scott’s post for more detail).
• The Test team runs tests both locally and on the “live” environment.
• We all share a single Admin LiveID that we use to (seldom) access the portal.
• We all use the MMC.

It is not difficult to imagine more complex requirements. For example, we don’t really have a “production” service since nobody uses our sample application (a-Expense). But extending the above architecture is not that complex.

Here’s a simple expansion considering 2 environments and an additional role that manages deployments “production”:

Notice that “production” could potentially be another subscription (with its own separate Admin LiveID / Certificates).