views:

32

answers:

2

Hi,

We are new to Azure and are going to deploy our first app in the next few days. I was just wondering if we need to have a more clear cut process in place for test and deploy and how to make it more cost effective.

This is the process I was considering -

1.Develop on local Dev fabric

  1. Maintain a common Build server which also hosts source control (we use TFS for both)

  2. Use the build server for local testing which feeds bugs to development

  3. Have a separate azure account for environment testing - Test-passed builds will be deployed to this account and used for environment testing

  4. Once any issues are fixed and the tests pass, deploy the same build to production account (directly from the build server, i could not think of a way to move from azure test to azure production)

Some points I ll have to take care of -

  1. Data will have to be reproduced from Production to Test servers for the testing to be effective

  2. Build activities will have to be automated to reduce manual errors (especially changing account related parameters like keys)

Do you guys this is fine? Or are there any loopholes in this? I wanted to keep Test account and prod account separate so that the security credentials of our prod can be kept with only key operational personnel. This is sort of what is recommended in one of the Microsoft blogs, but I wanted to get it whetted through a team of experts. Thanks in advance.

A: 

You don't need a separate Azure account. Instead you deploy your newly built azure project into the staging deployment of your azure account, test against that and then swap your azure staging and production deployments.

One thing you never want to do is to deploy a project directly to your azure production deployment. I have seen the process take over 10 minutes to complete and during that time your app will be offline. The staging deployment to production deployment swap is substantially quicker and should only take your app down for 10 to 20 seconds.

sipwiz
Thanks! But what about the data errors? I was mainly worried about that when we use staging - if we create any data, then that data goes into production database - whether it is windows azure or sql azure. Isnt it better to use staging just to check whether the variables are correct?
Roopesh Shenoy
+1 for tip on deployment time. That should definitely help.
Roopesh Shenoy
-1 for getting it wrong.Deployment swap does not incur any down-time for the web roles, since load balancer merely starts routing requests to the new deployment (long-running existing connections will be broken).Using staging for the testing deployments is not recommended, since you are going to share the same config, urls will be messed up (HTTPS certificates will get hairy) plus it's too easy to accidentally hit "Swap" button. Staging is exactly for the pre-deployment staging.
Rinat Abdullin
Yes Rinat, that is exactly my worry about using Staging - also I would not want the dev to need to know production credentials, since it is the ops guys who will be responsible for it. More of organizational policy to have a check in place before deploying to production.
Roopesh Shenoy
+3  A: 

This depends on the methodology. If you are doing iterations then keep testing and production accounts separate, promoting the release only after it makes through the testing.

Important: you might want to start developing against azure fabric as soon as possible (or at least to use azure storage account in the cloud), since Dev and real fabrics are too different at this point. There are a few quirks that can make your life harder if you fully rely on the dev fabric and storage.

If you are into rapid development (i.e.: deploying stable features as soon as they are stable and pass unit tests), then there is no explicit need for a single testing account (although some developers or prototypes might need separate accounts on per case basis). Note, that you might want to automate the deployment process somehow in this case (15 mins to deploy is long) by either using powershell scripts or some sort of the deployment manager that merely uploads binaries to the new AppDomain.

Rinat Abdullin
+1 for quirks - :) I'll just wait to see if any other answers come by, before accepting this. Want to see if there are alternate methods people are using.Currently we mainly do iterations, so your first option seems to reflect what I want to do.
Roopesh Shenoy