** Important note – Please read before reading further **
The content in this post was first written in 2011, exploring the earlier versions of Windows Azure. Since then, Windows Azure has evolved quite a lot, as well as other services in the Microsoft portfolio.
We now have an official solution to run load tests on Azure – load testing is part of Team Foundation Service and a preview is available. If you haven’t tried it already, I’d encourage you to try it.
Find out more at https://aka.ms/loadtfs.
If you’ve read the last 2 posts, you already know we’re building a proof-of-concept test rig using Visual Studio Test Agents hosted on Windows Azure. For the final part of this post, we’ll look at the deployment procedure.
I usually start by deploying just 1 instance from Visual Studio. There’s no point in jumping to the deployment of the full rig because currently there’s no option to setup Windows Azure Connect other than using the Management Portal and doing it manually. Let’s go by it step-by-step.
To deploy the first instance, the number of instances of my Worker Role in the Service Configuration file should be set to 1.
You can then Publish by right-clicking on the Cloud project and choosing Publish. Configure your target Hosted Service and environment and click OK to start deploying. At this point, Visual Studio will compile and generate your service package and then start uploading it to Windows Azure. Afterwards, it will trigger the deployment of the configured instance for your role. The whole process might take a while (around 15 minutes).
During this time, you should navigate to the Management Portal and take a look at what’s going on from the Hosted Services screen. The Hosted Services screen will allow you to track the deployment process.
The other screen you should be looking at periodically is the Virtual Network screen. When the instances are deployed, because they are enabled for Connect, they will show up here on the section “Activated Endpoints”. This section will contain a reference to your Controller machine, since you installed the Connect agent there.
Once it shows your new instance (a new entry named RD-something), you’ll be able to navigate to the “Groups and Roles” section, create a Group and create a Role Connection between your service and the Endpoint Group you just created.
It will look something like this:
Once you’ve done this, you can sit and wait for this first instance to install. You’ll notice that, on the Controller machine, once the instance is set as ready, you’ll be able to get an IPv6 for it and the Connect agent icon changes to show the connection is active.
If you feel the deployment is hung, a good tip is to reimage the instance.
Once this instance is Active, you can just change the configuration to add some instances. You can use the Management Portal to do so, choosing the Deployment and clicking “Configure” on the ribbon. Try changing the number of instances to 5, for example.
You’ll notice that every new instance you create will register with your local test Controller and become an Agent itself.
The only thing left is to reimage your first image so that it too registers with the Controller and your rig is now done! You should now be able to run Test Projects using this rig and collect the results.
You can download a sample project here. This sample project, the scripts and the code are provided as-is, without responsibility for support, and is the result of my curiosity and very limited testing. Remember that you need to change some settings on the configuration and the scripts, such as the download URL for the VS Agent software and the usernames and passwords which are created or used in the schedule task, as well as the name of your Controller Machine on the VS Agent setup command line.