构建结果确认要回答的问题很具体：这次构建到底能不能用。做法是把“流水线跑完了”拆成可逐项判定的内容，事先约定通过、带风险通过和阻断的口径，明确谁触发、谁判定、谁复核、谁放行，并把结论与证据记录到可追溯的位置。本文给出判定项清单、操作步骤、角色分工、填写示例和验收清单，并说明这类记录如何借助 ONES 与需求、任务、缺陷衔接。
要点总览（TL;DR）
- 构建结果确认的核心是把“流水线跑完了”变成“这次构建是否可用”的判定，需要事先约定编译、测试、静态检查、制品产出、冒烟验证五类判定项的通过、带风险通过与阻断口径。
- 操作流程分五步：约定触发条件与构建范围、执行并采集证据、按判定表出结论、失败处置与复跑、结论交接下游，每步都要有输入、动作、输出和完成标志。
- 角色至少区分提交者、流水线维护者、构建判定人、复核与放行人四类，判定人与复核人分离，带风险通过必须经过二次确认。
- 失败处置要防止“多跑几次直到绿”，复跑条件事先约定，复跑前后的结论都保留记录，阻断项跟踪到关闭。
- 机制是否有效看日常执行：判定口径被实际引用、每次构建有结论和证据、阻断项全部关闭、结论可追溯到需求或发布。
构建结果确认要判定哪些内容
构建结果确认的判定对象应当覆盖从代码变成可交付产物、再到可被下游使用的完整链路。判定项不宜过多，但每一类都要有明确的判定依据和结论取值，否则每次构建都要临时解释，结论无法比较，也无法追责。
建议把判定项分为五类，并为每类预设“通过、带风险通过、阻断”三种结论的适用条件。判定口径需要在团队内书面化，并在流水线配置和评审中引用，形成“规则先于构建”的秩序。
| 判定项 | 判定依据 | 通过 | 带风险通过 | 阻断 |
|---|---|---|---|---|
| 编译与打包 | 编译日志、打包产物是否生成 | 全模块编译成功，产物完整生成 | 非核心模块编译告警，产物可用 | 编译失败或产物缺失 |
| 自动化测试 | 单元测试、接口测试报告 | 用例全部通过，无跳过项异常 | 失败用例经确认与本次变更无关且有跟踪单 | 核心用例失败或失败原因未定位 |
| 静态检查与质量门禁 | 静态扫描报告、门禁规则结果 | 无新增严重问题，门禁通过 | 有新增一般告警且已登记处理计划 | 新增严重问题或门禁规则不通过 |
| 制品产出与版本标识 | 制品仓库记录、版本号与提交号 | 制品入库，版本号与提交一一对应 | 制品入库但标识需人工补充说明 | 制品未入库或版本标识缺失、错乱 |
| 必要环境下的冒烟验证 | 冒烟用例执行记录、环境日志 | 关键路径冒烟全部通过 | 非关键路径冒烟异常且有替代验证 | 关键路径冒烟失败或环境不可用 |
三种结论的边界要写清楚。“带风险通过”不是模糊地带，它要求风险已被识别、有明确复核人、有跟踪去向；“阻断”则意味着构建结果不能进入下游，必须先处置。判定项清单的交付物就是这张表：判定项、判定依据、结论取值，三者缺一不可。
从触发到放行的操作步骤
确认流程按五个步骤推进，每一步都要有输入、动作、输出和完成标志，避免“跑完就算完”。下表可直接作为团队的操作步骤表使用。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 一、约定触发条件与构建范围 | 分支策略、变更内容、判定表 | 提交者确认本次变更涉及哪些模块，按约定触发对应流水线；明确本次构建覆盖的范围 | 构建触发记录，含分支、提交号、构建范围 | 构建已触发且范围与变更一致 |
| 二、执行并采集证据 | 触发的流水线任务 | 流水线执行编译、测试、静态检查、制品打包；同步收集日志、测试报告、扫描报告、制品信息 | 完整证据集，与构建标识绑定 | 所有判定项都有对应证据，无缺失 |
| 三、按判定表给出结论并记录 | 证据集、判定表 | 逐项对照判定依据给出通过、带风险通过或阻断，写明理由 | 构建结果确认记录 | 每个判定项都有结论和理由，判定人已署名 |
| 四、失败或带风险的处置与复跑 | 阻断项或带风险项清单 | 为失败项建处置任务，定位原因、修复、约定复跑条件；复跑后更新结论 | 处置任务与更新后的确认记录 | 阻断项全部关闭，复跑结论已更新 |
| 五、结论交接给下游 | 确认记录 | 将结论与证据交接给测试、发布或需求负责人，关联到对应工作项 | 下游可查的结论与关联关系 | 下游已确认接收，关联关系可追溯 |
第三步是关键分界：证据齐备不等于结论成立，判定人必须逐项对照判定表，而不是看整体日志“感觉没问题”。第四步要防止复跑变成“多跑几次直到绿”，复跑条件应事先约定，例如修复提交后重新触发、或环境恢复后重跑冒烟，复跑结果同样要记录，保留前后对比。
角色分工与各自交付物
确认责任悬空通常源于角色不清：有人触发、没人判定，或者判定之后没人复核。建议至少区分四类角色，并为每类角色约定交付物和交接时点。
| 角色 | 职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 提交者 | 保证本地自检通过，提交信息完整，说明变更范围与影响 | 提交记录、变更说明、本地自检结果 | 提交时 |
| 流水线维护者 | 保证判定规则与执行环境稳定，判定表变更时同步更新流水线配置 | 可用的流水线配置、判定规则版本 | 规则变更时、环境异常时 |
| 构建判定人/值班角色 | 按判定表逐项出结论，记录理由，标记阻断项与带风险项 | 构建结果确认记录 | 证据齐备后 |
| 复核与放行人 | 对阻断项处置结果和带风险通过做二次确认，决定是否放行下游 | 复核意见、放行结论 | 处置完成或下游使用前 |
角色可以一人多岗，但职责不能合并到无人承担。判定人与复核人分离，是为了让带风险通过的判断经过第二双眼睛；如果团队规模小，可以由同一人不同时点承担，但复核动作要留下记录。交接时点写清楚，能避免“构建跑完了但没人知道能不能用”的空档。
示例：一次带失败的构建如何确认
以下为演示情景，不对应真实客户案例。某次构建中，编译通过，单元测试部分失败，静态检查出现新增告警。按判定表逐项确认如下。
| 判定项 | 证据 | 结论 | 理由 |
|---|---|---|---|
| 编译与打包 | 编译日志、产物清单 | 通过 | 全模块编译成功，产物完整 |
| 自动化测试 | 单元测试报告 | 阻断 | 3 个用例失败，其中 1 个属核心路径，原因尚未定位 |
| 静态检查与质量门禁 | 扫描报告 | 带风险通过 | 新增 2 条一般告警，已登记处理计划，无新增严重问题 |
| 制品产出与版本标识 | 制品仓库记录 | 通过 | 制品已入库，版本号与提交号对应 |
| 冒烟验证 | 冒烟执行记录 | 未执行 | 因测试阻断，暂不进入冒烟环节 |
处置动作：为失败的 3 个用例建立处置任务，先定位核心路径失败原因；修复提交后按约定条件复跑，复跑范围覆盖失败用例及关联模块；静态检查的 2 条告警指定处理人并约定关闭时间。复跑通过后，更新确认记录：自动化测试由阻断改为通过，冒烟验证补执行并给出结论，带风险通过项由复核人确认后放行。
记录与交接：确认记录中保留首次构建与复跑构建两个标识，写明每次结论、证据链接、判定人和时间；结论关联到对应需求与任务，失败用例的处置任务跟踪到关闭，下游测试与发布负责人从记录中直接看到最终结论。
确认记录放在哪里并如何衔接协作
确认记录的价值在于可追溯：任何人拿到一个构建标识，都能看到判定项结论、证据、判定人和时间，而不是只有一堆日志。记录字段建议如下。
| 字段 | 内容要求 |
|---|---|
| 构建标识 | 分支、提交号、构建编号、触发时间 |
| 判定项结论 | 逐项列出通过、带风险通过或阻断，附理由 |
| 证据链接 | 日志、测试报告、扫描报告、制品记录的存放位置 |
| 判定人与时间 | 判定人、复核人、各自确认时间 |
| 关联工作项 | 对应需求、任务、缺陷的编号与状态 |
记录与工作项的关联方式决定协作效率：构建结论应挂到本次变更对应的需求或任务上，失败项直接转为缺陷或处置任务并跟踪到关闭，下游测试与发布从同一处获取结论。这样构建结果确认就不只是流水线里的一个状态，而是研发协作中的一条可查记录。
ONES 可在这一环节承担记录与流转的承载：集成 Jenkins、GitLab CI 等第三方流水线工具后，ONES 会自动同步编排的流水线数据，更新执行状态和日志；流水线与项目关联后，可在项目、迭代、需求中可视化代码提交、流水线构建、产品发布等 CI/CD 过程。团队可以把构建结论与证据记录在对应工作项下，通过业务需求、研发任务等工作项拉取代码分支，并通过代码提交与工作项关联，使构建结果与需求交付进度对应起来；失败项则可借助缺陷管理与处置任务跟踪到关闭。具体字段形态与关联操作需按实际开通的模块核验。
完成检查：这套机制是否真的跑起来了
机制是否有效，不看文档写得多完整，而看日常构建是否真的按它执行。以下清单可逐项核对，任一项长期不满足，说明确认机制存在缺口。
- 判定口径已书面化，且在构建评审或流水线配置中被实际引用，而非只存在于文档库。
- 每次构建都有明确结论和对应证据，能回答“这次构建是否可用”，而不是只有日志可看。
- 所有阻断项都有处置任务，且已跟踪到关闭，没有长期挂起的阻断结论。
- 带风险通过项都有明确复核人，风险有跟踪去向，不是口头默认放行。
- 构建结论能追溯到对应需求或发布，下游使用结论时无需再向判定人单独询问。
- 复跑有约定条件，复跑前后的结论都有记录，能看出变化原因。
建议按固定周期抽查若干次构建记录，核对上述条目；发现判定项缺失或结论与证据不符时，先修订判定表，再同步调整流水线与角色分工，让规则、执行和记录保持一致。
常见问题
团队规模小，判定人和复核人可以是同一个人吗？
可以一人多岗，但复核动作要在不同时点留下记录。常见做法是判定人在证据齐备后出结论，复核人在处置完成或下游使用前再做一次确认，两次动作分别署名和时间。这样既适应小团队的人力现实，也保留了带风险通过经过第二双眼睛的证据。如果长期由同一人在同一时点完成判定和放行，带风险通过的判断就缺少制衡，建议至少对阻断项和带风险项保留独立复核。
复跑几次算合理，怎么避免“跑到绿为止”？
复跑条件应在判定表中事先约定，常见的有两类：修复提交后重新触发，或环境恢复后重跑对应环节。复跑范围覆盖失败项及关联模块，不必整条流水线全量重跑。每次复跑都保留构建标识和结论，能看出前后变化的原因。如果同一失败项在未做任何修复的情况下反复复跑，说明问题在环境或用例稳定性，应转为处置任务定位，而不是继续消耗构建次数。
带风险通过的结论，下游可以直接使用吗？
可以进入下游，但前提是风险已被识别、有明确复核人、有跟踪去向。判定人在记录中写明风险内容和影响范围，复核人确认后放行，风险项转为待办并约定关闭时间。下游测试或发布负责人从确认记录中看到带风险通过的标记和跟踪单，据此决定是否加做验证。缺少复核人或跟踪去向的带风险通过，应按阻断处理。
构建结论和需求、缺陷的关联，在工具里怎么落地？
常见做法是把确认记录挂到本次变更对应的需求或任务下，失败项直接转为缺陷或处置任务并跟踪到关闭，下游从同一处获取结论。ONES 集成 Jenkins、GitLab CI 等第三方流水线工具后，会自动同步编排的流水线数据，更新执行状态和日志；流水线与项目关联后，可在项目、迭代、需求中可视化代码提交、流水线构建、产品发布等 CI/CD 过程。团队可通过业务需求、研发任务等工作项拉取代码分支，并通过代码提交与工作项关联，使构建结果与需求交付进度对应。具体字段形态与关联操作需按实际开通的模块核验。
判定表定下来之后，多久需要修订一次？
没有固定周期，按触发条件修订更实际：新增判定项或门禁规则、阻断与带风险通过的边界在实际执行中反复出现争议、抽查发现结论与证据不符、流水线或环境发生较大变化时，都应修订判定表。修订后同步调整流水线配置和角色分工，并在团队内说明变化点。建议按固定周期抽查若干次构建记录，把发现的判定项缺失或口径模糊积累起来，集中修订，避免判定表频繁变动导致执行不稳定。
