More on why we made Buildix

Chris already blogged about Buildix. I thought I'd share some more of the background, and my take on why it is such a good thing.

Shorter Iteration Zero: When you start an Agile project you need to have some tools in place: SCM, CI etc. While you may not even have code if you're on a greenfield project, you still need to have some basic build system in place to compile, test and possibly deploy your code. This all takes time to do, and it generally involves some trial and error to get all the tools plumbed in together. So: Buildix helps you deliver code faster. You could be able to check in code in minutes. We demonstrated this at the TW London away day by interactively breaking and fixing the demo build during the presentation.

Easier upgrades: One pattern that comes up time and time again is checking all of the tools used into the source control system used on the project. So if you need to set up a new CI Server, you check out the tools from SCM. Fine. But upgrading them always seemed clumsy; especially when it's easy to fork a tool and check it back into SCM. So having a Debian based Linux distribution as the basis for Buildix was key - we can distribute tools as a Debian package, and leverage the APT system in Debian to take care of the mechanics of distributing upgrades and calculating dependencies.

Doing the right thing: We wanted some way of promoting good build and deploy practise in TW without trying to enforce anything or standardise on tools. Buildix is the container for those ideas, although we have a long way to go before we have a good sample of the lessons learned and techniques from all the projects worked on. I hope that we'll address some of this in the next Buildix release. I hope we can also improve on things like deployment to enterprise application servers. Stay tuned.