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