提交並推進您的封裝
當 CCD 封裝準備就緒時，請使用自動建構部署繼續。自動建構部署流程包括根據您的權利及系統架構來協調組態與自訂的推進。
您可以透過將 CCD 封裝與資訊清單檔案上載至您儲存體帳戶中的個別位置來提交建構。必須先在 /data/builds 上載 CCD 封裝。然後，必須在 /data/builds/deploy 上載資訊清單檔案。
此動作會觸發自動建構部署工作流程。此流程透過電子郵件接收的通知任務驅動。電子郵件中的資訊會引導您完成不同的步驟。任務核准者會在資訊清單檔案中宣告。資訊清單檔案的範例可在觸發器自動化部署主題中找到。
 |
將下列幾點視為先決條件：
• 必須設定 Azure BLOB 儲存體位置。必須從 PTC Cloud 取得授權詳細資訊。
◦ PTC 為您提供此活動的 SAS URL。
◦ 您應該向 PTC 支援入口網站提交請求，以將您的 IP 位址新增至允許清單中。在案例的詳細資訊中，提供穩定的 IP 位址。
• 您必須提交請求，才能將配管配置為與資訊清單檔案中提及的值相符。範例為 int1 或 pipeline1。如需有關 deploy_pipe 屬性的詳細資訊，請參閱觸發自動化部署主題中的「建立資訊清單檔案」部分。
|
自動化建構部署工作流程的第一步是檢查 CCD 封裝。系統會檢查 CCD 封裝，以確定其是否符合 Windchill+ 指南。檢查之後，系統會產生報告，並使其可在儲存體帳戶中使用。
您可以在下列位置找到報告與記錄檔：/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 等。如需詳細資訊，請參閱 Targets。
|
報告名稱
|
已實行的檢查
|
|---|---|
|
cwave_<CustomerShortName>_<Date-Time>_IntakeProcessor.html
|
Windchill+ 檢查 (Windchill+ 允許的自訂、取代、不支援的 API、安全性)
|
|
cwave_<CustomerShortName>_<Date-Time>_SpotBugs.html
|
靜態程式碼檢查 (Java 最佳作法)
|
請考慮下列事項：
• 如果 CCD 封裝有任何檢查失敗，會傳送通知給您，且提交流程會停止。
• 如果 CCD 封裝符合規定，流程會繼續，且會將建構推進至資訊清單檔案中定義的目標。
• 建構部署成功後，您有七天時間完成測試。
|
|
身為客戶，您負責 CCD 封裝內容。提交建構即表示您證明開發符合 PTC 安全性指南。如需有關 PTC 安全性指南的資訊，請參閱安全性自訂指南。
|
適用於 CCD 封裝構成的 Windchill+ 護欄
您的 CCD 封裝及其構成必須符合特定目錄結構。請遵循為 CCD 封裝的目錄結構與檔案內容指定的護欄：
• CCD 封裝的大小不得超過 100MB。
• CCD 封裝可以包含下列資料夾：
|
資料夾
|
描述
|
|---|---|
|
Configurations
|
無或一個 Configurations 資料夾
|
|
Generated
|
無或一個 Generated 資料夾
|
|
customlib
|
無或一個 customlib 資料夾
|
|
<custom module(s)>
|
一或多個自訂模組資料夾
|
|
|
在四個資料夾中，至少一個資料夾必須存在於您的 CCD 封裝中。
|
• descriptor.xml 檔案必須存在於您 CCD 封裝的所有自訂模組資料夾中。
• Generated 資料夾可以為空，也可以包含下列一個或兩個資料夾：
◦ db 資料夾 - db 資料夾可以為空。若非如此，它必須包含 db/conf/SchemaConfig.xml 檔案。
◦ BAC 資料夾 - BAC 資料夾中僅允許有一個 BAC .zip 檔案。BAC 資料夾中的 Mapping.xsl 檔案可提供 BAC 對應。
◦ 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 (在組態層級無效)
◦ 資源路徑上 JasperReports 資料夾內的有效檔案 - .jrxml、.jasperProperties 與 .properties
◦ src_web 路徑上 JasperReports 資料夾內的有效檔案類型 - .gif
◦ customlib 資料夾內的有效檔案 - .jar
◦ 下列資料夾內不允許有名稱為 apps 的資料夾：
▪ configurations/resources
▪ main/resources
▪ main/src_web
當提交封裝進行部署時，會檢查這些護欄。會報告任何不遵循的情況。部署記錄檔包含 RITM 摘要報告，例如 RITM0910921.txt。此報告概述封裝是否符合 Windchill+ 護欄。RITM 摘要報告的範例如下：
您可以在包含這些護欄檢查詳細資訊的詳細報告 zip 檔案中找到 RITM 詳細記錄檔。此 zip 檔案包含一個可提供護欄檢查詳細資訊的記錄檔。
zip 檔案的範例為 RITM0910921_Reports.zip。
記錄檔的範例為 preValidate_20240402-142645.log。
| | 雖然並未強制執行這些規則，但您必須注意任何差異，並主動對其進行修正。PTC 將來會強制執行其中一些規則，任何不遵循的情況都會使封裝此後無效。如需有關不允許的自訂與警告的詳細資訊，請參閱 Disallowed Customization。 |
上線之前
可以在沒有品質管制 (QA) 環境的情況下使用 Windchill+。也可以將進階 Windchill+ 與 QA 環境搭配使用。視情況而定，您可以遵循下列方法中提及的步驟：
具有 QA 環境的進階 Windchill+
當您將進階 Windchill+ 與品質管制 (QA) 環境搭配使用時，請執行下列步驟：
1. 將封裝提交至整合與功能接受度測試週期的整合環境。您可以經常觸發此測試週期。例如，一周多次。
◦ 使用 deploy_pipe : int 提交建構與資訊清單檔案。
如需詳細資訊，請參閱 Deploying Code and Configuration Package。
◦ 完成測試週期。在測試週期結束時，即視為任務完成，且環境會恢復為其先前的狀態。
| | 如果未在七天內完成此步驟，環境會自動恢復為先前的狀態。 |
2. 將您的封裝提交至 QA 環境進行 UAT，然後將封裝推進至生產環境。建議每月觸發 UAT 測試週期一次或兩次，因為此流程會將建構推進至生產環境。
◦ 完成測試週期。請考慮下列事項：
▪ 如果測試週期成功，會核准任務，且會將建構推進至生產環境。
▪ 如果測試週期不成功，會拒絕任務，且會將環境恢復為先前的狀態。
▪ 如果未在七天內完成測試週期，則環境會恢復為其先前的狀態。
沒有 QA 環境的基本 Windchill+
當您使用沒有品質管制 (QA) 環境的基本 Windchill+ Select 時，請執行下列步驟：
2. 完成整合與功能接受度測試週期。在測試週期結束時，任務即會完成，且環境會恢復為先前的狀態。
| | 如果未在七天內完成此步驟，則環境會恢復為其先前的狀態。 |
3. 使用 deploy_pipe : pipeline 重新提交相同建構與更新的資訊清單檔案。如需詳細資訊，請參閱 Deploying Code and Configuration Package。
4. 在整合環境中完成使用者接受度測試週期。請考慮下列事項：
◦ 如果測試週期成功 - 會核准任務，且會將建構推進至生產環境。
◦ 如果測試週期不成功 - 會拒絕任務，且會將環境恢復為先前的狀態。
◦ 如果未在七天內完成測試週期，環境會自動恢復為先前的狀態。
| | 所有測試活動都僅使用一個環境。系統一次只能執行一個測試活動。如果在此視窗中使用 deploy_pipe : int 提交建構，會自動遭到拒絕。 |
上線階段
確認上線階段後，必須將生產環境重新裝載至 QA 與整合環境。
您必須針對此活動在 PTC 支援入口網站中開啟服務請求。如需詳細資訊，請參閱開啟服務請求。
執行狀態
• 成功上線之後，所有環境都會從生產環境重新裝載。因此，PTC 強烈建議將變更傳播至開發環境。建議的方法是使用 BAC 並從整合環境匯出完整的 BAC 封裝。如需詳細資訊，請參閱使用 CCD 公用程式匯入 BAC 封裝。
請考慮下列事項：
◦ 必須至少匯出資料模型才能重新建構系統 (類型及屬性管理員)。
◦ 針對 BAC 不支援的物件，您可以利用 UI 從整合匯出 (如果可能)，或在開發環境中重新建立載入檔案。
• 之後，提交週期與「提交並推進您的封裝」主題中「上線之前」部份提及的提交週期類似。
• 主要版本上線之後，您必須將生產環境重新裝載至 QA 與整合環境。必須針對重新裝載活動開啟服務請求。如需詳細資訊，請參閱開啟服務請求。
| | • 在成功初始上線之後，應從生產重新裝載所有環境 (開發除外)。此重新裝載並非自動且需要服務請求。 • 「初始上線」是指第一次將應用程式部署到生產環境。在此階段，所有較低環境都會與生產同步處理，以確保整個部署環境的一致性與穩定性。 • 「主要上線」是指在「初始上線」之後，生產環境的任何後續發行版本。這些發行版本通常包含新功能、強化功能或修正，且為持續開發與交貨週期的一部份。 |