Skip to content

Why use automated deployment?

I was talking with a developer about their first rails project, the deadline of which was looming. After a quick walk-through of the code I started asking about process stuff — what are you using for tests? Are you using capistrano for deployment?

The answers were “I’d like to use tests at some point in the future” — danger! — and that no, he was deploying things manually up to a vps instance.

I said that whatever server admin task like deployment that I can automate and do from my own machine, I will. He asked, “why, are you not a server guy?”

So, I thought I’d jot down a snapshot of why I use capistrano (or chef recipes, with engine yard-ish clouds) for deployment, in case someone else is wondering.

Three main reasons: flow, safety, and process.


This one’s pretty simple. During the course of a development day, my screen-estate is taken up by an editor window, a browser, and the console. My console (iTerm) usually has several tabs open, typically three per project: a server, a prompt at the app’s root for doing git operations and kicking off tests, and one tab that’s tailing the cucumber or rspec logs.

If I want to deploy, I just drop into the console that’s already open, and run a simple command (“cap deploy”) and I’m done. It’s just part of the flow, and flow is everything.

If I have to deploy something manually, that involves: * opening a new tab * logging into the server * moving to to the app root * running commands like git pull, etc * possibly restarting mongrels * logging out and closing the tab

None of which is in the flow of developing. In other words, I have to switch modes from developer to sysadmin, and switching modes kills the flow.


This one’s simple also. Capistrano has a lovely command: “cap deploy:rollback”. If I deploy something that’s not ready for primetime, and satellites begin falling from their orbits or nuclear attack turtles start becoming sentient before they’re meant to, I can just kick off a rollback and I’m back to safety and fluffy bunnies. That’s because capistrano keeps several releases stored on the server, and switching to a previous codebase is as easy (mostly) as switching some symlinks.

In the manual world, it’s messier. I don’t like messy. Not with prematurely-sentient nuclear turtles out there.


Anything I have to do manually is something I’m likely to either screw up or forget. That’s because I’m a forgetful screw-up, but it’s important to build self-protection into your process flow.

Aside from updating the codebase, deployments can typically involve migrating the db, updating symlinks, restarting search servers, notifying services such as hoptoad and newrelic, etc. Anything that has to be done each time you deploy can be built into a capistrano script, so you don’t have to think about it. What you don’t have to think about, you won’t forget to think about, and you won’t screw-up.

If the updated codebase depends on a migrated db, and you forget to run the migrations after deploying manually, well here come the sentient nuclear turtles. And they’re mad.

So, keep the world safe: automate your deployment.

Post a Comment

Your email is never published nor shared. Required fields are marked *