Windchill+ での WBM マイグレーション
マイグレーションには Windchill Bulk Migrator (WBM) モジュールを使用します。このトピックでは、Windchill Bulk Migrator (WBM) の各種アクティビティについて説明します。
必要条件
WBM マイグレーションシナリオにはいくつかの特殊性がありますが、これはこのヘルプセンターのほかのセクションで説明されている概念から一貫して構築されています。
• WBM マイグレーションシナリオは、マイグレーション環境と QA 環境が使用される高度な Windchill+ シナリオです。環境のランドスケープは次のとおりです。
• WBM マイグレーションでは、Windchill+ 専用に構築された自動フレームワークが利用されます。マイグレーション環境ではバックエンドアクセス権は必要なく、付与されません。
• マイグレーションはどれ 1 つとして同じではありません。このセクションでは、WBM マイグレーションシナリオの大部分をサポートするために Windchill+ で利用可能なサービスについて説明します。ただし、複雑度に応じて、顧客またはパートナーはマイグレーションプロジェクトを設計および計画し、リハーサルの数、必要条件、オンプレミスで実行する追加の必須タスクなどの特定の要件に合わせて調整する必要があります。
• 移行するメタデータの構造にはデータベースが必要です。複数回の変換を回避するために、オンプレミスのステージングデータベースを使用するものとします。Oracle データベースを使用する必要があります。Windchill バージョンの要件に従って、Oracle データベースを使用する必要があります。データベース構造は Windchill WBM ステージングデータベースの要件を満たしている必要があります。
• WBM ステージングデータベース用に、オンプレミスのデータベーススキーマを別個に作成することをお勧めします。
• Windchill+ が混在モードをサポートしていないため、Windchill は、変更管理レガシーデータモデルから、変換ユーティリティを使用する新しいフレキシブルデータモデルに移行しました。したがって、Windchill Bulk Migrator で一括マイグレーションプロセスを実行する前に、ソースシステムをフレキシブルモードに変換する必要があります。詳細については、「Removal of Legacy Links from Windchill 13.0.2.0」を参照してください。
マイグレーション環境
マイグレーション環境とは、コード、コンフィギュレーション、データをまとめる規定されたプロセスが発生する場所のことです。マイグレーション用にビルドパッケージをサブミットするほかに、Windchill Bulk Migrator (WBM) を使用してステージングデータをサブミットします。このデータは、評価のためにマイグレーションステージングデータベースにロードされます。コード、コンフィギュレーション、データの移動はすべて、Windchill+ の中核を成す運用フレームワークの一部です。たとえば、システム A からデータを生成してある場所に配置すると、Windchill+ によってすべてのデータがシステム B に自動的に移行されます。
マイグレーション後、ビルドパッケージを QA 環境にサブミットしてから、本番環境にサブミットします。
WBM マイグレーションアクティビティ
WBM マイグレーションアクティビティに関連して、次の点に注意してください。
本番稼動前段階
マイグレーションロードテストを開始する前に、統合環境を使用して、すべてのコード変更が統合され、ビルドで成熟度レベルに達します。ビルドを展開するプロセスは、パッケージのサブミットとプロモートのトピックで説明されているプロセスとほぼ同じです。
以下の手順を実行します。
2. 統合と機能受け入れテスト (FAT) のサイクルを完了します。テストサイクルが終了すると、タスクが完了し、環境が以前の状態に戻ります。
 | この手順が 7 日以内に完了しなかった場合、環境は以前の状態に戻ります。 |
