审查与自动化

持久环境与 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 错误或日志摘要。

请勿包含原始凭据、含机密的完整日志、私有数据库数据或一次性链接。完整的证据清单请参阅 支持交接。