Feature environments

We at Kickstarter are big fans of feature branches for our code. But when it was time to deploy our features, we had a bottleneck. Our two test environments (QA and Staging) were constantly in use. Engineers had to wait for their turn to deploy a feature. We added a third test environment, configuring much of it by hand. But it was a marginal improvement. We needed a different way to work.

The answer was feature environments.

Now when an engineer wants to show off a feature, he launches a whole new environment with it's own database, web, and app servers. The environment is bootstrapped with a recent, scrubbed copy of the production database. All the configuration happens automatically, even new DNS records.

A few minutes later, the environment is ready to use. And when we're done, we shut it all down.

How it works

We made a small Rails app codenamed HiveQueen (a reference to Ender's Game). HiveQueen coordinates launching, configuring, and deploying to different environments. Behind the scenes, it uses:

HiveQueen is really standing on the shoulder of giants. It's a simple app using popular, stable tools to create an easy workflow for launching & configuring servers.

Working in Slow Time

An unexpected benefit of feature environments was the ability to work in Slow Time. Getting a feature ready for production involves several people: engineers, designers, and our community team. No longer are people rushed to review a feature while it's tying up the QA environment. We can leave up the feature environment for hours or sometimes weeks, iterating at our own pace.

← Previously: The value of classic literature | All posts | This is the newest post