Deploying: Why artifacts are your friend

Deploying: Why artifacts are your friend

(image taken from Nancy's photostream)

You're almost there. There's a single character in a single file that you need to change and you think the deployment is good to go. "There's no need to do a whole CI build and bother the QA's for this one", you think. "I'll just make the change against this tag, and merge it down later this afternoon." Oops. There you go. Provoking the Operations Manager again. You just made a decision on their behalf, and they probably won't like it.

The Operations Manager's job is about keeping services available, and about managing risk. They tend to mitigate risk by insisting that all code releases have passed whatever QA process your organisation has.

When your users turn on the telly for Neighbours, the operations team will be deploying a release candidate. Allowing deployments direct from your VCS (even if you compile it), is opening the the door to the possibility (no matter now slight) that the release candidate might have a few "enhancements" to it, courtesy of someone who isn't aware of the QA process.

So this is why people have a job that involves taking code from a Version Control System like Subversion, checking out a tag that a developer emailed them, optionally building that code, and then deploying it to a QA or production environment. You might think that's inefficient. But when it comes to keeping a major web property or financial system online, there's different calculations going on: and they are about risk.

Every time software is deployed, there's always the risk that no matter how diligent the development team has been, there's errors. Which can lead to outages, and cause at best reputational issues. So having someone to be the interface between the development team and the operations team and pull the right code across comes pretty cheaply.

Tools like Capistrano that work off of Subversion aren't yet a good fit for some the organisations because of this effect. When those organisations see fit to use Java and C# code anyway, I think there's virtue in taking the code that is built via Continuous Integration and using that as the clean, deployable unit. That's a repeatable process, and it doesn't involve humans typing stuff in, or clicking stuff, which always seems error prone to me. Mind you, that's could just be my typing.

DevOps New Zealand