Do you Kudu?

Having a testing team is vital for a good quality software release, but should we be so confident about the release if they don’t have reliably consistent, replicable environments on which to test?

Our production environment is predominantly Azure - if we have a legacy app it might be in an auto-scaling Virtual Machine; with greenfield apps, we aim to make our projects deployable to Azure websites, which is a PaaS (Platform as a Service).

The process for deploying to our production Azure websites usually includes leveraging Git deploy, which is where we do our work, commit and push. Azure polls our Git repository for changes, magic happens and we end up with an automatically deployed website ready for customer approval.

Our internal testing deployment process isn't nearly as elegant. Usually, this entails building and publishing to the filesystem and initiating a remote desktop session to an internal server. If the codebase has been previously deployed, we figure out where the site is deployed to and replace the files there with the latest version. If it is a new instance of an environment, then we have to create DNS entries to point to our internal testing server and add bindings in our webserver to listen for said hostname. There is also the pain of manually creating the database and ensuring that permissions are correct and all that it entails.

There is clearly disparity between these processes; how can we be confident that our deployments to a given test environment are consistent, if we employ such a manual and potentially error-prone procedure? We challenged ourselves to ensure that our testers have easy and rapid access to work in progress, so that our iterations could unfold quicker and we could then establish our shared understanding much sooner. Perhaps more importantly though, it would give us an opportunity to align our test and production environments more closely.

Under the bonnet of the Azure approach lies Kudu, an open source engine which can manage automated Git and Mercurial deployment. The good news is, this can be self hosted on a windows machine, and can do everything the version baked into Azure can do. This sounds promising.

So after installing Kudu on our trusty internal Windows Server 2012 box (after a little bit of configuration due to the elevated permissions required), we have a working Kudu installation. We can easily create a new instance of our project on the server, and if you look in the IIS management tool, you can see that Kudu has created a workspace for our site to live in and has even created the necessary bindings!

Looking at the Kudu dashboard for the project we just created, we can see a familiar interface - it looks just like the deployment screen in the Azure portal.

Navigating to the Deployments tab presents us with a handy URL which we can treat as a Git remote repository. Add this as a remote to our working copy and push, and we end up with an automatically built and deployed application. A custom deployment script later, and we have automatic database provisioning, permissions configuration, migrations and data seeding. Life is good!

All they have to do it is Git push and the latest code is deployed for them automatically, within seconds.

Our testers are pretty technical and can operate source control proficiently. By allowing them access to the source control repository, we have devolved the power of deployment to them by using Kudu. All they have to do is Git push and the latest code is deployed for them automatically, within seconds. So given a Git repository, our testers have the ability to create their own environments from scratch, each with independent resources which are configurable from the Kudu control panel. They can even use Kudu to redeploy previous versions of the codebase to compare functionality, all without any intervention from a developer.

Kudu works for .NET, Java, PHP, Node.js and Python out of the box - scriptability means it can potentially work for any ecosystem that can be hosted on a Windows server.