理想的な解決策は、依存関係のバージョンがわからない環境に配置することは絶対に避けてください。そういうわけで、狂気は嘘です。
これを回避することはガバナンス上の問題であり、ソフトウェアを構築するためのサービス指向のアプローチの中心となるはずです。
たとえば、サービスAのバージョン2.0を開発しているとします。ターゲット環境では、サービスBバージョン1.0とサービスCバージョン1.0があります。
ストレスフリーのリリースの最初のステップは、開発ビルドの一環として、最も近い近隣自動化テストセットを実行することです。このテストでは、B v1.0とC v1.0をサービス契約（詳細は後述）。これは、mountebankなどのテスト二重ツールを使用して容易にすることができます。
あなたのv2.0リリースブランチを作成したのと同じように、別のチームがサービスCのv1.1をリリースしようとしていることが分かります。v1.0からv1.1サービスCのv1.0契約への変更を構成します（詳細は後で説明します）。
v1.1が大きな変更であり、問題がなければ、サービスC契約のv1.1でテストを更新し、失敗を修正します。新しいv2.0.1パッチブランチを作成してリリースするとよいでしょう。何らかの理由でサービスCの前に強制的にリリースする必要がある場合でも、v2.0ブランチからリリースできます。
v1.1が大きな変更でない場合は、問題はありません。既存のブランチをリリースしてください。
上記のような集中リリース管理プロトコルによって生成されるオーバーヘッドに対処するためのさまざまな戦略があります。
前述のように、サービスをテストするときは、すべての依存サービスの契約を使用する必要があります。 （注：サービスの単体テストで定義されているDTOなどの既存のコードモデルを使用するのではなく、最も近いネイバーテストを契約から起動することが非常に重要です。すべてのサービスの契約は、完全なサービス記述を提供する標準（例えば、swagger）に基づいており、見つけるのは非常に簡単です。service repositoryを使用すると、これを簡素化できます。
また、前述のように、新しいバージョンの依存サービスによってサービスが中断される可能性があるかどうかは、常に知ることができます。 1つの戦略は、バージョンをインクリメントするとき何らかの意味を与えるバージョン管理規則に同意することです。たとえば、major.minor.patch（たとえばv1.0.0）を使用すると、メジャーバージョン番号が変更されてサービス契約が変更され、その結果、サービスが中断する可能性があります。前の例では、サービスCがv1.0からv1.1に移行しました。上記のような規約では、メジャーバージョン番号が変更されていないので、変更が私たちを壊すことはないと確信することができました。
集中管理されたリリース管理プロトコルを設定して維持するのは面倒かもしれませんが、サービスを展開することで何も壊れないという完全な確信が得られます。さらに、これは、元の質問で提案しているような複雑な（そして気になる）インライン・ランタイム依存性の解決を回避します。
はい。テスト。この質問はあまりにも広すぎる – Jamiec