3つのコンポーネントがあるクライアント/サーバープロジェクトがあります。
クライアントとサーバーの両方がBaseLibraryを参照します。したがって、2つのストリームを作成しました。
ここで、一方のストリームでBaseLibraryに変更を加えた場合、それらはもう一方のストリームには存在しません。RTC 2を使用して、コンポーネントをさまざまなストリームで同期させる方法はありますか？
また、お互いのストリームのフローターゲットを設定しようとしましたが、それは役に立たないようです。
ストリーム間のフローターゲットは、配信/受け入れフローが発生する場所を視覚化するのに役立ちます。これは、「フロー図」を作成するときに使用できる視覚化ツールです。
3.0.1では、あるストリームから別のストリームへの保留中の変更を実際に表示できます。
これで、ビルド定義を設定し、ビルド後の配信を使用して、あるストリームから別のストリームに自動的に配信できます。
このシナリオでは、「TeamA」は引き続き同じトリガーポリシーを使用します（配信するものがすべて検証されていることを確認するため）が、現在は単一のコンポーネントのみを「統合ストリーム」に配信しています。この状況では、「グリーン」ストリームはなく、リリースエンジニアは、統合ストリームが自動化されているため、統合ストリームに変更を加える必要がなくなりました。
Add components to deliver if they do not exist in the deliver targetまた、上の図から、2つのチェックボックス「 」と「 」がチェックされていないことに注意してくださいRemove components from the deliver target if they do not exist in the build workspace。
自動化されたメカニズムを介して、コンポーネントの追加/削除を統合ストリームに伝播しないことをお勧めします。チームが最後に望んでいるのは、誰かが誤ってチームのストリームを変更したために、他のすべてのコンポーネントを統合ストリームから削除することです。
このような場合、コンポーネントの追加または削除は、リリースエンジニアが手動で行う必要があります。
たとえば、チームが新しいコンポーネントを必要とする場合、最初にそれをストリームに追加してから、統合ストリームに配信する必要があります。次に、「」の「 」Components to deliver選択を変更します。Post-build Deliver