This past Tuesday I attended a Webinar led by ALM Ranger and Microsoft MVP Esteban Garcia (@EstebanFGarcia). The topic? Azure and Visual Studio Online (VSO), specifically around deployments (or so I thought). There was more content in this session than I expected to get, that’s for sure!

My primary goal in attending the session was to get a better picture of how deployments worked from VSO code repositories into the Azure cloud, but as a bonus there was also coverage of VSO load testing functionality, as well as Application Insights.

Continuous Deployment to Azure

The demo of how the deployment to Azure works is very impressive. The approach is very simple:

1. Go to Windows Azure.
2. Create a site.
3. Add a ‘resource’ to the site, selecting your source control repository in VSO.
4. Select the branch you wish to continuously deploy from.
5. A background process automatically creates the build definition required for the deployment and hooks it up so that every check-in gets deployed to your Azure site.

Alternatively, you can also set things up using the Continuous Deployment tile to access this wizard.

The time for the deployment to execute obviously becomes a factor here, as it seems to take several minutes for even a simple build to be deployed. I would expect some fiddling would be required here to get the deployment time trimmed down as much as possible.

Load Testing

Using standard Visual Studio load testing projects, VSO load testing allows you to execute your load tests in a hosted cloud environment, paying only for the load testing you use. Obviously, if you are doing a lot of ongoing load testing, it is more cost effective to host your own software and do this in-house. However, for those of us who only occasionally have a client willing to pay for load testing, this “pay for what you use” model is perfect.

The billing seems to be tracking “virtual user minutes“, which equates to the number of virtual users configured in the load test multiplied by the number of minutes that the test is configured to run. This math also means that lower-end users of this type of functionality will probably try to optimize their spending, which may lead to less than optimal test results. This class of users will either not be accurately reflecting their load (lowering number of users) or will not run the test long enough to find issues (number of minutes).

Application Insights

I must have had my head in the ground not to have heard of this until now, but VSO has an analytics/monitoring capability now available from the Azure and VSO interfaces. Applications Insights instrumentation adds into your application much like Google Analytics or other analytics tools by using a JS snippet that you add to your page. This then opens up the ability for you to monitor usage, availability, and performance.

Application Insights can be added to a web application project in Visual Studio (recommended by Microsoft), which will add a new configuration file into your project. An agent can also be installed on the server without making any changes to the application.

Bringing the big picture together

In terms of putting all your data in one place for the team, this is ideal. From an Azure level, the operations team can access the data directly from the site management interface. From VSO, the development team and product team can access the data directly from their product/code management interface.

Both sides of the DevOps group get to see what they need, when they need it, in the interfaces they use. A really nice story, on the surface. I look forward to digging down deeper here to see what the nitty gritty details of it all really are!