At GoldMail, we like to be using the most recent version of the Azure Tools and SDK for two reasons. One, we can take advantage of the newest features, and two, we don’t get too far behind, which may cause problems down the line. This can be problematic, as we have a lot of services, a lot of other work to do, and the Azure team is pushing out iterations pretty quickly. They were coming out every 3-4 months until this last one (June 2012), which was almost 7 months.
All of our infrastructure runs on Windows Azure. The exceptions are the desktop client (WinForms) and the Flash player. So when we update our tools version, it impacts everybody in Engineering, and our build engineer in Operations (we call him Awesome Jack).
The new version of the Tools/SDK (1.7) will run side-by-side with the previous version (1.6) (thank you Microsoft!). From information provided at the MVP Summit, I knew this was going to be the case, so we updated to 1.6 in March, which was a small update that didn’t impact us. This would allow us more flexibility when updating to 1.7.
Upgrading from Tools 1.6 to Tools 1.7
First, I installed the new tools/SDK on one of my personal computers rather than my work computer. This way, if I have any problems with the service or application running with 1.7, I can work on resolving the issue, and I can still get my work done.
I compared the manual installation instructions for Tools/SDK 1.6 against the manual installation instructions for Tools/SDK 1.7, and determined that I only had to install the following:
- Windows Azure Authoring Tools
- Windows Azure Emulator
- Windows Azure Libs for .NET
- Windows Azure Tools.VS100
If you’re running VS 2012, you can install Windows Azure Tools VS.110.exe instead of VS100 – we haven’t upgraded to VS2012 yet. (Since that changes the development UI, that’s a whole different upgrade project!) The instructions for 1.7 also talk about IIS Express and SQL Express Local DB, but I have full IIS SQL Server Developer’s Studio installed, so those are unnecessary.
The rest of the instructions and other installs, such as the URL Rewrite module, are the same as those for 1.6. So I only installed the Tools/SDK bits, carefully reading each License Agreement, just like everybody else. (Haha!)
So let’s see how to update the Visual Studio project. I’ve opened the Customer Services WCF service that is created during my Azure for Developers talk. Because I still have Tools 1.6 installed, I don’t get prompted to upgrade my project. But I want to do the upgrade, so how do I force the solution to upgrade? Right-click on the Cloud project and select Properties.
Now the properties of the cloud project are displayed. It recognizes that I have a newer version of the Tools installed and offers me an upgrade.
I click the Upgrade button and get the Visual Studio Conversion Wizard.
I click Next, and get the screen asking if I want to create a backup before the conversion is performed. (For solutions bound to source control, I always say no, because isn’t that the point of source control??)
I click Next and I get the Ready To Convert dialog, where it warns me about source control.
I click Finish, and I get the Conversion Complete dialog.
I check the box to see the conversion log because I’m nosy and I want to know what got changed, then click on Close. The log is displayed:
Among the changes, it looks like it added a Schema Version to the csdef and cscfg files. You can now see this in the csdef file at the end of the Service Definition element in the csdef file, and at the end of the Service Configuration element in the cscfg files:
Now that it’s upgraded, I just need to publish it to one of my staging services and test it out.
How do we schedule upgrading our services at GoldMail?
It would impact the development schedule too much to publish all of the services to staging, test all of them, and move them into production. So this is how we handle these upgrades.
- I put a work item in to TFS to for the upgrade of each service or application. (I want to be sure I can track each one separately, because we’re not going to release them simultaneously.)
- For each service or application: I open the source code in Visual Studio and update the cloud projects. (Note: if you have more than one project, you need to update each of them.) Then I publish the project to staging and (assuming that worked) shelve the changes from the upgrade.
- If the deployments work, I’ll do some cursory checking to make sure there aren’t any immediately obvious showstoppers. Then I will check in all of the changes. (No guts, no glory).
- At this point, the other developers and the build engineer have to install the new tools/SDK. Until they do, they won’t be able to open any of the projects. (It’s best to check and make sure they’re not in the middle of something before checking in the changes!)
- For each service, if we are currently working on it, I assign the work item for upgrading that service to that release. If we have an upcoming release that we haven’t started working on yet, we wait and include the Tools update with that release.
We are constantly working on the different products, so usually this will end up with most services being upgraded in 2-3 months. At that point, we will test whatever’s left and then release it.
If there is a feature we really need to use, we will accelerate the release schedule. But otherwise, this kind of lazy upgrade schedule works really well for us, even though it takes a little longer. Tools/SDK 1.6 came out before we’d finished upgrading everything to 1.5.
Of course, since 1.6 and 1.7 run side-by-side, we could wait and upgrade each product before we are going to make other changes, but I’m always afraid we’ll forget upgrade something, and this way ensures that we get everything updated eventually.
Tags: Windows Azure Tools