審查與自動化

持續性環境與 CI 審查

使用四步驟精靈建立共用的持續性環境、設定 CI 工作區設定檔、在五個 CI 索引標籤中審查合併事件，並從 Console 提升已驗證的候選項。

客戶管理員平台維運人員

最後更新 2026年6月18日

持續性環境與 CI 審查是 Console 擁有的共用驗證工作流程。當客戶需要長期存在的 QA、UAT、示範、預備或客戶審查執行階段，並希望變更在提升之前通過程式碼審查與 QA 時，請使用它們。

這些工作流程不同於個人開發者工作區。持續性環境是具有原則、計費、支援與事件歷程的共用客戶執行階段。CI 工作區設定檔是路由擁有的審查或 QA 執行階段設定檔，當合併事件需要瀏覽器、資料庫、程式碼智慧或目標環境檢查時，Console 會使用它。

這兩個介面都位於 Console 的左側導覽列中。Environments 擁有共用執行階段及其候選項；CI & Review 擁有路由、合併事件、執行以及供應商交接。兩者相互連結，因此你可以在環境與其審查歷程之間移動而不遺失上下文。

開始之前

• 你需要客戶管理員或平台維運人員角色才能建立環境與 CI 設定檔。
• 你打算驗證的儲存庫與分支必須可透過已連線的 Git 供應商存取。供應商連線請參閱 客戶管理員設定，資料庫種子請參閱 備份與還原來源。
• 決定路由是僅來源分支還是面向持續性環境，因為該選擇會改變執行哪些檢查。

建立持續性環境

開啟 Environments 並選取 Create environment。Console 會開啟一個四步驟精靈，頂部有步驟導覽列：Source、Runtime、Policy 與 Review。右側的即時啟動面板顯示目前選擇，並列出仍在封鎖的任何必要項。

1. Source。 選取客戶範圍、命名環境，並確認儲存庫 URL 與來源分支。Console 會在此處驗證供應商存取權。當變更相依於多個儲存庫時，啟用儲存庫堆疊，以便執行階段儲存庫與產品儲存庫按順序簽出。
2. Runtime。 選擇持續性環境設定檔、範本系列、工作區目標與執行階段大小。該設定檔設定 WebCentral 版本假設，包括後端工作區預期的 Java、Gradle、Tomcat 與授權套件。
3. Policy。 設定種子來源（資料庫備份）、公開範圍與資料庫遷移引擎。選擇與目標相符的遷移引擎：Flyway、ARCHIBUS DUW 或停用遷移。
4. Review。 確認啟動計畫。審查格線彙總設定檔、儲存庫模式、大小與資料庫備份。當所有必要項都齊備時，選取 Create environment。

建立開始後，Console 會建立環境記錄，並在所選目標支援時啟動後端工作區。然後環境卡片會顯示持續性工作區、候選版本與目前版本、環境更新狀態、執行階段捷徑以及事件歷程。

持續性環境旨在比個人開發工作區保持更長時間的開啟狀態。請審慎選擇執行階段大小與定價週期，並使用事件歷程確認後端工作區、Tomcat 路由、資料庫種子與提升狀態何時就緒。

請使用與來源儲存庫或 WAR 相符的 WebCentral 版本設定檔，尤其是對於需要 Tomcat 8.5 或 Tomcat 9 而非目前預設值的較舊 WebCentral 版本。有關這些設定檔如何對應到執行階段設定，請參閱 工作區預設集。

開啟環境執行階段捷徑

持續性工作區存在後，使用環境卡片動作：

請勿將原始記錄貼到支援工單中。而是分享可見狀態、執行 ID、工作區名稱、時間戳記與已清理的錯誤文字。

分兩個階段更新環境執行階段

當候選版本準備好落到持續性執行階段上時，Console 會使用審慎的兩階段更新，以免共用環境被意外重新啟動。

1. Request environment update。 這會核准對持續性工作區的更新並將其標記為已要求。Console 顯示更新已準備好開始，但尚未觸及執行中的環境。
2. Start environment update。 這會啟動持續性工作區更新並等待執行階段結果。Console 將狀態移至執行中，一旦持續性執行階段處於提升後的版本，則移至已套用。

