DevOps, a word for what I was already tinkering with

For a few months now a word has been going around, DevOps, launched after the Velocity conference of June 2009 and its famous “10 deploys a day” talk on dev and ops cooperation at Flickr, then picked up at the first DevOpsDays in Ghent in October, around Patrick Debois. It is presented almost everywhere as the end of the wall between those who write the code and those who run it and reading the first texts I had the odd feeling of recognising things I was already tinkering with in my corner, without ever having given them a name.

What I was tinkering with

Nothing very sophisticated, which may be why the comparison amuses me. My very first tooling was a host list, a CSV of variables and an ssh loop pushing template-rendered configs, with the idea, probably not phrased that way at the time, that the inventory is data and the transport is ssh.

One floor up, it is git and hooks. A repository for the configuration, ssh access by key and a post-receive hook that, on every push, puts the servers back into the state the repository describes. Gitolite on top to manage keys and per-repository rights without weighing things down, with the same bash hooks behind it to trigger deployments. That is how my game and voice servers run, configs I can replay, deployments I can read back and a discipline that fits in a few scripts.

The honest part, the wall

I would be tempted to say I never had that famous wall, but I should be fair about the reason. On my personal projects there is no wall because there is nobody on the other side, I am the dev, the ops and the only user complaining when it breaks, which takes no particular virtue. At work, on the other hand, I deal with developers and that is where the word really makes sense, because the wall there is not technical, it is organisational, two teams, two sets of priorities and the constant temptation to pass the ball when something falls over. That is the ground on which DevOps interests me, far more than the tooling, which everyone will end up building their own way.

No wall, no merit

The word is useful because it names something obvious that still has to be defended, dev and ops are two faces of the same craft and separating them often costs more than bringing them together. My git and bash hooks mechanism remains rustic and I do not claim it is anything more than a contraption that works, but I find the core idea in it, an infrastructure described somewhere and replayed from that description rather than typed by hand. The one thing that worries me a little is that it might end up as a job title, which would recreate one more silo exactly where the word was meant to remove one.

[edit: 2026] The bash and CSV contraption kept evolving for years, I tell that story in Ansible’s ancestor . As for the git repository and its hooks converging servers, we would call that GitOps today, a word that only appears in 2017; the next version, with GitLab CI, Terraform and Ansible, is in GitOps, the word after the practice . And yes, “DevOps engineer” did become a job title.