パッケージのサブミットとプロモート
CCD パッケージの準備が整った後、自動ビルド展開を使用して続行します。自動ビルド展開プロセスでは、コンフィギュレーションとカスタマイズのプロモーションがユーザーの資格と環境ランドスケープに合わせて調整されます。
CCD パッケージとマニフェストファイルを Storage アカウント上の各場所にアップロードすることによって、ビルドをサブミットできます。最初に、CCD パッケージを /data/builds にアップロードする必要があります。次に、マニフェストファイルを /data/builds/deploy にアップロードする必要があります。
この操作によって、自動ビルド展開ワークフローがトリガーされます。このプロセスは、電子メールによって受信した通知タスクによって駆動されます。電子メールには各手順に関する情報が記載されています。タスクの承認者はマニフェストファイルで宣言されています。マニフェストファイルの例については、「自動展開のトリガー」のトピックを参照してください。
 |
必要条件として、次の点を考慮してください。
• Azure BLOB Storage の場所を設定する必要があります。認証の詳細を PTC クラウドから取得する必要があります。
◦ PTC からこのアクティビティの SAS URL が提供されています。
◦ IP アドレスを許可リストに追加するよう、PTC サポートポータルにリクエストをサブミットする必要があります。ケースの詳細では、安定した IP アドレスを指定します。
• マニフェストファイルに記載されている値と一致するようにパイプラインを設定するよう、リクエストをサブミットする必要があります。たとえば、int1 または pipeline1 です。deploy_pipe 属性の詳細については、「自動展開のトリガー」のトピックの「マニフェストファイルの作成」のセクションを参照してください。
|
自動ビルド展開ワークフローの 1 つ目の手順は、CCD パッケージの検査です。CCD パッケージが Windchill+ ガイドラインに準拠しているかどうかが検査されます。検査後、レポートが生成され、Storage アカウントで使用できるようになります。
レポートとログは /data/builds/logs/<RITM Number>/ にあります。生成されるレポートとログのファイルの構文は次のとおりです。
• レポートの構文 - cwave_<CustomerShortName>_<Date-Time>_<Control Label>.html。ここで、<Control Label> には IntakeProcessor、SpotBugs、Logs などを指定できます。
• ログの構文 - ccd_<environment>_<Date-Time>_<ant target>_Logs.zip。ここで、<ant target> には deploy、load などを指定できます。詳細については、「ターゲット」を参照してください。
|
レポート名
|
実装されるチェック
|
|---|---|
|
cwave_<CustomerShortName>_<Date-Time>_IntakeProcessor.html
|
Windchill+ チェック (Windchill+ で許可されているカスタマイズ、廃止、サポートされていない API、セキュリティ)
|
|
cwave_<CustomerShortName>_<Date-Time>_SpotBugs.html
|
静的コードチェック (Java ベストプラクティス)
|
次の点を考慮してください。
• CCD パッケージがいずれかのチェックに失敗した場合、通知が顧客に送信され、サブミットプロセスが停止します。
• CCD パッケージが準拠している場合、プロセスが続行され、マニフェストファイルで定義されているターゲットにビルドがプロモートされます。
• ビルド展開が成功した後、7 日以内にテストを完了します。
|
|
顧客は CCD パッケージのコンテンツについて責任を負います。ビルドをサブミットすることで、PTC セキュリティガイドラインに従って開発が行われたことを証明することになります。PTC セキュリティガイドラインについては、「セキュリティカスタマイズのガイドライン」を参照してください。
|
CCD パッケージの構成のための Windchill+ ガードレール
CCD パッケージとその構成は、特定のディレクトリ構造に従っている必要があります。CCD パッケージのディレクトリ構造およびファイルコンテンツに関するガードレールに従ってください。
• CCD パッケージのサイズが 100 MB を超えてはなりません。
• CCD パッケージには以下のフォルダを含めることができます。
|
フォルダ
|
説明
|
|---|---|
|
Configurations
|
Configurations フォルダを含まないか、1 つのみ含む
|
|
Generated
|
Generated フォルダを含まないか、1 つのみ含む
|
|
customlib
|
customlib フォルダを含まないか、1 つのみ含む
|
|
<custom module(s)>
|
1 つ以上のカスタムモジュールフォルダ
|
|
|
CCD パッケージに、4 つのフォルダのうち少なくとも 1 つのフォルダが存在している必要があります。
|
• descriptor.xml ファイルは CCD パッケージのすべてのカスタムモジュールフォルダに存在していなければなりません。
• Generated フォルダは空にすることも、以下のフォルダのいずれかまたは両方を含めることもできます。
◦ db フォルダ - db フォルダは空にできます。空でない場合、db/conf/SchemaConfig.xml ファイルが含まれている必要があります。
◦ BAC フォルダ - BAC フォルダには BAC zip ファイルを 1 つだけ含めることができます。BAC マッピングは BAC フォルダ内の Mapping.xsl ファイルで指定できます。
◦ customlib には、パートナーの IP jar を格納する必要があります (存在する場合)。
• 指定可能な値は plusselect と meddev です。
• CCD パッケージには、以下の規則に示すような、ブロックされたファイルや予期しないファイルが含まれないようにしてください。
◦ パッケージ内で許可されないファイルのリスト - .jar、.class、.exe、.ser、.sql、.ddl、.pks、.pkb、.ora、.jasper、.cs、.cpp、.so、.dll、.jnilib、.dylib、.h、.cgf、.out、.ldif、.sh、.pl、.groovy、.gwt.xml、.gwt.modules.xml
◦ xconf フォルダ内で有効なファイル - .xconf
◦ conf フォルダ内で有効なファイル - .xml、.ini
◦ resources フォルダ内で有効なファイル - .tpl、.bas、.ddx、.html、.yml、.xjb、.ftl、.xml、.dtd、.xsl、.properties、.txt、.ini、.json、.js
◦ src フォルダ内で有効なファイル - .java、.rbInfo
◦ jsp フォルダ内で有効なファイル - .jsp、.jspf
◦ tags フォルダ内で有効なファイル - .tag、.tagf
◦ tlds フォルダ内で有効なファイル - .tld
◦ src_web フォルダ内で許可されないファイル - .java
◦ JasperReports フォルダの有効なパス - module/main/resources および module/main/src_web (コンフィギュレーションレベルでは無効)
◦ resources パスの JasperReports フォルダ内で有効なファイル - .jrxml、.jasperProperties、および .properties
◦ src_web パスの JasperReports フォルダ内で有効なファイルタイプ - .gif
◦ customlib フォルダ内で有効なファイル - .jar
◦ 次のフォルダ内では、apps という名前が付いたフォルダは許可されません。
▪ configurations/resources
▪ main/resources
▪ main/src_web
これらのガードレールは、パッケージが展開のためにサブミットされたときにチェックされます。準拠していないものはすべて報告されます。展開ログには RITM サマリーレポート (RITM0910921.txt など) が含まれています。このレポートでは、そのパッケージが Windchill+ ガードレールに準拠しているかどうかが示されています。RITM サマリーレポートの例を次に示します。
RITM 詳細ログは、これらのガードレールチェックの詳細を含む詳細レポート ZIP ファイルに含まれています。この ZIP ファイルには、ガードレールチェックの詳細を示すログファイルが含まれています。
ZIP ファイルの例としては、RITM0910921_Reports.zip があります。
ログファイルの例としては、preValidate_20240402-142645.log があります。
| | これらの規則は強制されませんが、規則からの逸脱に注意を払い、積極的に修正する必要があります。今後、PTC はこれらの規則の一部を実施します。準拠しない場合は、パッケージが無効と見なされます。許可されていないカスタマイズとその警告の詳細については、「許可されていないカスタマイズ」を参照してください。 |
本番稼動前
品質管理 (QA) 環境がない Windchill+ を使用できます。QA 環境があるアドバンス Windchill+ を使用することもできます。シナリオに応じて、次のアプローチで説明されている手順に従うことができます。
QA 環境があるアドバンス Windchill+
品質管理 (QA) 環境があるアドバンス Windchill+ を使用する場合は、次の手順を実行します。
1. パッケージを統合環境にサブミットして、統合および機能受け入れテストのサイクルに入ります。このテストサイクルは、週に数回などの頻度でトリガーできます。
◦ deploy_pipe : int を使用してビルドファイルとマニフェストファイルをサブミットします。
詳細については、「コードとコンフィギュレーションのパッケージの展開」を参照してください。
◦ テストサイクルを完了します。テストサイクルが終了すると、タスクが完了したものと見なされ、環境が以前の状態に戻ります。
| | この手順が 7 日以内に完了しなかった場合、環境は自動的に以前の状態に戻ります。 |
2. UAT の QA 環境にパッケージをサブミットしてから、パッケージを本番環境にプロモートします。UAT テストサイクルのプロセスによってビルドが本番環境にプロモートされるので、UAT テストサイクルは月に 1 回または 2 回トリガーすることをお勧めします。
◦ deploy_pipe : pipeline を使用してビルドファイルとマニフェストファイルをサブミットします。詳細については、「コードとコンフィギュレーションのパッケージの展開」を参照してください。
◦ テストサイクルを完了します。次の点を考慮してください。
▪ テストサイクルが成功した場合、タスクは承認され、ビルドが本番環境にプロモートされます。
▪ テストサイクルが成功しなかった場合、タスクは却下され、環境は以前の状態に戻ります。
▪ テストサイクルが 7 日以内に完了しなかった場合、環境は以前の状態に戻ります。
QA 環境がない基本 Windchill+
品質管理 (QA) 環境がない基本 Windchill+ Select を使用する場合は、次の手順を実行します。
2. 統合と機能受け入れテストのサイクルを完了します。テストサイクルが終了すると、タスクが完了し、環境が以前の状態に戻ります。
| | この手順が 7 日以内に完了しなかった場合、環境は以前の状態に戻ります。 |
3. deploy_pipe : pipeline を使用して同じビルドと更新されたマニフェストファイルを再サブミットします。詳細については、「コードとコンフィギュレーションのパッケージの展開」を参照してください。
4. 統合環境でユーザー受け入れテストサイクルを完了します。次の点を考慮してください。
◦ テストサイクルが成功した場合 - タスクは承認され、ビルドが本番環境にプロモートされます。
◦ テストサイクルが成功しなかった場合 - タスクは却下され、環境は以前の状態に戻ります。
◦ テストサイクルが 7 日以内に完了しなかった場合、環境は自動的に以前の状態に戻ります。
| | いずれのテストアクティビティでも、1 つの環境だけが使用されます。一度に実行できるテストアクティビティは 1 つだけです。この期間中に deploy_pipe : int を使用してビルドがサブミットされた場合、自動的に却下されます。 |
本番稼動段階
本番稼動段階を承認した後は、本番環境を QA 環境と統合環境にホスト再設定する必要があります。
このアクティビティ用に PTC サポートポータルでサービスリクエストをオープンする必要があります。詳細については、サービスリクエストのオープンを参照してください。
実行状態
• 本番稼動に成功すると、すべての環境が本番環境からホスト再設定されます。このため、開発環境に変更を反映することを強くお勧めします。BAC を使用し、統合環境から完全な BAC パッケージをエクスポートすることをお勧めします。詳細については、「CCD ユーティリティを使用した BAC パッケージのインポート」を参照してください。
次の点を考慮してください。
◦ システムを再構築するために少なくともデータモデルはエクスポートする必要があります (タイプおよび属性マネージャ)。
◦ BAC によってサポートされていないオブジェクトの場合、(可能な場合は) UI を使用して統合環境からエクスポートするか、開発環境でロードファイルを再作成できます。
• それ以降のサブミットサイクルは、「パッケージのサブミットとプロモート」のトピックの「本番稼動前」のセクションに記載されているものとほぼ同じです。
• メジャーな本番稼動の後は、本番環境を QA 環境と統合環境にホスト再設定する必要があります。ホスト再設定アクティビティのためのサービスリクエストをオープンする必要があります。詳細については、サービスリクエストのオープンを参照してください。
| | • 最初の本番稼働が成功した後、すべての環境 (開発環境を除く) を本番環境からホスト再設定する必要があります。このホスト再設定は自動では行われないため、サービスリクエストが必要です。 • 最初の本番稼働とは、アプリケーションを本番環境に初めて展開することを指します。この段階ですべての下位環境が本番環境と同期されます。これにより、展開ランドスケープ全体で一貫性と安定性が確保されます。 • メジャーな本番稼働とは、最初の本番稼働に続いて行われる、後続のすべての本番環境へのリリースを指します。通常、これらのリリースは進行中の開発および送信サイクルの一環であり、新機能、拡張機能、または修正が含まれています。 |