选择 Taiga 在哪里等待决定

区分四个决定

虚构设备服务有四个不同决定：接受计划、执行构建、合并变更和部署。不要把一个开关当作对四项操作的全部授权。

改变自主运行设置前，检查合并后代码仓库流水线会执行什么。如果合并到工作分支会触发部署，自动合并也可能触发现有工作流。

决定计划是否等待

产品设置 Build on its own by default 控制完成的计划是继续构建，还是等待批准。如果计划需要先由人决定，就关闭该设置。

Initiative 的 Build on its own 设置，可以为单个 initiative 改变这一行为。排队工作前，检查默认值和任何单独选择。

Approve 以批准者身份启动构建，并受其当前权限限制。失败的计划不会启动构建。构建自动化本身，不授权合并产生的 pull request。

理解合并层级

自主合并单独控制，启用前保持关闭。文档说明的集成支持 GitHub，包括 GitHub Enterprise。

组织或工厂禁用的上限，不能在下层覆盖。产品默认关闭则不同：只要上限允许，initiative 可以单独启用合并。

对于设备服务，明确初始范围。在允许边界内，后果较轻的 initiative，可以与员工访问控制变更采用不同选择。

让必需审查得到落实

Taiga 会询问源代码管理提供方，pull request 是否可以合并。分支保护决定必需检查、审查和其他条件。自主合并不会绕过这些规则。

如果自动审查必须能阻止合并，就通过代码仓库支持的配置，将其结果设为必需状态检查。建议性结果不会因为你期望它必需，就自动成为强制条件。

也要检查必需的人工批准。通过的检查不能替代策略要求的批准。确认实际目标分支上的规则。

理解合并停止的原因

阅读 initiative 上的原因。检查待完成、缺少批准、冲突和计划未完成，需要不同处理。如果修复改变了让失败检查通过的判定标准，Taiga 也会停止自主合并。应直接审查这种变化。

不要仅因为必需检查阻碍进度，就移除它。如果检查一直不报告结果，应修正配置，或使用获授权的策略流程。每次修复后，检查当前提交。

单独保留部署授权

Taiga GitHub App 执行自主合并，并被记录为合并者。代码仓库流水线保留原有部署行为。

本场景中，合并会部署到预发布环境。生产环境仍需要组织的生产决定和证据。确认流水线落实了这一区分。继续学习交付审查。