Menu

Subscribe

Kudos to Kudu: Windows Azure Websites Secret Sauce

on azure, github, continuous integration

cover

There are secrets in them Azures!
Learn how to deploy to an Azure Website from a directory nested with your GitHub repository automagically!

Continuous "Zagawa Wagawa"

Ok, so we all know the Contentiousness in software development rules;

  • Continuous Improvement
  • Continuous Delivery
  • Continuous Testing
  • Continuous Deployments
  • Continuous Integration

I think you get the point.

These days there are a myriad of options out there to choose from, Team Foundation Server, Visual Studio Online, TeamCity, Jenkins, Bamboo and the list goes on and on.

What is great about all of these tools is on key aspect, Automation.

I still have daymares of configuring CruiseControl.net with NANT... Ouch!

However that being said, sometimes these tools get in the way of doing what we want and we reflect back on that cool piece of NANT you wrote years ago. This can seemingly feel true in the context of Windows Azure and their Automated Website Deployments, ala GitHub for example. A core component of any valuable CI system is flexibility so you can address moments of off Golden Path gem requirements. As painful as it may sound, these systems don't solve every problem <shudders>Me</shudders>.

What if you want to deploy from GitHub, but your code is in a couple of child directories down the structure?
Or more interestingly, you have multiple solutions in a repository?

What to do?

Bienvenidos Kudu!

Lookie what we have here...

Kudu is the engine behind git/hg deployments, WebJobs, and various other features in Azure Web Sites. It can also run outside of Azure.

Interestingly enough, this is nothing new whatsoever! The source code dates back to February 2012 and hosting more than 30 releases and built by the likes of David Fowler and David Ebbo. Call it what you want, but this is a hidden gem of goodness!

Scenario

Moving our application architecture to a more back-end agnostic UI leveraging the maturity of JavaScript frameworks has been a focus of Bob and I for a while now. In doing this we are able to completely abstract the UI from any specific technology. The win here was out UI code lived within the same solution however, in a completely different directory structure. Deployments can be a little tricky.

So to alleviate this repository structure, we were able to leverage the deployment features of Kudu.

Execute

Let's walk through the steps to deploy to an Azure Website from GitHub when your code lives within a nested directory in your repository.

There is a good article here outlining the basic default setup of automatically deploying to Azure from source control. This gets us 75% of the way there, we have some additional work to do next.

First things first, the .deployment file.

Under the covers of Azure Kudu is a midst here!
When the deployment is fired off by changes in your SCM, Kudu goes to work.
One of the first things it does is look for this .deployment file in the root of the repository.
If it finds it, it will fire off any command within that file and let your custom commands handle the deployment.

  1. Create a file within the root of your repository named; .deployment

Within that file we want to fire off a command file like so;

[config]
command=deploy.cmd

This instructs Kudu to allow the contents/ commands within the deploy.cmd file to run the deployment.

In our case, we are talking about static code files within our repository; HTML, JavaScript
, and CSS files.

  1. Create a command file named; deploy.cmd

This file is where you can do practically anything. Run JS unit tests, etc. but for now we are going to keep it simple and just perform a simple xcopy to our wwwroot directory.

@echo off
echo ---Deploy static files...
xcopy %DEPLOYMENT_SOURCE%\src\site\* %DEPLOYMENT_TARGET% /Y /s

In a nutshell, all that is going on here is a simple xcopy of the deployment source, explicitly from our static site content in the \src\site directory of our repository to our wwwroot directory of our Azure site. Keep in mind, this is all run on the Azure side, on your Azure Website.

You'll notice a few a couple of environment variables. These can make life a lot easier as there are a few which may come in handy for your scripting needs;

  • DEPLOYMENT_SOURCE: directory of your source files, this is normally the root of your scm repository
  • DEPLOYMENT_TARGET: points to the wwwroot directory of your folder structure on your Azure website
  • DEPLOYMENT_TEMP: your deployment script may generate artifacts during the processing of your deployment script for the current build. This variables value is the path to a temporary directory for such artifacts. Keep in mind this directory is deleted after the deployment cmd is run.
  • MSBUILD_PATH: Path to msbuild executable.

Simple, straight forward, and not ironically the tip of the iceberg in regards to where you can go from here!

Kudu expands much further on this contrived example with many other features;

  1. Web Hooks
  2. Azure Site Extension
  3. Post Deployment Action Hooks
  4. WebJobs
  5. and much more.

The Kudu Project Wiki has some great content and how to take control of your Azure Website deployments back, so get creative and leverage some of the kick ass features of Windows Azure.