37signalsのBasecampでは、Railsで用意されているデフォルトの3つの環境のほかに、Beta、Staging、Rolloutの3つを定義して使っている。

• Beyond the default Rails environments by David of 37signals

Rollout環境は、新機能をまずユーザーの10%にだけ公開するために使われるもので、Flickrやetsyなど多くのサイトではFeature flippersとよばれる機構で実現している（機能毎のフラグを参照することで、新機能をユーザーに提供するかどうか切り替えるようなもの）。コメント欄でも、何故、Feature flippersではなく環境で機能のロールアウトを行うのかが尋ねられていて、DHHは以下のように回答していました。

I always want to leave the campsite in a better condition than I found it. To do that, I often refactor lots of code in the development of a new feature. When you’re not just adding to the pile, but rearranging it, it’s not the best idea to do that on production most of the time.

Additionally, while it’s great to use features in production for a bit before committing to their release, I also believe in clearing the decks and having as little discrepancy between the production version of Basecamp and the development version. That means an app not littered with dozens of features only visible to company workers. Work grows stale if it’s not shipped and it doesn’t provide any value to our customers before it is.

So that’s the general philosophy. But there’s also a matter of scale. We have less than 10 developers at 37signals. So we can’t work on dozens of features at once. If you have a hundred developers, all working on lots of features at the same time, maybe you have to accept the drawbacks of feature flippers. But that’s (thankfully, to me) not our scale.

つまり、Feature flippers方式を使うとProduction環境が機能フラグでゴチャゴチャしてくるのが嫌、ということなのかな。

まあ、それはそれとして、最後の段落の「37signalsには10人以下の開発者しかいないので、一度にいくつもの機能には取り掛かれない。この規模なら（ありがたいことに）Feature flippersの欠点を受け入れずに済むんだ」というのが実に37signalsらしくていいです。

ついでに、サラッとdhh/custom_configurationというgemが紹介されてた。