環境卡片顯示目前更新狀態與每個階段的簡短描述，以及執行階段證據列，以便你確認發生了哪些變更。

建立 CI 工作區設定檔

開啟 CI & Review 並選取 Create CI profile（在頂部動作列中為 Create CI/profile）。Console 會開啟一個具有相同步驟導覽列形狀的四步驟精靈：Source、Runtime、Policy 與 Review，在工作區中顯示為 Source route、Workspace runtime、Run policy 與 Review and create。

1. Source route。 選取客戶、供應商、儲存庫、分支以及選擇性的目標環境。選取目標環境會在稍後開啟目標檢查。當變更需要執行階段儲存庫加上產品或相依性儲存庫時，套用儲存庫堆疊設定檔。
2. Workspace runtime。 選擇工作區形態：review、QA、review plus QA 或 destination QA。選取 CI 範本、工作區目標與大小。
3. Run policy。 設定保留、成品、執行哪些階段、QA 範圍與資料庫遷移引擎。選取 WebCentral 版本設定檔與資料庫備份。審查通常使用高推理；QA 通常在確定性檢查收集證據後使用低推理。
4. Review and create。 在審查格線中確認路由設定檔，然後選取 Create CI profile。

儲存 CI 工作區設定檔不會建立個人開發者工作區。它會建立 Console 在合併事件或測試執行需要審查或 QA 工作區時使用的路由中繼資料。當不需要瀏覽器、資料庫與程式碼智慧工具時，輕量級執行仍可使用 Console 執行器而無需工作區。

如果路由沒有目標持續性環境，Console 仍可執行來源分支 QA。程式碼審查從 Console 合併事件、供應商提取要求或明確的 diff 開始，以便審查人員看到實際的變更集與合併閘門。由於沒有要驗證的環境設定，因此略過目標環境檢查。

五個 CI & Review 索引標籤

CI & Review 工作區在主面板上方組織為五個索引標籤，每個索引標籤都有即時計數：

索引標籤上方有一個工作流程列，顯示所選合併事件的階段管線：Intake、Review、QA、Target QA 與 Merge。每個階段顯示其自身的狀態，例如 open、waiting、skipped 或 waiting on checks。

僅來源分支與目標環境

僅來源分支的路由在沒有所選持續性環境的情況下執行程式碼審查與執行器 QA。在該模式下，Console 刻意略過目標環境檢查，並且 Target QA 階段顯示為 skipped。

具有所選持續性環境的路由會新增目標環境檢查。在程式碼審查與執行器 QA 通過後，Console 會在合併或提升能夠繼續之前，針對所選環境預設值驗證候選項。

目標環境檢查使用在提升後重要的環境預設值，包括資料庫類型、資料庫備份、遷移引擎、工作區目標、範本、工具鏈、工作區參數以及設定時的授權覆寫。

當路由使用較舊的 WebCentral 版本時，請在持續性環境、來源 QA 設定檔與目標 QA 設定檔上保持相同的版本設定檔。這樣可使審查證據、瀏覽器冒煙測試與最終提升檢查在相同的執行階段假設下執行。

設定供應商交接

開啟 Provider handoff 索引標籤並載入一個路由，以註冊或檢查受管供應商連線。Console 擁有審查層；供應商連線使其能夠張貼審查與 QA 留言、傳送狀態意見回饋並接收合併事件。

在此索引標籤中，你可以：

• 儲存受管連線。 註冊供應商應用程式、服務掛勾或經核准的認證參考，例如 token://...、k8s://secret/key 或 OpenBao/Vault 參考。Console 也可以接受一次性供應商權杖或應用程式密碼，並將其儲存在 Console 權杖儲存體、Kubernetes Secret 或 OpenBao/Vault 中。儲存後，Console 僅顯示認證預覽。
• 輪替認證。 當權杖過期或被替換時使用 Rotate credential。之後執行連線檢查。
• 撤銷認證。 使用 Revoke credential 保留連線記錄但停止張貼，直到新增新的認證參考。
• 安裝或協調 webhook。 使用 Install webhook 使合併事件更新到達 Console，使用 Reconcile webhook 修復偏移的掛勾，使用 Remove webhook 停止事件。在安裝 webhook 之前儲存或選取路由。
• 檢查連線。 在依賴路由進行審查、狀態或留言張貼之前，使用 Check connection 確認健康狀況。

