In the Beginning

Red Gate in the past has always produced lovely tools, however sometimes things are created which are never quite good enough to become products. So instead of keeping these things to ourselves we started putting them online for others to make the most out of – http://labs.red-gate.com. Being Red Gate the initial site was put up in a hurry using media wiki and languished there for many moons, unloved and unimpressive

Project

Thus was born a plan, and it was a cunning plan. In the past Red Gate has taken in interns to work on products, this time we would get a group of interns and give them the goal of developing a new website in just one week. The 7 interns would be joined by two developers, one project manager and as much design, ux and tech comms resource as we could scrounge.

The first day was spent sketching the UI and specifying what was going to demoed on the Friday in front of all the steak (mmmm steak) holders. This was interesting as things always start off very ambitious and then reality kicks in that it’s almost lunchtime on day 1 and you have to have everything finished for final testing in 3.5 days.

The team was split nominally into two, although in effect there were three major efforts going on, the underlying system, the admin interface and the public website itself. ASP.NET MVC was used as the technology mainly because it’s cool, new and very quick to get going with a fairly shallow learning curve.

The interns really stepped up and created something amazing in such a short space of time really getting a feeling for what’s it like to develop in a real company with a real deadline. Shame we couldn’t get testing resource to run alongside the interns as I think that was one experience that was sadly missing.

Presentation

Amazingly the team pulled together and although there were a few disagreements (and one nerf casualty – don’t ask) I was amazed that on Friday we could stand up in front of the heads of all the divisions of Red Gate and the CEOs and show something that looked great and pretty much did what we said it was going to do. An awesome effort by everybody involved.

After

The interns left *sob* back to life in academia, I hope they’ll be back though. Now the cold light of day dawns and we have to get this thing ready so I organised a bug hunt getting all those evil testers the interns missed, about 12 pages full of niggles were found with only a few serious bugs so it held up pretty well all things considered. A couple of choice bugs were the use of arabic in tool names, or perhaps the ability to send malicious ratings for tools – 16000 out of 5! Red Gate people can be truly evil sometimes.

So after tweaking the system and making modifications to the admin site it’s all looking ready to deploy. There it languishes for a while as many people have other things to do that take priority until.

Azure

Up pops an idea, we fancy playing with Windows Azure so let’s deploy the new labs site on the Azure platform. How hard can it be? Actually it turns out harder than I thought but still surprisingly easy once the initial modifications are made, I didn’t really take notes so this is from memory.

• First deploy a Hello World app to your Azure to get familiar with the tools
• Add a Windows Azure Cloud Service project to the solution
• Add Web Role in Solution to put your web sites in the Azure Cloud Thingy
• Add a WebRole.cs (have a look at your hello world version and copy it)
• Add references to your project
  • Microsoft.WindowsAzure.Diagnostics (Copy Local = True)
  • Microsoft.WindowsAzure.ServiceRuntime (Copy Local = False, don’t know why it just is)
  • Microsoft.WindowsAzure.StorageClient (Copy Local = True)
• Modify your web config adding the system.diagnostics/trace/listeners/AzureDiagnostics section – have a look in your hello world app
• Try it out on your local fabric
• Create your SQL Azure database
• Use the alpha versions of SQL Compare/SQL Data Compare for Azure or the Azure migration wizard to get your local db over to the cloud
• Modify your connection string to point at the cloud – does is still run with a remote db on the local development fabric? You probably didn’t change the firewall rules did you?
• Make sure you attempt no local file access if you need to store files use Azure Blob Storage, it’s not that complicated although you will have to recode stuff
• Try deploying – I find using the deploy in Visual Studio was the best as it logged the history of status changes allowing you see how long it takes – I was finding deployment took between 10 and 20 minutes
• Then realise that you still have to modify the SQL Azure firewall to allow your Azure hosted service to talk to your database (“Allow Microsoft Services access to this server”)
• If you’re using MVC curse and swear and eventually discover the reason you’ve got stuck in the dreaded Initializing/Busy/Stopped looped is that Copy Local should be True for System.Web.Mvc
• Then when you deploy for real discover that you really really need MultipleActiveResultSets=True on your connection string or all hell breaks lose and starts rampaging up the high street
• Also as an aside I put Elmah error reporting on the site and it pretty much just worked, did have to modify the sql a little to add a clustered index on the main table as SQL Azure doesn’t like bucket tables currently

That’s it after a few days of fiddling we’re live on http://labs.red-gate.com all in all pretty good and the staging/deployment switch that Azure can do as a party piece is pretty neat for bug fixing too.