Windchill Navigate ビルドの展開プロセス
展開プロセスでは、さまざまな環境を通じてパッケージをサブミットおよびプロモートします。その目的は、パッケージが最終的な展開環境に到達する前に、各段階においてそのパッケージの徹底的なテストと検証が確実に行われるようにすることです。
Navigate の展開プロセスには、以下の手順が含まれます。
1. 下位環境での初期展開
2. 成熟度カーブの段階
3. 本番環境での最終展開
次のシナリオについて考えます: チームは現在の要件に基づいてユースケースを選択し、そのユースケースをスプリントサイクルに統合します。このプロセスでは、さまざまな段階を通じてパッケージをサブミットおよびプロモートします。最初に、パッケージをサブミットして下位環境に展開します。パッケージは成熟度カーブの段階でプロモートされます。最終的なプロモーションは、最終展開段階で行われます。
詳細なプロセスの説明
1. 最初/初期のビルド展開 - PTC がお客様から受け取った初期ビルド展開は、PTC チームによる徹底的なレビューを受けます。このレビューに必要な成果物は次のとおりです。
◦ 記入済みの質問表: お客様が記入した詳細な質問表。
◦ ビルドパッケージ: お客様/システムインテグレーターによってサブミットされた圧縮パッケージ。
 | 初期ビルドは、PTC チームが承認して必要なガイドラインを満たしていることを確認した場合にのみ、次の手順に進みます。 |
