Since we’ve deployed our ScrumWall application from a pure hosted solution to a cloud based application, I thought it would be appropriate to discuss how we went around moving and deploying the code to Azure. As Marcus has discussed the architecture of ScrumWall (Part 1) we’ll dive straight into how we got ScrumWall up and running within a few hours.
ScrumWall does have a web application that hosts the Silverlight control which does the necessary authorisation, authentication and hosts the web services for our data flow; and we do need to migrate this. As Azure won’t pick up web applications as web roles out of the box, follow the instructions here (Converting Existing Web Applications for use in Azure) to convert it correctly.
The next big item that came up is configuration settings. Since you’re deploying a zipped up copy of your web application, you’re not going to be able to change web.config settings after you’ve deployed. Azure does support it’s own configuration settings system, this done via the cscfg and csdef files that come along with a Cloud Service project. The csdef file allows you to define your configuration settings while the cscfg file allows you to provide values for the settings.
To get around this issue, we duplicated all the web.config settings into the cscfg and csdef files and then wrote a wrapper class called SettingsManager that determines the context of the application. If we’re running under Azure, use the RoleManager class to provide the configuration settings, falling back to web.config on missing values while simply using the ConfigurationManger for standard web applications. This allows us to use the configuration options in Azure to dynamically modify the settings without facing another deployment.
In Scrumwall all of our logging was done via a logger factory class that determined what concrete logger to use. In standard web application mode, we used TraceListeners. However, Azure does not support TraceListeners at all and will fail with these enabled. Since we already had a factory, it was a simple step to create an Azure logger implementation that used the RoleManager to log our message. With our logger factory determining the logger type via our configuration settings and therefore through SettingsManager we are now able to switch loggers on the fly too!
With all these changes done, we deployed. Our Silverlight application, 3 SOAP web services, a Live ID authentication project and the web application was all bundled up and uploaded. For a solution with these many dependencies, I did expect at least one tier to fail. However, since we have the support from Visual Studio with the Azure tools, the project deployed and ran without a problem. Deploying Silverlight to Azure is as simple as deploying standard web applications and makes for a pretty seamless process.