Share via

Testing Applications in Azure

  • Article

Test On-Premise

  • Most but not all of the functional testing can be done on-premise running the cloud application in Compute Emulator
  • Most but not all of the functional testing can be done on-premise on Storage Emulator
  • Most but not all of the database testing can be done on an on-premise SQL Server R2 instance

Code Coverage

Test Early In-Cloud

Test Scenarios specific to Cloud

  • Concurrency: Most of the times, your application will run with multiple roles accessing the same resource like Database. Hence it’s important to test for concurrency and deadlock.
  • SQL Azure throttling: Your application will be throttled by SQL Azure under high load and your writes might fail. Hence it’s important to implement exponential backoff http://geekswithblogs.net/hroggero/archive/2011/05/26/cloud-lesson-learned-exponential-backoff.aspx
  • Configuration changes: If you change the value of a setting in the configuration file of an already deployed service, the service isn’t restarted. If you are storing the value of a setting in a variable which gets initialized in the constructor, this value will not be updated. Hence you will be always reading stale values. It’s always better to read from the settings at any time instead of a local variable.
  • Elevated Privilege: If you are running a command on startup which requires administrative rights, it’s important that you run it under elevated privilege or your role will fail to start http://msdn.microsoft.com/en-us/library/gg456327.aspx
  • Certificates: If your application is consuming a service which requires you to have the private key in your local store, sometimes people forget to add the additional certificate configuration. Hence the service works in Compute Emulator but not on cloud http://blogs.msdn.com/b/windowsazure/archive/2011/09/07/field-note-using-certificate-based-encryption-in-windows-azure-applications.aspx
  • SQL Azure Limitations: Make sure you don’t make use of any features that aren’t available in SQL Azure http://msdn.microsoft.com/en-us/library/windowsazure/ff394102.aspx
  • Capacity Panning: You can scale out anytime on runtime after the deployment by increasing the number of role instances. But you cannot scale up on runtime and requires redeployment. Hence it’s important to choose the right VM instance size http://www.microsoft.com/windowsazure/features/compute/
  • Topology: You can improve your performance and reduce your billing by deploying both the Hosted Service and the SQL Azure Database in the same data center. You should also choose the data center which is close to your customers.
  • Confidentiality: If you are developing a confidential application, one of the things you can do is to never deploy on the Production slot until you are ready to be live. You can deploy on the staging slot which will generate a  random URL which is not easily discoverable.
  • Security: If you are developing your application for specific customers only, consider securing your application with ACS http://acs.codeplex.com/documentation
  • Bottleneck: Most of the times, the database will be the bottleneck. You can easily scale out your web role and worker role but scaling out the database isn’t easy. You can scale out the database using Data Sync http://www.microsoft.com/windowsazure/features/database/#data-sync . You can configure multiple hosted services pointing to their own database which are synched. The hosted services and be managed by Azure Traffic Manager http://msdn.microsoft.com/en-us/gg197529
  • Rollback: Always deploy your newer version on a staging slot and then VIP swap it with the production slot which has the older version. This way you will always have the older version on the staging slot in case you need to rollback.
  • Failover: You should be prepared for situations where your dependent services might go down even though they have a strict SLA. Hence have a failover hosted service and database in a different datacenter in case of disaster recovery.
  • Platform Upgrades: Since you don’t own the platform, some upgrades might potentially break you. Hence it’s important to have continuous integration so that you test your application on a regular basis.
  • Monitoring: Use SCOM from monitoring the availability and Performance of your services http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=11324

Automate Deployment

Continuous Integration

  • Building and packaging cloud projects is possible by passing the parameter /t:publish to msbuild
  • Deployment can be automated by following the steps mentioned above. You just need to call the scripts from your Lab Environment
  • Automated test can be created in Visual Studio and added to the Microsoft Test Manager
  • Perform Daily Build-Deploy-Test using TFS 2010 http://social.technet.microsoft.com/wiki/contents/articles/tfs-2010-build-deploy-test.aspx

In-Cloud Performance Testing

SQL Azure Performance Tuning