ユーザーヘルプ > 変更パッケージ内の作業単位のグループ化 > 変更パッケージの再同期の概要 > 変更パッケージの再同期での伝播変更パッケージの使用
  
変更パッケージの再同期での伝播変更パッケージの使用
別の変更パッケージを使用して、CP の再同期操作で行われたすべてのメンバーの変更を記録できます。このような目的で使用される変更パッケージを、伝播変更パッケージと呼びます。
* 
管理者が変更パッケージを必須として設定している場合でも、CP の再同期操作の伝播変更パッケージを指定する必要はありません。
CP の再同期操作中に、標準変更パッケージを作成し、伝播情報をその変更パッケージに記録することを指定した場合は、伝播変更パッケージを作成しません。変更を分離する際に制御を最大レベルにするためには、空の伝播変更パッケージから開始することをお勧めします。伝播変更パッケージに前のエントリが含まれない場合は、問題の変更に具体的に関連するエントリだけが追加されます。
伝播変更パッケージには、実行されたすべてのメンバーとサブプロジェクトの変更、および再同期の結果として伝播された変更パッケージが設定されます。不要なメンバーの変更を破棄したり、解決したマージの競合を伝播変更パッケージに追加することができます。また、Windchill RV&S コマンド (「チェックアウト」、「移動」、「名前変更」、「メンバーリビジョンの更新」、「サブプロジェクトの作成」など) を使用して、必要に応じて伝播変更パッケージにエントリを追加することもできます。
すべての変更が完了したら、伝播変更パッケージをサブミットしてプロジェクトを更新できます。
* 
メンバーリビジョンを更新せずに伝播変更パッケージをサブミットすることもできます。この場合、ビルドマスタは伝播変更パッケージをソフトウェアがビルドされた時点で適用します。
伝播変更パッケージのエントリは、再同期された変更パッケージの対応するエントリよりも優先されます。したがって、ブランチから結合を実行し、その結果を伝播変更パッケージにチェックインすると、結果のリビジョンは、ブランチ上に存在する可能性のある、一覧表示されている変更パッケージ内のどのエントリよりも優先されます。
伝播変更パッケージを使用する利点
伝播変更パッケージを使用すると、他の開発者は CP の再同期コマンドの実行操作が重複したり、エラーや結合の競合を解決することなく、同じ一連の変更パッケージを適用できます。
伝播変更パッケージは、ビルドマスタが作業を実行する際にも役立ちます。CP の適用操作が失敗した場合、開発者は同じ変更パッケージで CP の再同期コマンドを使用し、依存関係と必要なマージを特定して、単一の伝播パッケージに必要な変更をすべて含めることができます。
伝播変更パッケージを使用すると、長い時間を必要とする大規模な CP の再同期操作を 1 回実行するのではなく、CP の再同期コマンドを繰り返し使用してプロジェクトの変更を収集することで、開発パス間の変更を徐々に伝播できます。
伝播変更パッケージを使用する場合、適用された変更パッケージが依存している変更パッケージは、前の CP の再同期操作によりプロジェクトに既に適用されていると、バックフィル一覧に表示されません。既に適用されている変更パッケージに関する警告メッセージが表示されます。
CP の再同期を使用して伝播変更パッケージを適用する場合には、結果が常に受け入れられるとは限らないため、注意が必要です。たとえば、バグの修正が既存のプロジェクト メンバー内に存在する場合、プロジェクト内にそのメンバーのアーカイブが既に存在します。その結果、CP の再同期により、変更されたメンバーがブランチに追加されます。この追加のブランチは、プロジェクトでは受け入れられない可能性があります。
伝播変更パッケージの使用例
abcBusiness 会社には、次の 2 つの開発チームが存在します。
メインのリリース サイクルで新しいフィーチャーとソフトウェアを開発する製品チーム
リリースされたソフトウェアを管理し、顧客から指摘されたバグを解決するメンテナンス開発チーム
製品チーム (PT) は、メインの開発パスに新しいフィーチャーとデザインを実装します。
メンテナンス開発チーム (MDT) は、リリース 2.0 のバリアント開発パスで作業し、新しくリリースされた製品の問題を解決します。このチームの主な目標は、リリース 2.0a のバグ修正を作成することです。MDT の作業プロセスは次のとおりです。
バグが顧客により報告されます。
バクに対する変更パッケージが作成され、この場合はコンテナ ID は 1204 となります。ワークフローが有効になり、アイテムが作成され、作成された変更パッケージに関連付けられます。
問題を修正する担当者として 1 人の MDT 開発者が割り当てられます。
MDT 開発者は、変更パッケージを作成します。
MDT 開発者は、必要な変更を実行してコードをテストします。
MDT 開発者は、変更したファイルをバリアント プロジェクトに再度チェックインし、ファイルを変更パッケージ 1204:1 に関連付けます。
この例では、MDT 開発者のすべての作業がバリアント開発パスにチェックインされ、リリース 2.0a の一部になります。ただし、MDT のバグ修正の作業は、次の製品リリースに組み込むことができるように、メインの開発パスに戻す必要があります。PT 開発者は、バグ修正に対応する変更を選択して、サンドボックスで適用します。CP の再同期コマンドは、新しい修正を適用するための最適なオプションです。
PT 開発者は、同じアイテムの 2 つ目の変更パッケージ 1204:2 を作成します。2 つ目の変更パッケージには、サマリー "メインの開発パスに適用される修正" が含まれます。PT 開発者は CP の再同期コマンドを開始し、メインの開発サンドボックス、およびこのアイテムの最初の変更パッケージ (1204:1) を選択します。2 つ目の変更パッケージ (1204:2) は、伝播変更パッケージとして使用されます。
すべての結合の競合を解決したら、開発者は伝播変更パッケージをサブミットし、Windchill RV&S は参照されている変更パッケージからの変更を適用します。
これで、バグ修正がメインの開発パスとバリアント開発パスの両方に対応し、問題がリリース 2.0a および次のメジャー製品リリースで修正されます。