Question

Some background….

We’re venturing into Azure for the first time and are trying to do it in baby steps. For now, our first apps are going to be worker roles monitoring queues to process requests (such as sending an email or performing some screen scraping) and we’ll just insert into the queues from our on-premise MVC app and WCF services. We’ll later move the MVC app and WCF services to Azure.

Our development workflow essentially goes like this (somewhat modified in unimportant ways):

1. Develop locally and on some shared servers. Check into source control.
2. Every 15 minutes, build server builds and deploys to a “development” environment (doubles as CI and covers in case we need to hit a “development” environment other than local)
3. Technical testers manually trigger build server to deploy the last-successful “Dev” build to the Test environment (or alternately, the previously-deployed Test build, including/excluding database).
4. Technical testers and business testers manually trigger build server to deploy the last-successful “Test” build (or alternately, the previously-deployed Test build, including/excluding database) to the QA environment.
5. At some point we merge the changeset that QA approves for deployment.
6. Later our production build server deploys this version to staging and then later to our production environments (we host it N times in parallel/independent environments).

As you can tell, we have a number of internally-hosted versions of our app for internal support people to hit against prior to reaching production. I would like for these to have a reasonably low-level of dependence upon Azure. I don’t need to complete sever dependence so we’ll continue to use Azure Queues and perhaps some other mechanisms just because they’re easy to continue using, but we don’t want to have our build server to have to deploy to Azure for every one of these environments (and alternatively pay for all that hosting).

So how can we reasonably host our Worker Roles on-premise in a way where we’re actually testing the code that gets deployed to Azure?

One option that’s been suggested is that we create the worker role as a wrapper/facade and do all the real work inside a class library, which was our plan. However, the follow-up to allow us to “host” this would be to create a second wrapper/facade application that performs the same work as the worker role, just in a way where we can run it as a scheduled task or a windows server. Ultimately, I don’t like this option because an entire project is never tested until it hits staging.

Is it possible to do something similar where we create a second wrapper/facade application that instead of calling the class library that it actually references and calls the Run() function in the worker role?

Answer 1

Do you reckon Azure emulator might help you? These are the differences between the real Azure provider and the emulator.

Having a facade for your worker role seems reasonable. And use adaptors to adapt any possible cloud (or other hosting) techonology to that facade? Just trying to throw in some ideas. I actually used this approach before, but was a “personal” project.

Use PowerShell to configure your roles and whatnot.
Configure your Azure emulator like this.