Windchill+ 存取、部署與組態
 |
「企業管理員」(BA) 角色提供了更高的權限，可支援對企業至關重要的組態變更，包括存取網站層級公用程式頁面。此功能雖然提升了靈活性，但必須謹慎使用，且不能取代建議的 CCD 部署方法。
欲開始使用企業管理員功能，您必須提出服務請求。核准之後，網站管理員會將您指派至 Site Business Administrator - Contributor (Site) 群組，以授與您必要的權限。如需詳細資訊，請參閱開啟服務請求。
如需有關「企業管理員」角色的詳細資訊，請參閱企業管理員使用者群組。
|
存取權
• 您有權存取整合環境的前端部份，包括組織層級與網站管理層級公用程式頁。
• 您擁有管理存取權，此存取權僅限於 QA 與生產環境的網站層級與組織層級公用程式頁。此存取權應該主要用於僅檢視的目的，但對於新企業管理員角色而言，並不會強制這樣做。PTC 建議僅出於疑難排解和監視目的使用此存取權。可供您使用的特定組織層級公用程式會根據環境而有所不同。此存取權的使用須嚴格遵守職責範圍，杜絕濫用。
• 您無權在任何 PTC 託管的 Windchill+ 環境中存取 Windchill 伺服器的後端部份。後端存取僅在本機開發環境中可用，可以透過開發人員託管的虛擬機器形式，也可以透過雲端入口網站託管的虛擬機器形式。
部署方法
• PTC 僅支援透過自動建構部署流程部署建構封裝。
• 自動建構部署僅接受一種封裝方法，稱為 CCD (Code and Configuration Deployment)。
• CCD 公用程式隨 PTC Windchill PDMLink 一起提供和安裝。如需詳細資訊，請參閱 Deploying Code and Configuration Package。
• 系統會使用 Business Administrative Change (BAC) 架構來捕捉、匯出及匯入企業組態。欲推進，必須將 BAC 封裝包括在 CCD 封裝中。
• CCD 是唯一支援的部署方法。
• BAC 封裝必須包括所有組態，並根據發行 Cadence 與排程組合指定時間範圍內的所有工作串流 (累積)。如需詳細資訊，請參閱使用 CCD 公用程式匯入 BAC 封裝。
• PTC 不建議使用 BAC 管理您的容器「存取控制清單」(ACL)。請改用 CCD 封裝中支援的 LoadFromFile 架構。如需詳細資訊，請參閱 CCD Package Structure。
• 不允許透過 BAC 與其他任何類似物件管理 ACL。此限制專門用於 Windchill+ 部署。
• LoadFromFile 有明確的限制。該功能僅支援不超過特定大小臨界值的 CCD 封裝。
開發與組態最佳作法
• 所有專案都必須從使用「類型及屬性管理員」公用程式進行的資料建模活動開始。
• 資料建模是指定義物件類型與屬性策略。在您的開發環境中，開發資料模型並使用自動化部署將其發佈至整合環境。
• 您必須先驗證所有 CCD 封裝，才能將其提交至自動化建構服務。建議您設定兩個開發環境：
◦ 實行變更的來源開發環境。
◦ 用於測試是否可以部署 CCD 封裝的目標開發環境。如需詳細資訊，請參閱 Targets 中的部署目標部份。
在此前後關聯中，目標主題特指用於構建與組態目的的 CCD ANT 目標。它不是指 INT (整合)、QA、PROD (生產) 等部署環境，亦不牽涉任何關聯的管線目標。
• 針對組態管理，您必須在每次成功完成功能接受度測試 (FAT) 之後建立 BAC 封裝。客戶與合作夥伴必須計劃將這些封裝儲存在您的原始程式碼管理系統 (SCM) 中。BAC 封裝包括資料模型，可作為新程式設計師加入或重新整理本機開發環境的起點。
• BAC 封裝可供在整合環境中使用之後，程式設計師即可從 UI 執行微小調整。
• 所有開發都必須在本機開發環境中完成，例如本機虛擬機器或雲端入口網站。
• 必須在開發環境中使用 CCD 進行準備、建構及部署。
• PTC 不建議在您的開發環境中管理個別容器組態；例如，產品或專案。
• 某些容器的建立可能是為了建立容器範本。
• 在 QA 與生產環境中小心使用容器層級組態。
企業管理員角色摘要
 |
PTC 建議指派給企業管理員角色的使用者不要是權限較低之其他任何使用者群組的成員。
|
企業管理員使用者群組會授與您更高權限，可讓您直接在生產環境中進行變更。這些功能可讓您直接存取以檢視和更新企業組態 (包括類型定義、屬性結構與分類)，但是它們也承擔著重要的營運責任。若變更不當或不協調，可能會中斷使用中的工作流程、影響資料完整性或損害業務過程連續性。
我們強烈建議客戶建立內部管控實作，包括變更管理協定、在非生產環境中進行測試，以及管理員培訓。此功能旨在酌情減少對平台管線的依賴，但不會消除有關驗證和問責制的最佳作法。必須謹慎平衡業務敏捷性與平台穩定性。
由該功能所引發之系統中斷將被視為客戶責任，不屬於 SLA 所保障之中斷情形，亦不計入 99.5% 正常運作時間保證之範圍。