依存関係の促進戦略：サイロ化またはオーケストレーション？

私たちは、相互に依存し合う多くのアプリとWebサービス（一部のパブリック向け製品、一部の内部およびプライベート「バックエンド」の一部）を持っています。これらの各コンポーネントには、4つの環境（特定の目的に役立つサーバー/ノードのクラスター）があります。

• 非生産
  • DEV-CIがプッシュ変更を構築する統合開発環境。エンジニアがローカルで再現できないバグを見つけるのに役立ちます
  • QA -分離されたQA /テスト環境
  • DEMO -ビジネス関係者のための安定したUAT環境
• 製造
  • LIVE -私たちのライブ/制作環境

コードの昇格は次のようになります：（LOCAL開発者のマシン）=> DEV=> QA=> DEMO=> LIVE。

と呼ばれるmyappRESTful Webサービスによってサポートされるアプリケーションがありmyws、それ自体がと呼ばれるDBによってサポートされているとしmydbます。

現在、これらの依存関係の中で私が「オーケストレーション」プロモーションと呼ぶものmyapp-devがmyws-devありますmydb-dev。が使用するポイント。同様に、myapp-qaがmyws-qaを使用することを指すmydb-qa。同じのためにDEMOとLIVE。

これの問題は、たとえばにmyapp変更を加えるたびにmyws、mydbにも変更を加える必要があることです。しかし、各DEV環境は依存関係の環境を指しているため、DEVこれらの変更をすべて同時にスケジュールしてロールアウトする必要があります。さらに、1つのビルドが不安定になったり壊れたりすると、他の上流コンポーネントがダウンすることがよくあります。たとえば、開発者がを変更するときに何かを壊した場合、通常mydb-dev、myws-devおよびmyapp-devクラスターも不安定になります。

これを解決するために、私は「サイロ化された」プロモーション戦略と呼ぶものの提案をまとめます。すべてのコンポーネント間の依存関係はこのガイドラインに従います。

• 上流の依存DEMO関係は、すべての非実稼働環境（DEV、QAおよびDEMO）の下流の依存関係の環境に依存します。そして
• 上流の依存LIVE関係は、本番環境の下流の依存関係の環境に依存します

この規則を使用myapp-devするとmyws-demo、実際にはをポイントし、を使用しますmydb-demo。同様に、およびmyapp-qaも指します。myws-demomydb-demo

私は見つけることができることをここに利点があるビルドの安定化：それははるかに少ない可能性が高いということであるDEMOコードはにそれを作ることができないので、特定のコンポーネントのための環境が不安定になるDEMOの両方の厳格なテストなしDEVとQA。

この方法で見つけられる唯一の欠点DEMOは、特定のコンポーネントで問題が発生した場合、すべての上流の依存関係のすべての非本番環境が突然破壊されることです。しかし、DEVとで実行されたテストのために、これが非常にまれに発生するはずであることに反対しQAます。

これはしていまし解決して、この問題とその解決策が既に（私が画策/サイロ化呼び出しています何のほかに）それらに名前を持っている場合、私は驚かないだろう多くの開発者（ずっと賢く自分よりも経験）という問題です。だから私は尋ねます：サイロ化されたプロモーション戦略のメリットはどんな短所よりも重要ですか、そして私がここで見落としているかもしれない短所は何ですか？

私があなたの投稿を正しく読んでいる場合、この提案は実際に主張されている問題のどちらかを解決するようには思えません。

たとえばmyappに変更を加えると、mywsとmydbにも変更を加える必要があります。しかし、各DEV環境はその依存関係のDEV環境を指しているため、これらの変更をすべて同時にスケジュールしてロールアウトする必要があります

「サイロ型プロモーション戦略」は、これをさらに悪化させるだけのようです。myapp v2、myws v2、mydb v2がDEVのみにあり、myapp v2がmydb v2に依存してクラッシュしない場合、myapp v2をDEVで実行しようとすると、mydb v1 DEMOがヒットし、クラッシュします。本質的に、サイロを常にオーバーライドするか、myapp v2で作業を開始する前にmydb v2を本番環境に展開する必要があります。さらに重要なことは、DEVでmydb v2をテストすることは決してないため、壊れている場合は、DEMOで壊れるまではわかりません。その後、元の状態に戻ります。

あなたが説明する問題は、ワークフローの設定方法に関係なくある程度避けられませんが、最小限に抑えることができます。その秘訣は、mydbとmywsの間のインターフェース（およびmywsとmyappの間のインターフェース）が厳密に定義されていることを確認し、そのインターフェースに対するすべての更新が完全な下位互換性を持つようにすることです。私の仕事では、アプリとサービスの間のインターフェースを定義するXMLスキーマがあり、内部ツールの多くでは、これらのスキーマに対して互換性のない更新を行うことができません。

さらに、1つのビルドが不安定になったり壊れたりすると、他の上流コンポーネントがダウンすることがよくあります。たとえば、開発者がmydb-devを変更するときに何かを壊した場合、myws-devおよびmyapp-devクラスターも通常不安定になります。

これは深刻な問題のように聞こえますが、展開の問題ではありません。データベースが壊れると、サービスとアプリが正しく機能しなくなりますが、「不安定」になることはありません。開発者がmyappを実行しているすべてのユーザーが、単にクラッシュするのではなく、「申し訳ありませんが、現在データベースに問題が発生しています」と表示されるように、何らかのエラーメッセージを返す必要があります。

壊れたデータベースがこれらの問題を引き起こすことが問題である場合は、「一時的なサイロ化」システムをセットアップして、「mydb DEVが今壊れていると言うことができます。すべてのmyws DEVクエリをmydb DEMOにルーティングして、当分の間"。ただし、これはmydb DEVが再び正常に機能するまで一時的な修正を実行する方法にすぎません。すべてがデフォルトでそのように「サイロ化」されている場合、mydb DEVに対してまったく実行されないため、上記の問題に戻ります。

私はおそらくあなたの提案をどういうわけか誤解しているように感じますが、うまくいけば、この回答により、少なくとも誤解されていたことが何であり、それを言い換えるのが最善であることが明確になります。