构建结果报告模板以一次构建为一行，先回答三个问题：这次构建能不能用、失败卡在哪一步、由谁跟进。下面先给一份可直接复制到文档或表格的空白模板，再逐字段说明填写口径、列出必填与选填清单，并用一次失败构建的完整示例演示如何填写，最后说明模板随流水线变化时的调整与维护规则。
要点总览（TL;DR）
- 模板以一次构建为一行，按“标识—执行—结果—产出—责任”排列字段，复制表头即可逐行填写。
- 最小可用字段集覆盖构建编号、代码版本、分支、触发方式、构建环境、开始时间、构建状态、失败阶段、失败原因分类、负责人、后续动作和关闭状态。
- 失败阶段回答“卡在哪”，失败原因分类回答“为什么”，两者分开填写，统计时才能区分流程瓶颈与代码质量问题。
- 示例演示一次在单元测试阶段失败的构建：失败阶段填“单元测试”，原因分类选“用例不通过”，后续动作写明修复、重新构建和缺陷单关联。
- 模板需随流水线变化调整，枚举值集中维护，模板保留版本号与变更记录，并与构建记录、缺陷跟踪保持衔接。
可复制空白构建结果报告模板
模板采用单行主表结构：一次构建占一行，横向排列字段。复制时保留表头，按实际构建逐行追加。字段顺序按“标识—执行—结果—产出—责任”排列，便于从左到右阅读时先定位构建，再判断结果，最后确认跟进人。
| 构建编号 | 代码版本 | 分支 | 触发方式 | 构建环境 | 开始时间 | 结束时间 | 耗时 | 构建状态 | 失败阶段 | 失败原因分类 | 产物名称 | 产物版本号 | 用例结果 | 质量门禁结果 | 负责人 | 后续动作 | 关闭状态 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
如果团队使用表格工具，可将上表直接粘贴为表头行加一行空行；如果使用文档工具，可把表头转为固定格式的字段清单，每次构建复制一份填写。字段较多时，建议把“构建编号”到“构建状态”放在左侧固定列，把“失败阶段”之后的字段作为右侧补充区，避免横向滚动过长。
字段说明：每个字段记录什么、怎么填
同一份模板由不同人填写时，差异通常出在口径上，而不是字段缺失。下面按五类字段说明含义与填写方式，团队可据此统一写法。
构建标识类字段
| 字段 | 记录什么 | 填写口径 |
|---|---|---|
| 构建编号 | 本次构建的唯一标识 | 优先使用流水线系统生成的编号；手工记录时采用“日期＋当日序号”，如 20240612-03，保证全表不重复 |
| 代码版本 | 本次构建对应的提交标识 | 填写提交哈希的短格式或完整格式，团队内统一一种；同时构建多个仓库时，按“仓库名：提交号”分行列出 |
| 分支 | 代码来源分支 | 填写分支全名，如 feature/payment-retry；临时分支注明来源分支，便于回溯 |
执行类字段
| 字段 | 记录什么 | 填写口径 |
|---|---|---|
| 触发方式 | 构建由什么引起 | 使用固定枚举：代码提交、合并请求、定时任务、手动触发、上游构建触发 |
| 构建环境 | 构建运行的环境 | 填写环境名称与用途，如“测试环境-共享构建机”；同一环境有多套配置时补充配置标识 |
| 开始时间、结束时间 | 构建起止时刻 | 统一时区并注明，精确到分钟；跨天构建保留完整日期 |
| 耗时 | 构建总时长 | 由起止时间计算，单位统一为分钟；用于观察构建时长变化时保留一位小数 |
结果类字段
构建状态使用有限枚举：成功、失败、中止、未执行完成。失败阶段填写构建流程中实际中断的环节，如依赖安装、编译、单元测试、集成测试、制品打包、部署到测试环境。失败原因分类用于统计，建议控制在十项以内，例如代码编译错误、依赖下载失败、用例不通过、环境或资源问题、配置错误、超时、人为中止。失败阶段回答“卡在哪”，失败原因分类回答“为什么”，两者分开填写，统计时才能区分流程瓶颈与代码质量问题。
产出类字段
产物名称填写构建输出的制品名，如服务包、镜像、安装包；产物版本号填写本次产出的版本标识，未产出制品时填“无”并说明中断位置。用例结果记录通过数、失败数与跳过数，如“通过 218，失败 3，跳过 5”；质量门禁结果记录门禁是否通过及未通过项，如“未通过：新增严重问题 1 个”。
责任类字段
负责人填写本次构建的跟进人，通常是提交人或当班构建维护人，需写到具体人名。后续动作写清下一步做什么，如“修复编译错误后重新触发”“联系环境管理员恢复构建机”“提交缺陷单并关联本构建”。关闭状态使用“待处理、处理中、已关闭”三档，已关闭时在后续动作中补充关闭依据，如“重新构建成功，编号 20240612-05”。
必填与选填：哪些字段不能空
最小可用字段集只需支撑三个判断：这次构建是什么、结果如何、谁跟进。字段不足会导致报告无法用于排查，字段过多则增加填写负担，团队可按流水线复杂度逐步扩展。
| 类别 | 字段 | 理由或适用场景 |
|---|---|---|
| 必填 | 构建编号、代码版本、分支 | 缺少任一项都无法定位到具体代码，回溯和复现无从谈起 |
| 必填 | 触发方式、构建环境 | 区分问题来自代码还是环境，是排查失败的第一分叉 |
| 必填 | 开始时间、构建状态 | 状态是报告的核心结论，时间用于排序和统计构建频率 |
| 必填 | 失败阶段、失败原因分类 | 构建失败时必填；成功构建可留空或填“不适用” |
| 必填 | 负责人、后续动作、关闭状态 | 保证每次失败构建都有明确跟进人和处理进展 |
| 选填 | 结束时间、耗时 | 构建仍在运行或中止时可能没有结束时间；关注构建时长趋势时建议填写 |
| 选填 | 产物名称、产物版本号 | 构建在打包前中断时无产物；需要追溯发布来源的团队建议填写 |
| 选填 | 用例结果、质量门禁结果 | 流水线包含自动化测试或门禁检查时填写；仅做编译打包的流水线可省略 |
增减字段的原则是：新增字段必须对应一个明确的判断或统计需求，例如需要按环境统计失败率时才单独拆出环境字段；删除字段前确认没有报表或复盘流程依赖它。流水线从单一编译扩展到包含测试与部署时，可先补用例结果和产物字段；引入多环境部署后，再考虑拆分部署阶段与部署结果。
填写示例：一次失败构建的完整报告
以下示例为演示情景，展示一次在单元测试阶段失败的构建如何填写完整报告，字段与前面的模板和说明一一对应。
| 字段 | 填写内容 |
|---|---|
| 构建编号 | 20240612-03 |
| 代码版本 | a1b2c3d |
| 分支 | feature/payment-retry |
| 触发方式 | 合并请求 |
| 构建环境 | 测试环境-共享构建机 |
| 开始时间 | 2024-06-12 14:02（北京时间） |
| 结束时间 | 2024-06-12 14:11（北京时间） |
| 耗时 | 9 分钟 |
| 构建状态 | 失败 |
| 失败阶段 | 单元测试 |
| 失败原因分类 | 用例不通过 |
| 产物名称 | 无 |
| 产物版本号 | 无 |
| 用例结果 | 通过 218，失败 3，跳过 5 |
| 质量门禁结果 | 未执行（构建在测试阶段中断） |
| 负责人 | 张明 |
| 后续动作 | 定位 3 个失败用例，确认为重试逻辑断言过期；修复后重新触发构建，并提交缺陷单关联本构建 |
| 关闭状态 | 处理中 |
这份示例中，失败阶段写“单元测试”而不是笼统写“测试失败”，失败原因分类选“用例不通过”而不是直接粘贴报错日志，日志放在构建系统里供追溯。后续动作写明了修复对象、重新构建和缺陷单关联三个动作，关闭状态保持“处理中”，待新构建成功后改为“已关闭”，并在后续动作中补充新的构建编号。
当构建结果需要与需求、缺陷和评审记录放在同一处查看时，可以把报告中的构建编号、负责人和后续动作同步到项目管理工具中。ONES DevOps 解决方案支持集成 Jenkins、GitLab CI 等第三方流水线工具，集成后自动同步流水线数据并更新执行状态和日志，并可在项目、迭代、需求中查看构建过程，便于把失败构建的跟进动作与工作项、缺陷记录关联起来。是否采用这种方式，取决于团队是否已在用 ONES 管理项目与缺陷。
调整与维护：让模板跟着流水线变化
模板的价值在于长期稳定可比。流水线、环境和质量要求变化时，模板应有明确的调整触发条件、评审责任和版本记录，避免字段随意增删导致历史数据无法对比。
字段增删的触发条件
- 流水线新增阶段（如新增集成测试或部署环节）时，补充对应的失败阶段枚举值，并评估是否需要新增结果字段。
- 引入新的构建环境或构建机类型时，扩展构建环境的填写口径，而不是新增重复字段。
- 质量门禁规则变化时，同步调整质量门禁结果的记录方式，保留门禁规则版本。
- 连续多个周期某字段全部为空或无人查看时，提交删除评审，确认无报表依赖后移除。
枚举值的维护方式
失败原因分类、触发方式、关闭状态等枚举值应集中维护在一处，模板、报表和复盘文档引用同一份清单。新增枚举值需说明适用场景，合并含义重叠的旧值时要保留映射关系，使历史数据仍可统计。建议每季度评审一次枚举值的使用分布，长期未出现的值考虑合并或删除。
模板版本与评审责任
模板本身应有版本号和变更记录，记录每次调整的字段、原因和生效日期。评审责任可落在构建维护人或工程效能负责人，调整前收集填写人和报表使用方的意见，调整后通知团队并更新示例。版本号可随模板文件命名，如“构建结果报告模板 v1.2”。
与构建记录、缺陷跟踪的衔接
报告模板是构建记录的摘要视图，详细日志、完整用例报告仍保留在流水线系统中，模板中通过构建编号建立引用。失败构建需要修复时，在缺陷跟踪中创建或关联缺陷单，并在后续动作中写明缺陷单编号；构建关闭时同时确认缺陷单状态，避免报告已关闭而问题仍未处理。团队可借助 ONES Wiki 的模板库一键创建制式化文档，把这份模板固化为团队统一格式，减少每次手工复制表头的成本。
常见问题
构建成功时，失败阶段和失败原因分类怎么填？
成功构建的失败阶段和失败原因分类可以留空，也可以统一填“不适用”。团队内选择一种写法并保持一致即可，关键是不要让成功行出现自由文本，否则按失败原因分类统计时会把成功构建混入。若模板用于报表，建议在表头说明中注明成功行的填写规则。
一次构建涉及多个仓库的提交，代码版本字段怎么写？
按“仓库名：提交号”分行列出，每个仓库一行，构建编号保持同一个。如果表格工具支持单元格内换行，可在一个单元格内分行；如果使用纯文本表格，可在代码版本字段后用分号分隔并保持仓库顺序固定。团队需统一提交号格式，短哈希或完整哈希选一种。
构建在运行中还没有结束，报告要不要先填？
可以先填。开始时间、构建状态填“未执行完成”，结束时间和耗时留空，负责人和后续动作按当前情况填写。构建结束后再补结束时间、耗时和最终状态。这样报告能反映在途构建，避免只记录已结束的构建而漏掉长时间卡住的执行。
失败原因分类的枚举值应该由谁维护？
建议由构建维护人或工程效能负责人集中维护，模板、报表和复盘文档引用同一份清单。新增枚举值需说明适用场景，合并含义重叠的旧值时保留映射关系，使历史数据仍可统计。每季度评审一次使用分布，长期未出现的值考虑合并或删除。
构建结果需要和缺陷单关联时，模板里怎么体现？
在后续动作中写明缺陷单编号，例如“提交缺陷单 BUG-1024 并关联本构建”。构建关闭时同时确认缺陷单状态，避免报告已关闭而问题仍未处理。如果团队使用 ONES 管理项目与缺陷，可将构建编号、负责人和后续动作同步到工作项中，把失败构建的跟进动作与需求、缺陷记录放在同一处查看。