2. 成熟度カーブの段階 - この段階は PTC チームの承認を必要としません。この段階では、ビルドは成熟度カーブをたどります。以下のタスクが実施されます。
◦ バグの修正: 問題を特定して解決します。
◦ ロジックの変更: ビルドの機能を微調整します。
◦ ユーザー受け入れテスト (UAT): ビルドがユーザー要件を満たしていることを確認します。
◦ 外観の変更: ユーザーインタフェースとユーザーエクスペリエンスを調整します。
初期展開は非本番環境で行われます。お客様またはシステムインテグレーターは、ビルドに対して行われたすべての変更に関する詳細なドキュメントを維持する責任を負います。
| | このプロセスの間は、当該ビルドパッケージで対応している要件や、ビルドの依存関係 (サードパーティライブラリに対する) を変更しないことが非常に重要です。何らかの変更が発生した場合は、展開プロセスを最初からやり直す必要があります。 |
3. 本番環境での最終ビルド展開 - 本番環境のサーバーへの最終展開は、PTC チームによる徹底的かつ包括的なレビューを受けます。このレビューでは、ビルドがすべての側面で品質、機能、およびコンプライアンスの最高基準を満たしていることを、本番環境へのリリース前に確認します。このレビューに必要な成果物は次のとおりです。
◦ 記入済みの質問表: お客様が記入した詳細な質問表。
◦ ビルドパッケージ: お客様/システムインテグレーターがサブミットする圧縮パッケージ。
◦ 詳細ドキュメント: 成熟度段階の間にビルドに対して行われたすべての変更に関する包括的なドキュメント。詳細については、「詳細ドキュメントの作成: 主要なガイドライン」のセクションを参照してください。
| | この段階には PTC チームの承認が必要です。 |
お客様向けのガイドライン
• 要件の一貫性 - アップロードする初期ビルドに、すべての重要なコンテンツが含まれている必要があります。システムインテグレーターは、第 1 段階と第 3 段階の 2 つの展開段階で、要件や依存関係 (特にサードパーティライブラリに対する) に大幅な変更を行わないようにすることが非常に重要です。
• 詳細なドキュメント - ビルドに対して行われたすべての修正に関する包括的なドキュメントを維持する必要があります。
• PTC チームによるレビュー - PTC チームは、本番環境への最終展開に向けてビルドがプロモートされる前に、すべての変更をレビューします。
これらのガイドラインを順守することで、Windchill Navigate ビルドの安全かつ安定した展開プロセスを実現できます。
展開プロセスを繰り返す必要がある頻度
カスタマイズを検討する際には、具体的なユースケースを念頭に置いており、スプリントサイクルで作業する開発チームがいます。チームは、ユースケース (1 つの要件の場合もあれば、要件セットの場合もあります) を選択し、スプリントサイクルで開発を開始します。ビルドを準備するために複数のスプリントサイクルが必要となる場合があります。
たとえば、5 回のスプリントが含まれる 6 か月のリリースサイクルでは、要件は各スプリント内で選択されて開発されます。タイムラインはさまざまで、開発、QA、展開の各フェーズを含む 20 日間のスプリントのような場合もあります。サイクル中に要件が大幅に変更された場合は、プロセスを最初からやり直す必要があり、承認が必要です。
展開プロセスの頻度は、ユースケースとスプリントサイクルの数によって変わります。たとえば、10 回のスプリントサイクルで 10 個のユースケースを開発する場合、このプロセスが 10 回実行されます。1 回のスプリントサイクルで 5 個のユースケースを開発する場合、このプロセスは 2 回実行されます。
その他の例:
1. 例 1: 短いスプリントサイクル
◦ スプリントサイクルは 2 週間です。1 個の要件を選択し、それを 10 日間で開発し、2 日間で QA を行った後、展開します。6 個の要件がある場合は、このプロセスを 12 週間で 6 回実行します。
2. 例 2: 重複する要件
◦ 複数のスプリントにまたがる、重複する要件があります。たとえば、完了までに 3 回のスプリントを要する要件では、スプリントごとにプロセスを 1 回実行し、継続的インテグレーションとテストを確保します。
3. 例 3: サイクル途中での大きな変更
◦ サイクルの途中で、要件に対してデータモデルの変更などの大幅な変更を行った場合は、プロセスを最初からやり直す必要があります。これにより、すべての依存が再評価され、承認を取得できるようになります。
4. 例 4: 頻繁な展開
◦ 頻繁な展開が好ましく、スプリントサイクルを 1 週間に設定しています。4 日間で開発し、1 日間で QA を行い、最終日に展開します。8 個の要件がある場合は、このプロセスを 8 週間で 8 回実行します。
5. 例 5: カスタムタイムライン
◦ プロジェクトのニーズに基づいてカスタムタイムラインを設定します。たとえば、スプリントサイクルを 30 日間に設定し、そのうち 20 日間を開発、5 日間を QA、5 日間を展開に使用します。プロセスの頻度は、要件の数とその複雑度に基づいて調整します。
質問表に含まれる情報
展開プロセス中に次の 2 つの質問表に回答する必要があります。
1. 初期展開の質問表 - この質問表は、下位環境での最初の展開に必要です。これにより、先に進む前にすべての事前チェックとコンフィギュレーションが適切に行われたことを保証します。
2. 最終展開の質問表 - この質問表は、本番環境での最終展開に必要です。これにより、すべての重要な側面がレビューおよび承認されていることを確認し、スムーズで正常な展開を保証します。
質問表の例を以下に示します。
質問 | 回答 | |
|---|---|---|
一般的な詳細 | お客様のアカウント名 | |
お使いの Windchill のバージョン | ||
お使いの Windchill Navigate のバージョン | ||
展開予定日 | ||
展開予定環境 | ||
パッケージの詳細 | このパッケージは下位環境でテスト済みですか? (「はい」の場合はその環境名を記入) | |
どのようなタイプのカスタマイズを実装しましたか? | ||
このパッケージではサードパーティのライブラリが使用されていますか? | ||
デフォルトの認証方法を使用していますか、それともこのパッケージはアプリケーションキーに依存していますか? | ||
このカスタマイズで対処しようとしているビジネスケースまたは目的は何ですか? | ||
カスタマイズ内にガードレールに違反している部分がないことを確認しましたか? | ||
古いパッケージと新しいパッケージの違いは何ですか (存在する場合)? |
| | この質問表では、古いパッケージと新しいパッケージの違いを説明する必要があります。たとえば、追加された新機能、修正されたバグ、バージョン番号の変更があるかどうかを説明するなどです。これらの違いは、展開プロセスに関与するすべての人が変更内容を確実に把握するのに役立つため、重要です。これにより、問題を防ぎ、互換性を確保し、新しいパッケージがすべての要件を確実に満たすようにすることができます。 |
詳細ドキュメントの作成: 主要なガイドライン
本番環境への展開用に最終ビルドをサブミットする際には、成熟度段階で行ったすべての変更の包括的なドキュメントを含めることが非常に重要です。このドキュメントには、開発プロセス全体を通じて発生したすべての更新、機能追加、バグ修正、および改訂の詳細を記載する必要があります。
詳細なドキュメントを提供することで、すべての関係者が変更内容を把握できるようになり、トラブルシューティング、一貫性の維持、ビルドがすべての要件を満たしていることの検証に役立ちます。この手順は、展開をスムーズに進めて正常に完了させるために不可欠であり、エラーのリスクを最小限に抑え、本番環境を新しいビルド用に完全に準備できるようにします。
以下のシナリオについて考えてみます。
通常、ビルドサイクルはバージョン 1.0 から開始します。後続の段階でビルドを改訂するにつれて、1.1、1.2 のようにバージョンに更新することがあります。ビルドは、本番サーバーに展開する準備が整うまでに複数回改訂され、1.7 のような最終バージョンに達している場合があります。
各改訂で行った変更の詳細な記録を保持しておく必要があります。たとえば、5 個のアイテムを変更する場合は、それらの変更を明確に文書化します。このドキュメントは、リリースノートの形式にすることができます。そのサイズは製品によって異なります。
たとえば、ドキュメントには次のような情報が含まれる場合があります。
• バージョン 1.4.6: 特定の問題を処理するための修正を追加。
• バージョン 1.4.5: 新機能を実装。
• バージョン 1.4.4: 特定の機能のパフォーマンスが向上。
このタイプのドキュメントは、バージョン 1.0 から 1.7 までのビルドの過程を追跡するのに役立ちます。スクリーンショットや、関連情報を最も適切に伝達できる任意のフォーマットを使用できます。重要なのは、包括的な変更の追跡を確実に行うことです。Word ドキュメント、Excel シート、またはその他の形式でも構いません。ニーズに最適なフォーマットを考案してください。
変更ログの例を以下に示します。
例 1 - 簡潔な変更ログ: クイックリファレンス用の 1 行のサマリー
例 2 - 詳細な変更ログ: 更新の包括的なリスト
例 3 - 包括的な変更ログ: 更新、修正、改善の網羅的なまとめ