マイグレーション環境の手順
マイグレーション環境はロードテストに使用されます。以下の手順を実行します。
1. AzCopy を使用して、ステージングデータベースダンプをストレージ領域にアップロードします。
詳細については、以下のリンクを参照してください。
2. ステージングデータベースダンプのインポートをリクエストするサービスリクエストをオープンします。詳細については、サービスリクエストのオープンを参照してください。
3. ビルドを展開します。ビルドを展開するプロセスは、パッケージのサブミットとプロモートのトピックで説明されているプロセスとほぼ同じです。このトピックは、マイグレーション環境へのビルドの展開に適用されます。
| | デフォルトでは、マイグレーション環境においては、この手順の間に作成されたバックアップは 30 日間保持されます。 |
5. ロードを実行するサービスリクエストをオープンします。
6. コンテンツマイグレーションの場合、Storage アカウントからコンテンツマップファイルを取得し、コンテンツコピースクリプトを準備します。その後、スクリプトが添付されたサービスリクエストをオープンし、最終的なコンテンツ転送を実行します。詳細については、サービスリクエストのオープンを参照してください。
7. マイグレーションテストサイクルを完了します。テストサイクルの最後に、サービスリクエストを通じてリクエストされた以下のいずれかの操作 (優先順に記載) により、環境は空の状態に戻されます。
◦ 本番環境からのホスト再設定
◦ 再プロビジョニング (初回マイグレーションの場合にのみ使用され、以降のデータマイグレーションには使用されません)。
QA 環境の手順
QA 環境は UAT に使用されます。以下の手順を実行します。
1. ステージングデータベースにインポートされた最新状態のデータで同じプロセスを繰り返します。
◦ deploy_pipe : pipeline を使用してビルドファイルとマニフェストファイルをサブミットします。
| | デフォルトでは、QA 環境においては、この手順の間にとられたバックアップは 30 日間保持されます。 |
2. QA 環境でのロードの実行をリクエストするサービスリクエストをオープンします。詳細については、サービスリクエストのオープンを参照してください。
3. コンテンツマイグレーションの場合、Storage アカウントからコンテンツマップファイルを取得し、コンテンツコピースクリプトを準備します。その後、スクリプトが添付されたサービスリクエストをオープンし、最終的なコンテンツ転送を実行します。コンテンツマップファイルの作成の詳細については、WBM の各段階を参照してください。
4. UAT テストサイクルを完了します。30 日以内に次のいずれかの決定を行います。
◦ テストサイクルが成功した場合 - タスクが承認され、ビルドのみが本番環境にプロモートされます。
◦ テストサイクルが成功しなかった場合:
▪ タスクを却下でき、環境は以前の状態に戻ります。
▪ タスクを承認でき、ビルドが本番環境にプロモートされます。バグを修正するために以降のビルドをサブミットできます。
◦ テストサイクルが 30 日以内に完了しなかった場合、環境は自動的に以前の状態に戻ります。環境を維持するには、タスクを承認する必要があります。
| | QA 完全ロードがさらに必要な場合、サービスリクエストを使用してリクエストされた (優先順に) 次に示すいずれかの操作により、環境が空の状態に戻ります。 • 本番環境からのホスト再設定。 • 再プロビジョニング (初回マイグレーションの場合のみ、以降のデータマイグレーションには使用されません)。 |
オプションで、本番稼動向けに差分ロードを計画している場合、ロードは本番環境で独立して行う必要があります。本番環境でのロードの実行をリクエストする (繰り返す) サービスリクエストをオープンします。詳細については、サービスリクエストのオープンを参照してください。
本番稼動段階
• この段階では、承認済みのビルドが QA 環境と本番環境にすでに存在します。
• さらに、本番環境で以前のデータのロードが可能な場合もあります。
• 本番稼動カットオーバー中にビルドのサブミットが必要ない場合 (または、本番稼動に必要なビルドを事前にサブミットしている場合)、次の手順を実行します。
1. 最新のステージングデータベースダンプを Storage アカウントにアップロードします。
2. 最新のステージングデータベースのインポートをリクエストするサービスリクエストをオープンします。
3. 本番環境でロードを実行するサービスリクエストをオープンします。
4. コンテンツマイグレーションの場合、スクリプト作成後に、最終的なコンテンツ転送のためのサービスリクエストをオープンします。
• ビルドのサブミットが必要な場合、「QA 環境の手順」のセクションで説明されている、ビルドのサブミットとプロモーションのプロセスに従います。その後、「QA 環境の手順」のセクションで説明されているように、本番環境アクティビティとサービスリクエストを実行します。
• 本番稼動を承認した後は、本番環境を QA 環境と統合環境に (以降のマイグレーションが計画されている場合はマイグレーション環境にも) ホスト再設定する必要があります。ホスト再設定アクティビティのためのサービスリクエストをオープンする必要があります。
実行段階
• 本番稼動に成功すると、すべての環境が本番環境からホスト再設定されるので、開発環境に変更を反映することを強くお勧めします。
◦ データモデルは最低限必要であり、開発環境の開始点として使用する必要があります。
◦ 最新のビルドを再使用できます。
• 以降にマイグレーションが行われる場合、「本番稼動前」のセクションで説明されているプロセスを繰り返す必要があります。
| | 既存のデータの損失を回避するため、プロジェクトの設計段階とプランニング段階の間に環境再表示アクティビティについて慎重に検討してください。 |
最終的な考慮事項
• 大規模なマイグレーションの場合に、本番稼動カットオーバー中の影響を緩和するには、差分ロードを許可するようにマイグレーションアクティビティを設計することを強くお勧めします。
• マイグレーションプロジェクトはどれ 1 つとして同じではありません。マイグレーションプロジェクトが成功するためには、確実なプランニング、スコーピング、リスク管理、依存管理などのアクティビティを実行する必要があります。これらのアクティビティにより、マイグレーションの設計が適切に行われ、スムーズな本番稼動カットオーバーが実現します。
• マイグレーションテストの見積りは実際より低くなりがちです。単純なマイグレーションプロジェクトの場合、3 回のテストマイグレーションサイクルから始めることをお勧めします。複雑度が増すとともに、さらに多くのサイクルの実装を計画できます。