I’m continuing our work with our Continuous Delivery effort. Were migrating from our previous build system to Hudson since it makes builds much more accessible.

The work started with the continuous delivery with hudson project I have on github and were slowly adapting a fork of that to work with out scenarios.

We realized that the amount of builds that we will be hosting in Hudson might make it hard to get an overview of what depends on what. After some research I found out that you could add the following to the URL of your hudson to get a dependency graph of all the builds:


So if you host Hudson locally it would look like:


This is how our current dependency graphs looks like:


The package output build takes the result from our old package build and migrates it over to the delivery pipeline. The Template Schedule Deploy job (which I now realize is a bad name) takes a set of “job files” and run the deploy installation job with the given settings.

The Create job files based on search creates the job files that the template deploy job works with, and the upgrade early, test, and bulk installations does a search in our installation of RemoteX Applications to find out which installations to upgrade based on the units in RemoteX Applications.

Each job then run the deploy installation build (not visible in the graph) to deploy the upgrade for each customer. In essence running the same build for upgrading that we use every time we deploy anything.