Over the past few months we’ve added more servers, more environments, and more employees. I have become increasingly nervous whenever a deployment is going out that something might go wrong. What if we deploy the wrong branch to the wrong environment, or what if we prematurely deploy to production?

I made a few changes to our deployment scripts to ease my worries. The changes are small and simple, but make me feel content that fewer things will go wrong as we grow. The two changes are:

Confirm any deployment to production. Configure allowed branches per environment.

First, deploying to production shouldn’t be taken lightly, but a simple confirmation is (hopefully) enough to prevent careless mistakes. This is a task that can be called from any of our environments, production.rb for example. Now each environment is responsible for deciding if it’s confirm-worthy.

Capistrano deployment confirmation.

Second, we follow the Gitflow Workflow; as such, we maintain the invariant that “master” is always deployable, and it is the only branch that should ever be deployed to production. Similarly we want to restrict staging to branches that either match “master” or “release.*”. This should be simple enough with another Capistrano deployment task. We simply have to define allowed branches on our production and staging environment as necessary. An array of regular expressions does just fine, e.g. [‘master’, ‘release.*’] for staging.

Capistrano branch verification.

While simple, these changes prevent a lot of things from going wrong. No one will accidentally deploy to production when they’re scrolling through their command history. We will only ever deploy “master” to production, and “master” or “release.*” to staging. I feel more comfortable now that things are a bit more explicit and these simple rules will be enforced.