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:
- AWS EC2, RDS, Route53 for servers, MySQL databases, and DNS records.
- Fog, a wonderful ruby library for working with AWS.
- Opscode Chef & the Chef REST API for configuring servers.
- Capistrano for deploying application code.
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.