构建状态看板的价值在于让人一眼判断“现在能不能合并、哪条流水线出了问题、该找谁”。下面给出一张已填写的示例看板，按流水线、分支、提交、构建编号、阶段、状态、耗时、失败原因、负责人和更新时间组织字段，并说明状态口径、失败跟进方式以及迁移到其他团队或工具时需要保留的结构。示例为演示情景，数据不代表任何真实团队的构建结果。
要点总览（TL;DR）
- 示例看板用流水线、分支、提交、构建编号、阶段、状态、耗时、失败原因、负责人、更新时间十个字段，覆盖排队、运行中、成功、失败、取消、阻塞六种状态。
- 状态口径要先统一：阻塞与失败分开记录，环境问题不被误记为代码质量问题；失败率按失败次数除以总构建次数计算，取消和阻塞单独统计。
- 失败跟进靠三件事落地：失败原因按编译错误、测试失败、环境问题、依赖拉取失败分类，负责人按提交人、值班人、模块负责人约定，更新时间配合构建编号判断失败挂了多久。
- 迁移到其他团队或工具时保留状态口径、失败原因分类、责任归属和时间戳；字段数量、汇总指标和通知方式可按团队调整。
- 示例假设单团队、少量流水线、单一测试环境，多团队需增加分组维度，多环境需增加环境字段，构建量大时需聚合与筛选。
示例目标：这张看板要回答哪些问题
这张看板面向一个持续集成节奏较稳定的研发小组：每天有若干次代码合并触发构建，团队需要在不打开流水线工具逐个翻看的前提下，快速掌握构建健康度。示例假设团队使用一条主干分支加若干特性分支，流水线数量在十条以内，由提交人和值班人共同承担失败处理。这一设定仅用于演示，读者应按自己的分支策略和值班安排调整。
看板建成后，至少要能回答三个问题。第一，当前哪些构建处于失败或阻塞状态，失败发生在哪个阶段。第二，这次失败影响哪个分支、哪次提交，是否会阻断合并或发布。第三，谁在处理这次失败，处理到哪一步。三个问题对应三类字段：状态与阶段回答“是什么”，分支、提交与构建编号回答“影响哪里”，负责人与更新时间回答“谁在跟进”。
判断看板是否可用，可以对照以下最低标准：
- 状态口径统一：所有流水线使用同一套状态名称，排队、运行、成功、失败、取消、阻塞不会混用，也不会出现“差不多成功”这类模糊状态。
- 失败可定位：从看板的一行能追到具体构建编号和失败阶段，不需要再凭时间猜测是哪次构建。
- 责任可追溯：每个未解决的失败都有明确负责人和最近更新时间，超过约定时限未处理的失败能被识别出来。
这三条标准不依赖具体工具，用表格、看板视图或研发管理工具中的工作项列表都能实现。示例后续展示的字段和状态，就是围绕这三条标准展开的。
完整示例：一张已填写的构建状态看板
示例看板分为顶部汇总区和明细区。汇总区给出当天整体情况，明细区逐条列出构建记录。下表为字段定义，随后是已填写的示例数据。
| 字段 | 填写内容 | 示例值 |
|---|---|---|
| 流水线 | 流水线名称，与流水线工具中的命名一致 | web-app-ci |
| 分支 | 触发构建的分支 | feature/login |
| 提交 | 短提交哈希，必要时附提交说明 | a3f9c21 |
| 构建编号 | 流水线工具生成的唯一编号 | #1842 |
| 阶段 | 失败或当前所处的阶段 | 单元测试 |
| 状态 | 统一状态口径中的一个值 | 失败 |
| 耗时 | 本次构建从开始到结束的时长 | 6分12秒 |
| 失败原因 | 按分类填写的失败说明 | 测试失败：登录用例断言不通过 |
| 负责人 | 当前跟进人 | 提交人 李某 |
| 更新时间 | 状态最后一次变化的时间 | 今日 10:42 |
顶部汇总区示例：今日构建 28 次，失败 4 次，失败率约 14%，平均耗时 5 分 40 秒，待处理失败 2 个。失败率按“失败次数 ÷ 总构建次数”计算，取消和阻塞不计入失败次数，单独统计。这个口径需要在团队内写清楚，否则同一组数据会算出不同结果。
明细区示例数据如下：
| 流水线 | 分支 | 提交 | 构建编号 | 阶段 | 状态 | 耗时 | 失败原因 | 负责人 | 更新时间 |
|---|---|---|---|---|---|---|---|---|---|
| web-app-ci | main | b7d2e10 | #1846 | 构建 | 运行中 | 已进行 2分30秒 | — | 值班人 王某 | 今日 11:05 |
| web-app-ci | feature/login | a3f9c21 | #1842 | 单元测试 | 失败 | 6分12秒 | 测试失败：登录用例断言不通过 | 提交人 李某 | 今日 10:42 |
| web-app-ci | feature/pay | c1e8a44 | #1841 | 依赖安装 | 失败 | 1分05秒 | 依赖拉取失败：私有仓库超时 | 值班人 王某 | 今日 10:20 |
| api-service-ci | main | d9b3f07 | #0917 | 编译 | 成功 | 4分48秒 | — | 提交人 张某 | 今日 09:58 |
| api-service-ci | release/2.3 | e5a1b83 | #0916 | — | 排队 | — | — | 值班人 王某 | 今日 09:55 |
| web-app-ci | feature/search | f2c7d19 | #1839 | — | 取消 | 0分40秒 | 提交人手动取消，已被新提交取代 | 提交人 赵某 | 今日 09:31 |
| api-service-ci | main | a8e4c62 | #0914 | 集成测试 | 阻塞 | — | 环境问题：测试环境数据库不可用 | 值班人 王某 | 今日 09:12 |
这张表覆盖了运行中、失败、成功、排队、取消和阻塞六种状态，失败原因覆盖测试失败、依赖拉取失败和环境问题三类。读者可以把它当作模板，替换成自己流水线的真实字段后直接使用。
逐项解释：每个字段和状态为什么这样填
状态口径是看板最需要先统一的部分。示例中的判定条件如下：排队表示构建已触发但尚未分配到执行资源；运行中表示已开始执行且未结束；成功表示所有阶段按预期完成；失败表示某个阶段返回非零结果或断言不通过；取消表示人为中止或被新构建取代；阻塞表示构建无法继续推进，原因通常在执行环境或外部依赖，而非代码本身。阻塞与失败分开，是为了让环境问题不被误记为代码质量问题。
| 状态 | 判定条件 | 看板上的处理动作 |
|---|---|---|
| 排队 | 已触发，等待执行资源 | 观察等待时长，超时则检查执行机容量 |
| 运行中 | 已开始执行，未结束 | 无需处理，关注耗时是否异常 |
| 成功 | 全部阶段完成 | 归档，作为可合并依据 |
| 失败 | 阶段返回失败结果 | 填写失败原因，指定负责人跟进 |
| 取消 | 人为中止或被新构建取代 | 注明取消原因，避免误判为失败 |
| 阻塞 | 环境或外部依赖不可用 | 转交环境维护人，恢复后重新触发 |
失败原因字段的粒度以“能指导下一步动作”为准。示例把失败分为编译错误、测试失败、环境问题、依赖拉取失败四类，每类后面附一句具体说明。只写“构建失败”无法区分是改代码还是找运维；写得过细、贴整段日志，又会让看板难以扫读。较长的日志放在流水线工具里，看板保留分类和一句定位信息即可。
负责人字段按“谁最可能先动手”填写。特性分支的失败默认填提交人，主干和发布分支的失败默认填当日值班人，涉及公共模块时改填模块负责人。规则要提前约定，避免失败出现后无人认领。更新时间记录状态最后一次变化，配合构建编号可以判断这次失败已经挂了多久、是否被重复触发的新构建覆盖。
构建编号的作用常被低估。同一分支在一天内可能触发多次构建，只写分支名会让“失败的是哪一次”变得模糊。编号与提交哈希一起使用，既能定位到具体一次执行，也能回溯到对应代码变更。
可迁移规律：换团队或换工具时保留什么
换团队或换工具时，有四类内容应当保留：统一的状态口径、失败原因分类、责任归属规则和时间戳。它们决定了看板能否支撑判断，与使用哪种工具无关。可以按团队调整的是字段数量、汇总指标和通知方式。小团队可以去掉阶段字段，只保留状态和失败原因；构建频繁的团队可以增加“是否阻断合并”字段；通知可以从群消息改为每日汇总。
把看板字段映射到研发管理工具时，通常有两种承载方式。一种是把每次构建记录为一条工作项，流水线、分支、提交、构建编号作为字段，状态作为工作项状态，负责人作为处理人，失败原因写在描述或评论中。另一种是用文档或表格维护看板视图，适合构建量不大、以人工更新为主的团队。两种方式都需要保证状态值与流水线工具返回的结果一致，避免看板显示成功而流水线实际失败。
看板与流水线工具的分工需要说清楚：流水线负责执行构建、产出日志和结果，看板负责呈现状态、分配责任和记录跟进过程。看板不替代流水线执行，也不应成为第二套构建记录的唯一来源。ONES DevOps 解决方案在这方面的做法是集成 Jenkins、GitLab CI 等第三方流水线工具，自动同步流水线数据并更新执行状态和日志，同时把流水线与项目关联，在项目、迭代、需求中呈现代码提交、流水线构建和产品发布过程。对于希望把构建失败跟进与需求交付放在同一处管理的团队，这种关联可以让看板上的失败记录直接对应到相关工作项，减少在工具之间来回切换。具体字段映射方式需按团队已集成的工具和配置确定。
适用边界：示例在哪些情况下需要调整
示例假设单团队、少量流水线、单一测试环境的场景。多团队协作时，需要在看板中增加团队或项目分组维度，否则不同团队的构建混在一起，汇总指标会失去参考意义。多环境部署时，应增加环境字段，区分测试环境、预发环境和生产环境的构建，避免把环境问题记到代码提交上。
示例聚焦看板的字段、状态和跟进规则，不涉及具体流水线工具的安装配置与脚本编写。流水线如何定义阶段、如何设置触发条件，属于流水线工具自身的配置范围，读者应参考对应工具的文档。构建量较大时，逐条罗列会超出看板的可读范围，需要按流水线或分支聚合，配合筛选条件查看失败明细，并设置只展示未解决失败的默认视图。
最后需要说明，本文所有构建编号、提交哈希、耗时和失败率均为演示数据，用于说明填写方式，不代表任何真实团队的实际构建结果。读者在搭建自己的看板时，应以流水线工具返回的真实状态和日志为准，并根据团队的分支策略、值班安排和发布节奏调整字段与阈值。
常见问题
团队对某个构建的状态判断不一致时，看板该怎么处理？
先回到判定条件本身，确认分歧出在哪一步。常见情况是同一构建既有人记为失败、有人记为阻塞：如果失败发生在代码阶段（编译、测试断言），记为失败；如果卡在执行环境或外部依赖，记为阻塞。另一种情况是构建被新提交取代后自动中止，这类应记为取消并注明原因，不计入失败次数。
口径统一后，把判定条件写进看板的说明区或团队文档，新成员按同一份规则填写。若分歧反复出现，说明规则本身有歧义，需要补充边界案例，而不是每次临时裁定。
失败构建长时间无人认领，看板上如何暴露出来？
依靠负责人和更新时间两个字段配合。约定一个处理时限，例如主干失败当日处理、特性分支失败在下次合并前处理，然后用“状态为失败且更新时间超过时限”作为筛选条件，形成待认领列表。
负责人字段留空本身就是信号。示例中默认规则是特性分支填提交人、主干和发布分支填值班人，若出现留空，说明触发构建的提交没有对应到人，需要补充值班安排或调整默认规则。看板不负责自动催办，但可以让遗漏变得可见。
构建量变大以后，逐条罗列的看板还能用吗？
逐条罗列适合每天几十次构建的规模。构建量继续增长后，明细表会超出可扫读范围，需要改为两层结构：上层按流水线或分支聚合，展示失败数、待处理数和平均耗时；下层保留明细，默认只显示未解决的失败和阻塞记录，成功构建按需查询。
聚合维度的选择取决于团队关心什么。按分支聚合适合关注合并阻塞的团队，按流水线聚合适合关注某条流水线稳定性的团队。无论哪种，状态口径和失败原因分类都应保持不变，否则聚合结果无法横向比较。
把看板放进研发管理工具时，构建记录应该建成工作项还是文档表格？
取决于构建量和跟进方式。构建量不大、以人工更新为主时，文档或表格维护看板视图成本更低，改字段和加列都灵活。需要把失败跟进与需求、迭代关联，或者希望失败记录有处理人和状态流转时，把每次构建建成工作项更合适，负责人即处理人，状态即工作项状态，失败原因写在描述或评论中。
ONES 的做法是集成 Jenkins、GitLab CI 等第三方流水线工具，自动同步流水线数据并更新执行状态和日志，同时把流水线与项目关联，在项目、迭代、需求中呈现代码提交、流水线构建和产品发布过程。具体字段如何映射到工作项，需按团队已集成的工具和配置确定。
示例中的失败率和平均耗时可以直接拿来考核团队吗？
不建议直接使用。示例中的失败率口径是失败次数除以总构建次数，取消和阻塞不计入失败；平均耗时按单次构建从开始到结束计算。这两个指标反映的是构建运行情况，受提交频率、流水线配置和测试规模影响，单独拿出来比较不同团队意义有限。
如果用于改进讨论，应同时看失败原因分布和失败处理时长，判断问题集中在代码质量、测试稳定性还是环境。指标口径一旦确定就保持稳定，频繁调整会让历史数据失去可比性。
