研发版本与发布管理要解决的是“这次到底发什么、能不能发、发完怎么确认”的问题。可按版本立项、范围冻结、集成验证、发布评审、上线观察、复盘归档六个环节推进，每个环节留下对应记录，并把版本、发布单、变更、缺陷和验证证据关联起来，让每次发布都可追溯。下面给出流程表、角色分工、字段设计、执行示例和检查清单。
要点总览（TL;DR）
- 研发版本与发布管理按版本立项、范围冻结、集成验证、发布评审、上线观察、复盘归档六个环节推进，每个环节都要有明确输出和完成标志。
- 范围冻结是流程分水岭：冻结后的每次调整都要走变更申请与审批，并评估对测试范围、发布时间和回滚方案的影响。
- 版本号按大版本、迭代版本、修复版本分类命名；发布单必填版本号、范围、关联变更、验证结论、发布时间、执行人、回滚方案和批准人。
- 发布前按清单核对代码合入、配置差异、数据库变更、依赖权限、回滚预案与通知对象，阻断项未清零不发布；上线后设观察窗口判断继续放量或回退。
- 流程是否落地看记录：发布单字段完整、变更均有审批、回滚有复盘、版本与需求缺陷关联可查。
一个版本从立项到上线要走哪几步
六个环节的顺序不宜颠倒：立项确定“做什么、谁负责”，冻结确定“做到哪里为止”，集成验证回答“是否具备发布条件”，发布评审决定“是否放行”，上线观察判断“是否稳定”，复盘归档把经验沉淀下来。每个环节都要有明确输出和完成标志，否则流程容易停在口头确认。
| 环节 | 输入 | 关键动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 版本立项 | 业务目标、需求池、上一版本遗留问题 | 确定版本号、版本目标、范围清单和版本负责人；约定测试通过标准与发布窗口 | 版本立项记录、范围初稿、责任人名单 | 版本号已分配，目标与范围经相关方确认 |
| 范围冻结 | 范围初稿、开发进度评估 | 设定冻结时点；冻结后新增或调整需求必须走变更申请与审批 | 冻结版范围清单、变更申请记录 | 冻结时点到达且范围清单定版，后续调整均有审批记录 |
| 集成验证 | 合入的代码、构建配置、测试用例 | 统一构建形成候选产物；执行功能、回归与必要的非功能测试；记录测试结论 | 发布候选版本、测试报告、遗留缺陷清单 | 测试通过标准达成，遗留缺陷已评估并明确处理方式 |
| 发布评审 | 发布候选、测试报告、变更清单、回滚预案 | 按清单核对代码合入、配置差异、数据库变更、依赖与权限、通知对象；确认阻断项是否清零 | 评审结论、发布单、上线通知 | 评审通过并明确批准人，阻断项全部关闭或有书面豁免 |
| 上线与观察 | 发布单、执行步骤、监控看板 | 按步骤执行发布；上线后验证核心功能，在观察窗口内跟踪既定指标 | 发布执行记录、观察记录、问题登记 | 观察窗口结束且指标正常，或已按预案回退并记录 |
| 复盘归档 | 发布单、问题记录、监控数据 | 归档发布记录；复盘延期、缺陷、回滚等事件并形成改进事项 | 复盘纪要、改进任务、归档记录 | 改进事项已指派责任人与期限，版本状态关闭 |
范围冻结是整条流程的分水岭。冻结前可以讨论范围取舍，冻结后每一次调整都要评估对测试、发布时间和回滚方案的影响，并把评估结论写进变更记录。冻结时点建议与测试开始时间对齐，给验证留出足够窗口。
版本与发布各由谁负责，交付哪些记录
职责悬空最常见的表现是：版本延期找不到决策人，发布出问题找不到执行人，复盘时拿不出验证证据。解决办法是把每个环节的负责人和交付物写清楚，并区分“批准”和“知会”两类动作。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 版本负责人 | 对版本目标、范围、进度和整体质量负责；组织立项与冻结；牵头发布评审；决定是否按预案回退 | 版本立项记录、冻结范围清单、评审结论 |
| 研发人员 | 按范围交付代码与配置；提交合入申请；修复缺陷；提供变更影响说明 | 代码合入记录、变更说明、缺陷修复记录 |
| 测试人员 | 执行测试并给出通过结论；维护遗留缺陷清单；确认回归范围 | 测试报告、缺陷清单、验证结论 |
| 运维/发布执行人 | 准备发布环境与执行步骤；执行上线操作；维护回滚预案；发布中上报异常 | 发布单执行记录、回滚预案、上线通知 |
| 产品与业务确认方 | 确认版本目标与范围；参与发布评审；上线后确认业务可用性 | 范围确认意见、验收结论 |
| 跨团队协调角色 | 当版本涉及多个团队时，统一收集各团队的交付状态、依赖和风险，向版本负责人汇报 | 依赖清单、风险跟踪记录 |
审批与知会要分开：发布批准权应集中在版本负责人或由其授权的评审组，避免多人都有否决权导致无法决策；知会对象包括客服、业务运营、值班人员等，他们需要知道发布时间、影响范围和异常反馈渠道，但不参与放行决策。回滚预案的归属人是发布执行人，版本负责人负责确认预案可执行并决定是否启用。
版本号、发布单与状态字段怎么设计
字段设计的目的是让版本和发布可检索、可追溯。版本号建议采用“主版本.迭代号.修复号”的形式，并按类型区分：大版本承载结构性变化，迭代版本承载常规需求交付，修复版本只处理缺陷与紧急问题。修复版本应基于已发布版本拉出，避免夹带新需求。
| 对象 | 必填字段 | 说明 |
|---|---|---|
| 版本 | 版本号、版本类型、版本目标、范围清单、版本负责人、计划发布时间、状态 | 范围清单以需求条目形式列出，便于后续关联缺陷与变更 |
| 发布单 | 版本号、发布范围、关联变更、验证结论、计划发布时间、执行人、回滚方案、批准人 | 验证结论引用测试报告；关联变更列出冻结后所有调整 |
| 变更单 | 变更内容、提出人、影响评估、审批人、审批结论 | 影响评估需覆盖测试范围与发布时间 |
版本状态建议设为：规划中、开发中、待发布、已发布、已回滚、已关闭。状态流转要留痕，记录每次变更的时间与操作人。版本与需求、缺陷、构建产物的关联方式有两种常见做法：一是在需求与缺陷上标注所属版本，二是由版本条目反向聚合。两种方式可以并用，关键是任一版本都能查到它包含的需求、修复的缺陷和对应的构建产物。
一个迭代版本从冻结到上线的示例
以下为演示情景，用于说明流程如何跑通。某团队计划发布迭代版本 2.4.0，范围包含订单查询优化和两项后台配置调整，冻结时点为 3 月 10 日，计划 3 月 20 日晚发布。
3 月 12 日测试发现订单查询在特定筛选条件下超时，属于影响核心功能的紧急缺陷。团队提交变更申请，说明修复涉及查询索引调整和一次数据库变更，影响测试范围为订单模块回归，发布时间不变。版本负责人审批通过，测试补充回归用例，变更记录关联到发布单。
3 月 19 日发布评审会核对：代码已全部合入候选分支；配置差异两项均已确认；数据库变更脚本已在预发环境执行验证；依赖与权限无新增；回滚方案为回退应用版本并保留索引变更（索引变更对旧版本兼容）；通知对象包括客服与值班群。评审结论为通过，批准人为版本负责人。
3 月 20 日晚执行发布，上线后 30 分钟内验证订单查询、后台配置读写和登录等核心功能，观察窗口设为 2 小时，跟踪错误率与接口响应时间。观察期内指标正常，发布单标记为已发布。3 月 22 日复盘，记录本次紧急缺陷的发现时点与修复耗时，形成“冻结前增加筛选条件压测”的改进事项并指派责任人。
发布前检查与上线后确认清单
清单的价值在于把“大家觉得没问题”变成“逐项有结论”。建议把检查项分为发布前、发布中、发布后三段，并事先约定阻断项。
- 发布前：代码是否全部合入候选分支并有合入记录；配置差异是否逐项列出并确认；数据库变更是否已评审并在预发验证；新增依赖与权限是否已开通；回滚预案是否可执行、回滚步骤是否演练或核对；通知对象是否覆盖客服、业务与值班人员；测试报告与遗留缺陷处理结论是否齐备。
- 发布中：按发布单步骤逐项执行并记录时间；每个关键步骤后执行验证点；出现异常按上报路径通知版本负责人与发布执行人，由版本负责人决定继续、暂停或回退。
- 发布后：验证核心功能可用；在观察窗口内跟踪既定监控指标；登记发现的问题并标注是否阻断；观察窗口结束后给出继续放量或维持现状的结论。
阻断项建议至少包括：核心功能测试未通过、数据库变更未在预发验证、回滚方案缺失或不可执行、关键依赖未就绪。阻断项未清零时不应发布；确需带风险发布，应由版本负责人书面记录风险与应对措施，并明确知会范围。
怎么判断这套管理已经跑起来了
流程是否落地，看记录而不是看制度文件。可以用下面几项做定期自查，每项都能从记录中直接核验。
| 自查项 | 判定标准 |
|---|---|
| 发布单完整性 | 抽查近三个版本，每个版本都有发布单，必填字段无空缺 |
| 变更审批 | 冻结后的范围调整均能找到变更申请与审批记录 |
| 发布异常处理 | 发布失败或回滚均有记录，并在约定时间内完成复盘 |
| 关联可查 | 任一版本能查到包含的需求、修复的缺陷和对应构建产物 |
| 观察窗口执行 | 上线后有观察记录，指标与结论可查 |
如果抽查中发现发布单字段缺失、变更无审批或复盘长期未做，说明流程仍停留在形式阶段，应优先补齐记录再谈优化。自查频率可按版本节奏安排，例如每个大版本结束后做一次抽查。
用ONES承载版本与发布记录
上述流程产生的记录分散在文档、聊天和表格里时，追溯成本会明显上升。ONES 可以将版本作为工作项聚合需求、缺陷与任务，让版本范围在系统内直接可见；发布单与变更、验证结论可以关联记录，状态流转与审批过程留痕，便于回答“这个版本改了什么、谁批准的、验证结论是什么”；发布后形成的复盘事项也能作为工作项继续跟踪到关闭。对于需要跨团队协调的版本，各团队的交付状态和依赖关系可以在同一处汇总，减少反复对齐。具体字段配置与审批流程需结合团队实际流程在工具中设置。
常见问题
版本范围冻结之后，业务方坚持要加一个需求，应该怎么处理？
先评估再决定，不要直接口头答应或拒绝。让提出方提交变更申请，写清需求内容、期望上线时间；由研发评估改动量和对已测功能的影响，由测试评估回归范围，由发布执行人评估是否影响回滚方案。版本负责人根据评估结论决定纳入本版本、顺延到下个版本或拒绝，并把结论和理由写进变更记录。若纳入本版本，发布单的关联变更字段要同步更新，测试补充对应回归用例。
小团队人少、角色重叠，还需要把六个环节都走一遍吗？
环节可以合并执行，记录不能省。小团队常见做法是版本负责人同时承担发布执行人，产品确认方由业务负责人兼任，立项与冻结在同一次会议完成。需要保留的最小记录是：版本号与范围清单、冻结后的变更审批、测试通过结论、发布单（含回滚方案与批准人）、上线后的观察结论。这些记录保证出问题时能回答“发了什么、谁批准的、怎么回退”，与团队规模无关。
什么情况下可以带风险发布？
阻断项未清零时原则上不发布。确因业务时点等原因需要带风险发布，应由版本负责人书面记录风险内容、影响范围、应对措施和知会对象，并明确一旦触发问题由谁决策回退。常见可评估放行的情况包括：遗留缺陷仅影响非核心路径且有临时规避手段、数据库变更已在预发验证但数据量级差异较大。核心功能测试未通过、回滚方案不可执行这两类情况不建议放行。
发布后观察窗口设多长，看哪些指标？
观察窗口长度按系统影响面确定，常见做法是核心交易类系统设 1 至 2 小时并覆盖一个业务高峰，内部系统可缩短。指标在发布评审前就应约定，通常包括错误率、接口响应时间、核心功能成功率，以及与本次变更直接相关的业务指标。观察期内出现指标异常，按上报路径通知版本负责人，由其决定继续观察、暂停放量或回退；观察结束后的结论要写进发布单，作为版本关闭的依据。
版本记录分散在文档和聊天里，怎么低成本做到可追溯？
先把关联关系固定下来：每个版本有唯一版本号，需求、缺陷、变更单、发布单都标注所属版本号，构建产物记录对应的版本号与提交信息。这样即使记录分散，也能按版本号检索聚合。进一步的做法是把版本作为工作项放在研发管理工具中，让需求、缺陷、变更和发布单直接挂在版本下，状态流转与审批过程自动留痕。ONES 支持将版本作为工作项聚合需求、缺陷与任务，并关联发布单与验证结论，具体字段与审批配置需结合团队流程设置。
