Webサイトまたはソフトウェアをデプロイしているほとんどの企業は、最近の変更がユーザに表示される前にテストできるようにするため、事前のプロダクション環境を使用している。これは、問題やバグを見つけるための防御線を追加するという点で多くの利点をもたらすが、コストと複雑さを増大させ、逆効果をもたらすこともある。ソフトウェアが常にデプロイ可能であることを確認するためにチームを奨励する継続的デリバリー (Continuous Delivery) などの手法により、複雑なブランチ構造やテスト環境から離れ、よりシンプルなセットアップに勢いがある。Squeakyは、プライバシーを侵害することなく訪問者がWebサイトやWebアプリを使用できるかを企業が理解できるよう支援する会社だ。同社は、異なるアプローチを採用し、ステージング環境を使用しない理由を概説している。彼らは、これによってより速く出荷でき、プロダクトで見つかる問題の数を減らすのに役立つと考えている。
彼らのアプローチを説明するブログ投稿で、SqueakyのLewis Monteith氏は、ステージング環境にあるいくつかの問題について詳しく説明している:
事前環境がプロダクションと同等になることは決してありません: スケーラブルなクラウドネイティブアプリは、多くの場合、負荷を処理するためにプロダクションでより多くのリソースを必要としますが、事前にまったく同じセットアップを構築するコストは法外です。これにより、事前環境の構成のドリフトとスケールダウンアーキテクチャが発生し、これらの事前環境でのテストで問題を見つけることができなくなる可能性があります。
常に大きくなったリリースの待ちがあり、オーナーシップが減少します: 複数の開発者またはチームが同時にコードをリリースしたい場合、事前環境がボトルネックになります。事前環境を待たなければならないことは、特にテストが失敗し、全員がそれらの修正を待たなければならない場合、テストの遅延と妥協を引き起こします。リリースの待ちがあるとブランチが分けられ、後で多数の変更をマージしなければならなくなり、開発者に苦痛を与えます。
そして、待ちを減らすために、リリースに、バグが発生する可能性を高めることを意味するこれらがバンドルされることになる。誰のどの変更で問題が発生したかを正確に追跡することが困難になる。問題は分離されていて、開発者はプロダクションに行った変更を認識できない。
責務を置き換えるプロセス: 事前環境は、運用にフォーカスしたチームによって実行される傾向があるため、事前環境へのデプロイには、開発者から運用チームに責任の暗黙の引き継ぎが伴う可能性があります。
Squeakyの代替アプローチは、これらの問題を解決または回避することを目的としている。これを機能させるための4つの重要な信条がある。
稼働する準備ができたコードのみのマージ: このアプローチは、適切なテストがあり、変更が開発で検証されていることを確認することでバックアップされます。
フラットブランチ戦略: すべてのブランチはメインブランチからフォークされ、変更はメインブランチにのみマージされます。スモークテストは、開発者のコンピュータでローカルに行われます。
高リスクな変更のためのフィーチャーフラグ: Squeakyは、全体的に負荷がかかった状態のパフォーマンスや変更にユーザがどのような反応をするかについて懸念がある場合、フィーチャーフラグの背後で大幅な変更を加えることがあります。これらはユーザごとに実行できます。
デプロイメントのハンズオン: 監視、ロギングやアラームは、問題がないことを確認するために包括的に使用されます。また、Squeakyでは、ブルー/グリーンデプロイメントを使用して、すべてが問題ないことを確認するまで、ユーザのサブセットに変更をデプロイします。
Squeakyがステージング環境を廃止し、多くの継続的デリバリーの原則を支持することで、ソフトウェアの出荷に対するマインドセットが変わった。変更を公開する前にあるバッファの削除は、変更のプロダクションへの適合の信頼レベルを上げる必要がある。これにより、コストと複雑さが軽減され、開発ライフサイクルのスピードアップに役立った。