変更パッケージの概要

変更パッケージは、論理的な作業単位と見なすことができる、1 人のユーザーによって行われた変更をグループ化したものです。変更パッケージの作成者だけが、変更パッケージにエントリを追加できます。メンバー操作の実行中に変更パッケージを指定すると、変更パッケージのエントリが追加されます。

変更パッケージは、既にリポジトリ (サーバー) にコミットされたメンバーおよびサブプロジェクトに対する変更と、デスクトップ上にあってユーザーからだけ参照でき、リポジトリ (遅延中) にコミットされていない変更の両方のログとして機能します。変更パッケージレビューが必須の場合、変更パッケージは、コミットされる前に保留中にすることによって、リポジトリへの変更のコントロールとして機能します。

変更作業が完了して変更パッケージを終了するまで、変更パッケージはオープン状態です。レビューが必須の場合、変更パッケージを終了する前に別の状態になります。

変更パッケージの使用時には、次の規則が適用されます。

• 各変更パッケージには、一意の変更パッケージ ID (CP ID) があります。CP ID は、次の形式のコロン区切り識別子です。

Windchill RV&S のインテグレーションが有効である場合、アイテム ID がコンテナ ID として使用されます。

• 変更パッケージを閉じることができるのは、変更パッケージの作成者または変更パッケージ管理者だけです。ただし、変更パッケージが空である場合は、グローバルレベルの ManageEmptyChangePackage 権限を持つ他のユーザーも、その変更パッケージを閉じたり、破棄したりすることができます。

• 変更パッケージが閉じられた後で再度開くことができるのは、変更パッケージ管理者だけです。変更パッケージの適用または変更パッケージの再同期によって変更パッケージを伝播した場合は、変更パッケージ管理者でも再度開くことはできません。

変更パッケージをアイテムに関連付けることで、Windchill RV&Sのワークフローとドキュメントの管理を利用するよう変更パッケージの機能を拡張できます。

ワークフローおよびドキュメントとのインテグレーションの一環として、変更パッケージをWindchill RV&S アイテムと関連付けることができます。アイテムは、必要なアクションに関する詳細な情報を提供し、ソフトウェア開発サイクルと呼ばれる開発およびテストのワークフローを制御します。

Windchill RV&S アイテムは、ソフトウェア開発サイクルにおける変更を追跡します。たとえば、管理者は問題アイテムをソリューションアイテムと関連付け、両方のアイテムの追跡と監視が簡素化されるようにWindchill RV&S を構成できます。各アイテムには監査証跡があり、それを使用して問題解決プロセスの有効性について内部プロセスを評価できます。つまり、アイテムによってあらゆるエンジニアリングプロジェクトのすべての側面が追跡されます。

ワークフローおよびドキュメントとのインテグレーションにより、アイテムの影響を受ける開発者グループを特定することが可能になります。これらの開発者には、電子メール通知規則を使用して通知を送ることができます。

管理者は、変更パッケージを使用できるアイテムタイプを定義し、プロセスおよびワークフロー管理と統合されるようにソフトウェアコンフィギュレーション管理を構成します。

アイテムを使用して変更パッケージをグループ化し、変更の大規模な論理グループを作成できます。アイテムのチーム開発のために、アイテム内の各変更パッケージは異なるユーザーによって作成可能です。

アイテムおよび変更パッケージの使用時に適用される次の規則に注意してください。

• 単一のアイテムに対して、複数の変更パッケージを作成できます。アイテムの解決に 2 つ以上の変更セットが必要な場合、新しい変更セットのそれぞれについて新しい変更パッケージを作成できます。これを利用すると、複数のユーザーが同じアイテムで作業することも可能になります。

• アイテムタイプがオープン変更パッケージを許可しない場合、新しい変更パッケージを作成し、そのアイテムと関連付けることはできません。どのアイテムタイプがオープン変更パッケージを許可するかは、管理者に問い合わせてください。

• オープン変更パッケージを許可するのは、管理者によって指定されたアイテム状態だけです。オープン変更パッケージを許可しない状態に進もうとすると、Windchill RV&S によって、まずアイテムの変更パッケージを終了するよう指示されます。

• 通常は、すべての変更パッケージを終了しないかぎり、Windchill RV&S のワークフローを最終的な状態に進めることはできません。詳細については、管理者に確認してください。

• ワークフローが有効な場合、変更パッケージ ID は次の形式のコロン区切り識別子です。

変更パッケージには次の利点があります。

• 変更パッケージを使用すると、関連する変更を 1 つの論理単位としてグループ化できます。

• 変更パッケージを使用すると、進行中の作業をリポジトリ (サーバー) にまとめてサブミットできます (変更パッケージのサブミットを使用します)。これにより、ユーザーが進行中の関連作業を部分的にサブミットするのを防ぐことができます。

• 変更パッケージを使用すると、関連する変更を 1 回の操作でプロジェクトまたはサンドボックスに適用できます。

• 変更パッケージを使用すると、ユーザーはプロジェクト全体を再同期することなく、特定のアイテムを解決するために必要な変更を再同期できます。

• 変更のグループを 1 つの単位として表示できます。レビューが必須の場合、変更はレビューされてからサーバーリポジトリにコミットされます。

変更パッケージを使用して開発を制御する方法の例を次に示します。この例をレビュープロセスと組み合わせて、どの変更がリポジトリの永続部分になるかを制御できます。

1. ワークフローおよびドキュメントが有効な場合は、対処する必要があるアイテムをサブミットします。

2. アイテムに対処するために実行する必要があるタスクのグループに対して、変更パッケージを作成します。変更パッケージの作成中に、アイテムに関連付けます。

4. 開発プロセスの一環として、アイテムの影響を受けるメンバーを特定します。影響を受けるメンバーで操作を実行するときの変更パッケージを指定します。操作が「変更パッケージ」ビューに一覧されます。

5. アイテムに対処するための開発がすべて完了したら、変更パッケージをサブミットします。ロックされたメンバーは遅延中のチェックイン操作に変換されてからチェックインします。遅延中のすべての操作がサブミットされます。

6. アイテムに対処する作業が完了したら、変更パッケージを閉じます。変更パッケージが「終了」状態に移行し、「変更パッケージ」ビューから消えます。

7. ワークフローに沿ってアイテムを進めます。この時点で、確認フェーズが開始されます。アイテムに対処するために追加の作業を実行する必要があると判断された場合、ユーザーはアイテムをワークフロー内の以前の状態に移動します。その後、自分または別の開発者が追加の変更パッケージを作成します。アイテムへの対処が十分に行われるまで、このプロセスを繰り返します。