Archive for January, 2014

Azure WebJobs and continuous delivery

Thursday, January 23rd, 2014

I’m not quiet about the fact that I’m fairly enamoured with the work Microsoft is doing with Windows Azure at the moment, and this last week, they’ve made something that should be simple, but has always been difficult, simple again.

Deploying Windows services, recurring tasks or “scaling up that little console application” has always been a bit of a chore. It’s why I built SimpleServices, it’s why TopShelf exists. Last week Microsoft quietly introduced “Web Jobs for Windows Azure Websites”, summarised as astutely as ever by @shanselman here.

They’re cool. They’re the “Azure websites” of console apps, and that’s awesome. If you check out Scotts blog there’s a pretty good guide on getting started with WebJobs and using the Azure management portal to upload .zip file packages and interact with the scheduler.

What’s slipped under the radar a little is the fact that they’ve actually built support for continuous delivery of these WebJobs into Project Kudu – this is game-changingly awesome for Windows shops.

What this means, is that you can create a new GitHub project with a solution in the root, that builds a C# .csproj console app, check it in, and hook up automated deployment, ending up with the dream-workflow of “git push deploy” every single change. I actually started experimenting to see if you could leverage Kudus .deployment file configuration to invoke MSBuild to do just this, only to be baffled for about 15 minutes as to why I all of a sudden had a running WebJob in my account after hooking up Git deployment.

Well played Microsoft – you did what I thought I was hacking together before I got there.

The process for doing this is pretty simple… first create a new solution with a .csproj in it (Console app)



.. and push your project to a private or public github account.

Then create a new Azure website host:


Then hook it up to your git (or other) repository:



Select your project


Now wait about 30 seconds and you’ll notice you have a new “Web jobs” tab in your website menu



That’s it, your console app is running continuously. You’ll probably want to stick a while loop in there or use something like SimpleServices that handles this natively. Every time you commit a change, your Web Job will redeploy, and it scales with your available resource.

This is a big deal for Windows software deployments, it’s CD of headless applications, without the ceremony of configuring worker roles.

A+ would deploy again.

Definition of ‘refucktoring’ in English

Saturday, January 4th, 2014


Pronunciation: /r??fakt????/

verb (refucktoring; past and past participle refucktor/r??fakt?/ )
  1. In computer programming – to make something differently shitty by re-working poor software with the result also being unintentionally shitty software. Side effect of poor attempt at refactoring.

    ”the PHP dev team did some hardcore refuctoring between php3 and php4. Look at the poor attempt to implement OO!”

    ”we should fire John, look at this horrific refucktoring he did of our previously simple codebase”

  2. In computer programming – to make some shitty software differently shitty in order to facilitate a further refactor.

    ”yesterday I spent hours refucktoring some terrible ADO.NET code so we can migrate to Simple.Data!”