Designing a continuous deployment system: on being language agnostic

Source

Hi, and welcome again to my series of rants about continuous deployment :) In the next few posts, I'll try to scope out what I think a hypothetical greenfielded continuous deployment system should and shouldn't do, and then get that down to what a feasible continuous deployment system should and shouldn't do. Hopefully there won't be too much cutting.

Fair word of warning, there's some ground rules to cover first before I get to talk about anything really interesting. This article, specifically, is about being language agnostic. It's not exactly a very controversial thing, and is mostly here so I have something to point to when someone asks me why I did X rather than Y. If you're willing to concede that the added complexity of supporting arbitrary languages and build/deployment systems is worth it, feel free to skip this one.

Python's great and all, but lock-in is pretty much always bad. There's two big reasons why I think this is worth doing, despite potential added complexity:
  1. You want other people to use your system.
  2. You want to be able to use different things, now or in the future.
The first point is pretty straightforward. For something as critical as a continuous deployment system, you'll want a lot of other people using it and contributing to it. In CI systems, this sort of traction is what made Buildbot great and Hudson popular. Selling people something that works with whatever it is they have is a lot easier than selling people something that works with whatever it is you have.

The second point is just because nothing can be the best way to express every possible problem all the time. You might want to use different tools, if only purely for the sake of experiment.

If your architecture makes it possible, why not allow a programmer to foray into the slightly unknown? Who knows, you might develop something nice. Programmers are typically creative people: giving them a lot of a freedom to tinker tends to repay itself many times over (Google figured this out with 20% time).

The bottom line is simple: don't make it work for Python only. Or, which is more like what I'm going to do: make it Python only for now, but don't make it hard for other people to do whatever they like with it.

The next article is going to be about what to deploy and the format to deploy it in.