What is a recommended Develop-test-deploy strategy for Azure?

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

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

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

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

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

---

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.

---

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.