就緒面板會引導你瀏覽路由中繼資料、供應商服務、安裝目標、認證來源、允許的動作、Console 記錄與供應商健康狀況，以便你看到哪個步驟仍然缺少。

請勿將供應商權杖、原始認證酬載或私有部署機密放入路由名稱、描述、QA 備註或路由說明中。

審查合併事件

合併事件是 Console 中的一般審查單位。合併事件可以來自供應商 webhook、工作區交接或手動 Console 註冊。

1. 開啟 CI & Review。
2. 從 Merge events 索引標籤中選取合併事件。
3. 開啟 Review in Console，查看來源分支、目標分支、供應商連結、功能項、審查人員清單與堆疊的變更。
4. 指派審查人員或新增自訂審查人員，並更新審查人員備註。
5. 當路由就緒時，選取 Start review & QA。
6. 觀察工作流程列：Intake、Review、QA、Target QA 與 Merge。

當偵測到堆疊的變更時，Console 會顯示其可以安全展示的有界堆疊預覽與每個檔案的上下文。僅將供應商連結用於次要上下文。

Archibot 審查與執行器 QA 可以個別或一起執行。審查著重於程式碼、堆疊 diff 上下文、缺少的測試、有風險的路徑與文件影響。QA 著重於執行證據，例如瀏覽器冒煙、資料庫檢查、所選測試命令、工具鏈驗證與工作區記錄。有關 Archibot 審查與 QA 機器人如何設定，請參閱 Console Bots。

如果執行需要停止，請在 Evidence and logs 索引標籤中的執行上使用 Cancel run。Console 會將該執行標記為已取消。

合併與提升

Console 將人工合併保持為預設值。

在 Merge in Console 可用之前：

• 必須記錄審查人員核准。
• 要求的程式碼審查階段必須通過。
• 要求的執行器 QA 階段必須通過。
• 如果選取了目標環境，則目標環境檢查必須通過。

合併完成後，已驗證的候選項可以成為所選持續性環境的提升候選項。僅當最新的 CI 執行與目標環境檢查與候選版本相符時，才從 Environments 使用 Promote candidate。提升後，使用上述兩階段環境更新將其落到執行中的執行階段上。

記錄、證據與 Shared Drive

CI & Review 與 Environments 在 Console 中保留事件歷程。使用 Evidence and logs 索引標籤中的執行時間軸查看階段變更、作業名稱、目標環境狀態與已清理的記錄列。

當支援人員需要證據存續超過正常執行記錄保留時段時，使用 Save to Shared Drive。這需要帳戶擁有可寫入磁碟機。請保持長期存續的證據已清理並經客戶核准。有關範圍化磁碟機存取的運作方式，請參閱 工作區 Archibot 與 Shared Drive。

審查人員應能在合併之前從 Console 回答三個問題：

• 發生了哪些變更，包括任何堆疊的 diff？
• 執行了哪些審查、QA 與目標檢查？
• 如果稍後執行需要支援審查，已清理的證據在哪裡？

請勿共用：

• API 金鑰、供應商權杖、webhook 機密、cookie 或邀請連結。
• Kubernetes Secret、Pod 環境變數、kubeconfig 或 Coder 權杖。
• 原始資料庫 URL、原始備份內容或授權檔案。
• 私有對話記錄或客戶資料傾印。

常見封鎖因素

支援交接

為支援人員，請包含：

• 客戶帳戶與環境名稱。
• 合併事件 ID 或 CI 執行 ID。
• 來源分支、目標分支以及可見時的供應商合併要求編號。
• 被封鎖的階段。
• 已清理的 Console 錯誤或記錄摘要。

請勿包含原始認證、含機密的完整記錄、私有資料庫資料或一次性連結。完整的證據檢查清單請參閱 支援交接。