Pain

I love GitHub, both as a service, but also as a company. I admire how they think constantly about their development processes and what can be improved upon. This trait is so ingrained they devote an entire group, their Friction Team, to sanding down rough edges and alleviating pain.

We don’t have a Friction Team at Dynamo, but we certainly have friction. I think a lot about friction, and about pain. I’m pain-averse. Pain is tedious, and it’s expensive. I’m not satisfied muddling through a tedious experience—I want to make sure I never slog through that particular muck again.

Staging Servers are Painful

In an application of any interesting size, many features are going to be in development at any given time, and the typical release timeframe is “yesterday.” But before a release can be deployed, it needs to be approved. It’s not (yet) reasonable to ask clients to interact with scary tools like git and command-line, but they need to be able to interact with and evaluate the product.

Our erstwhile solution has been staging servers. We maintain a “staging” branch, ostensibly based off master, into which feature branches are continually merged throughout development, and which is deployed to the staging server. This workflow is painful. Describing this workflow is painful.

Staging servers are painful. Except, they aren’t, or shouldn’t be. Ideally, a staging server is where finished features go for a final integration check before being let loose on the world. They’re meant to mimic your production environment as closely as possible, so any failures you would get in production happen instead without the supervision and involvement of your customers.

But with many features, in many different stages of development, the divergence from production grows wider and wider, and the value of a staging server grows smaller and smaller.

Moreover, there are inevitably conflicts. Different sets of changes to the database, to the stylesheets, to the API. Heaven help you if you haven’t got a test suite. Or how about simply merge conflicts? Resolving conflicts is painful. Conflicts are painful.

Fortunately, the solution is obvious: clones.

Clones (and Forks, I guess)

Both our deployment platforms, Heroku and Cloud66, have features for designating an existing app or stack, and duplicating it.

This alleviates so much pain. Clones allow us to create staging servers that exist only to stage deployments to production, and to be disciplined about it. When it’s trivial to provision a stack, it’s trivial to reprovision a stack, and we can be adamant about ensuring staging never diverges significantly from production.

More critically, clones allow us to have a dedicated stack for each feature in development. This frees developers to deploy more liberally, to engage clients for feedback more frequently, because features don’t conflict with one another during development.

Clones are not all puppies and rainbows and happy disburdened developers. There are some hindrances. For example, there are non-trivial manual steps to provisioning and decommissioning cloned stacks on Cloud66. (Heroku forks are much more mature, but Heroku is falling out of fashion and favour.) The power of clones is still in its infancy, but there’s a lot of potential. And much less pain.