Squeakyがステージング環境を使わない理由
(squeaky.ai)ステージングの問題
- pre-live は本番環境と同一ではない
- リリースキューが発生する
- リリースが大きくなりすぎる
- 変更に対するオーナーシップが不足する
- プロセスが責任を肩代わりする状態を許してしまう
SqueakyのShip方法
- 本番投入可能なものだけをマージ：変更についてローカル開発環境で十分にテストする
- フラットなブランチ戦略を使う：機能をマージする準備ができたら、rebase してテストする。問題発生時はロールフォワードする
- 高リスクな機能では常にフィーチャーフラグを使う
- 手動デプロイ：変更後も継続的に監視する。監視 / ロギング / アラートを全体的に適用する。ブルー/グリーンデプロイ
結論
- 真の CI/CD のためにステージング環境を手放せば、ソフトウェアを Shipping する別の考え方を作ることができる
- 変更が本番化される前のバッファがないなら、変更が本番環境に適していると確信していなければならない
- 自分が行ったすべての変更に対してオーナーシップを持ち、注意を払う必要がある
- インフラコストと複雑さが減り、開発ライフサイクルを簡素化し加速できる
3件のコメント
組織内でステージング環境を構築したときに感じた安心感を思うと、あまり共感はできないですね。
それでも、デプロイが滞ったり変更内容が増えたりする欠点には共感できます。
ステージング環境が存在するというだけでも、別の環境にデプロイできて、複製可能なソフトウェアの本質？を満たしているか確認できるので、意味はあると思います。
うーん、「オーナーシップ」や「注意」が不完全な人に頼るべきことなのかは分からないですね。少なくとも、指示したとおりに完璧に動作するコンピューターの助けを借りることこそ、コンピュータープログラマーがやるべきことではないでしょうか。
それから、概念を広げると、
ステージング = 最終承認用（私たちが話していた仕様と最終的に同じか、プロダクトデータを入れてみたら思ったより見栄えが悪い、などの確認用）
開発 = 開発者などのメンバーや機能に関する議論用（デモ用）
として使っていますね。
うーん……私は、こういう問題はどんなサービスを開発しているかによって変わると思っています。
どれだけテストしても問題は起こり得ますし、それをユーザーが受け入れられるかを考えないといけません。
Facebook のように、誤動作しても「そんなものか」で済まされるソフトウェアなら、こういうやり方も可能でしょう。
ただ、ミッションクリティカルなインフラや有料サービスなら、問題が起きないよう万全を期すべきだと思います。