Windchill Navigate 建構的部署流程
部署流程涉及在各種環境中提交及推進封裝。目標是確保封裝在到達最終部署環境之前，在每個階段都進行全面測試及驗證。
Navigate 的部署流程包括以下步驟：
1. 較低環境中的初始部署
2. 成熟度曲線階段
3. 生產環境中的最終部署
請考慮以下情境：您的小組根據目前需求選取使用案例，然後在衝刺週期中整合使用案例。流程涉及在各種階段中提交及推進封裝。最初，您透過提交來在較低環境中部署封裝。您的封裝會在成熟度曲線階段推進。最終推進會發生在最終部署階段。
詳細流程描述
1. 第一次/初始建構部署 - PTC 從客戶處接收的初始建構部署會經過 PTC 小組的全面審核。此審核需要的產出物包括：
◦ 完成的問卷：客戶填寫的詳細問卷。
◦ 建構封裝：由客戶/系統整合者提交的壓縮封裝。
 | 初始建構只會在 PTC 小組核准的情況下進入下一步，以確保其符合所需指導原則。 |
2. 成熟度曲線階段 - 此階段不需要 PTC 小組的核准。在此階段期間，建構會經過成熟度曲線，其中包括以下任務：
◦ 錯誤修正：識別並解決問題。
◦ 邏輯變更：調整建構的功能。
◦ 使用者接受度測試 (UAT)：確保建構符合使用者需求。
◦ 裝飾變更：調整使用者介面與體驗。
初始部署發生在非生產環境中。客戶或系統整合者負責維護對建構所做全部變更的完整文件集。
| | 藉由建構封裝與建構相依性 (對協力廠商物件庫) 解決的需求在此流程期間保持不變至關重要。如果發生任何變更，您必須重新啟動部署流程。 |
3. 生產環境中的最終建構部署 - 產品伺服器上的最終部署會經過 PTC 小組的全面徹底審核。此審核可確保在發行到生產環境中之前，建構的所有方面都符合品質、功能與法規遵循的最高標準。此審核需要的產出物包括：
◦ 完成的問卷：客戶填寫的詳細問卷。
◦ 建構封裝：由客戶/系統整合者提交的壓縮封裝。
◦ 詳細文件集：在成熟度階段期間對建構所做全部變更的完整文件集。如需詳細資訊，請參閱「建立完整文件集：主要指導原則」部份。
| | 此階段需要 PTC 小組的核准。 |
客戶指導原則
• 需求的一致性 - 您上載的初始建構必須包含所有重要內容。系統整合者在第一階段與第三階段這兩個部署階段期間避免引入需求或相依性 (尤其是對協力廠商物件庫) 的重大變更至關重要。
• 完整文件集 - 您必須維護對建構所做全部修改的完整文件集。
• PTC 小組審核 - PTC 小組會先審核所有變更，然後再推進建構以在生產環境中進行最終部署。
透過遵守這些指導原則，您可以確保 Windchill Navigate 建構的部署流程安全穩定。
您應多久重複一次部署流程？
在考慮自訂時，您會考慮到特定的使用案例以及在衝刺週期中工作的開發小組。您的小組擇取可能是一個需求或一組需求的使用案例，並開始在衝刺週期中予以開發。有時可能需要多個衝刺週期才能準備好建構。
例如，在具有五個衝刺的六個月發行週期中，在這些衝刺中選取並開發需求。您可能有不同的時間表，例如包含開發、QA 與部署階段的 20 天衝刺。如果需求在週期中發生顯著變更，必須重新啟動流程，且需要核准。
部署流程的頻率取決於使用案例與衝刺週期數。例如，如果在 10 個衝刺週期內開發 10 個使用案例，會遵循流程 10 次。如果您在一個衝刺週期內開發 5 個使用案例，會遵循流程兩次。
其他範例：
1. 範例 1：較短衝刺週期
◦ 您有 2 週的衝刺週期。您選取需求、予以開發 10 天、花費 2 天進行 QA，然後部署。如果您有 6 個需求，將在 12 週內遵循流程 6 次。
2. 範例 2：重疊需求
◦ 您有跨越多個衝刺的重疊需求。例如，需要 3 個衝刺完成的需求將針對每個衝刺遵循流程一次，進而確保持續整合與測試。
3. 範例 3：主要變更週期中期
◦ 如果您在週期中期對需求進行重大變更，例如調整資料模型，必須重新啟動流程。這可確保重新評估所有相依性，並獲得核准。
4. 範例 4：頻繁部署
◦ 您偏好頻繁部署且有 1 週的衝刺週期。您開發 4 天、QA 1 天，並在最後一天部署。若有 8 個需求，將在 8 週內遵循流程 8 次。
5. 範例 5：自訂時間表
◦ 您根據專案需求設定自訂時間表。例如，您可能有一個 30 天的衝刺週期，其中包含 20 天的開發、5 天的 QA 與 5 天的部署。您根據需求數及其複雜度調整流程頻率。
問卷中包含哪些資訊？
在部署流程期間，您必須完成兩個問卷：
1. 初始部署問卷 - 在較低環境中進行第一次部署時需要此問卷。它可確保在繼續之前已進行所有適當的初步檢查與組態。
2. 最終部署問卷 - 在生產環境中進行最終部署時需要此問卷。它可核對所有重要方面都已經過審核及核准，進而確保順利且成功進行部署。
問卷的範例如下：
問題 | 答案 | |
|---|---|---|
一般詳細資訊 | 您的客戶帳戶名稱 | |
您的 Windchill 版本 | ||
您的 Windchill Navigate 版本 | ||
您的規劃部署日期 | ||
您的規劃部署環境 | ||
Package Details | 您是否已在較低環境中測試此封裝？(如果是，請為環境命名) | |
您已實行哪種類型的自訂？ | ||
此封裝中是否使用任何協力廠商物件庫？ | ||
您使用預設驗證方法，還是此封裝依賴應用程式金鑰？ | ||
此自訂致力於解決的商業個案或目標為何？ | ||
您是否確保自訂的任何部份都不會違反護欄？ | ||
舊封裝與新封裝 (如果有) 之間的差異為何？ |
| | 在此問卷中，您需要描述舊封裝與新封裝之間的任何差異。例如，您可以解釋是否有新增的新功能、修正的任何錯誤，或版本編號的變更。這些差異非常重要，因為它們有助於確保參與部署流程的每個人都瞭解已變更的內容。這可以防止出現問題、確保相容性，並確保新封裝符合所有需求。 |
建立完整文件集：主要指導原則
當您提交最終建構以在生產環境中部署時，請務必包含在成熟度階段期間所做全部變更的完整文件集。此文件集應詳細說明在整個開發流程中發生的每個更新、功能新增、錯誤修正與版本修訂。
透過提供完整文件集，您可確保所有利害關係人都瞭解變更，這有助於進行疑難排解、保持一致性以及核對建構是否符合所有需求。此步驟對於順利且成功進行部署、將錯誤風險降至最低並確保生產環境為新建構做好充分準備至關重要。
請考慮下列情境：
通常，您會從版本 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 - 簡潔的變更記錄檔：供快速參考的單行摘要
範例 2 - 詳細的變更記錄檔：完整的更新清單
範例 3 - 全面的變更記錄檔：更新、修正與改善的詳盡編譯
