版本发布时间流程与规范：研发团队版本管理流程优化关键指标

版本发布时间表上写着“周四 20:00”，并不代表版本真的能在周四 20:00 安全发布。研发团队常见的失控场景是：代码已合并，测试仍在回归；产品还在确认变更范围；运维等不到回滚方案；业务却已经按原定时间通知客户。问题通常不在于缺少一个发布日期，而在于团队把“计划发布”“具备发布条件”和“发布完成”混成了同一个状态。优化版本发布时间流程，应该先定义可验证的放行条件，再用变更冻结时间、发布准点率、回滚率、发布后缺陷率等指标检验流程是否有效。

一、核心结论：发布日期不是流程，放行条件才是流程

1. 先把“发布时间”拆成四个时点

我通常不会让团队只填写一个“发布时间”。一个时间点无法说明版本现在处于什么状态，也无法告诉相关人员下一步要做什么。至少应区分计划发布时间、变更冻结时间、放行评审时间和实际完成时间。

计划发布时间是对外或跨团队沟通的目标；变更冻结时间是限制新增功能、修复和配置变更的边界；放行评审时间是核对质量、安全、运维和业务条件的决策点；实际完成时间则是发布部署、验证和必要的业务确认都完成的时间。

这四个时间相互关联，却不能互相替代。计划时间可以调整，冻结时间可以提前，评审可以否决，实际完成时间只能由发布记录确认。若团队把它们统一填进一个日历事件，管理者看到的只是安排，不是风险。

2. 将发布改造成一组可验证的状态迁移

一条可执行的版本流程，应该能回答三个问题：当前版本在哪个阶段、进入下一阶段需要什么证据、谁有权决定继续或暂停。只有状态名称而没有进入条件，流程就会退化成看板上的装饰标签。

状态机的价值不在于把流程画得更复杂，而在于让“卡住”变得可见。版本停在测试中三天，与版本已经放行但等待窗口，是两种完全不同的问题，需要不同的处理方式。

3. 先用少量指标控制风险，再逐步增加指标

流程优化不需要一开始就建设复杂的管理仪表盘。对于多数团队，我会先保留四项核心指标：版本发布时间偏差、发布成功率、变更失败率和发布后缺陷率。它们分别回答计划是否可信、执行是否顺畅、变更是否造成生产问题、用户是否承担了质量代价。

不要为了显得精细而把数十个指标一次性纳入考核。指标过多会让团队花时间维护口径，甚至为了好看修改统计边界。先保证每项指标定义清晰、数据源稳定、能关联到具体改进动作，再扩展到审批等待、冻结后变更、回滚耗时等过程指标。

4. 发布治理要追求“可预测”，而非机械地追求准时

准点发布不是最高目标。如果团队为了守住日历时间而跳过测试、压缩观察期或隐瞒未解决缺陷，表面上准点率提高了，真实风险却被转移给用户和一线支持人员。

成熟的发布时间流程，目标是让承诺有依据、例外有记录、风险有边界、失败能恢复。当版本不满足条件时，按规则延期，往往比按时发布一个不可控版本更专业。

二、背景与场景：为什么发布时间总在临近时变成“抢救现场”

1. 日期承诺先于工作量和依赖确认

不少版本计划从业务活动日期倒推出来：营销页面需要某功能，销售希望某能力进入演示，管理层据此要求在某天发布。日期先被承诺，范围、依赖、测试容量和外部审批随后才逐步浮现。

这会造成一种典型错觉：团队看起来有明确计划，实际上计划缺少约束条件。比如支付接口变更要等外部联调，数据迁移需要维护窗口，移动端商店审核时长也不是研发团队能够完全控制的。如果这些依赖没有写进版本计划，发布日期只是一个愿望。

2. 多团队协作让局部完成掩盖整体未完成

研发说代码已合并，测试说主要用例已通过，运维说部署脚本已准备，产品说文案还要确认。每个岗位都可能完成了自己的任务，但版本作为一个整体仍未具备发布条件。跨团队版本治理的难点，往往不是任务无人负责，而是交接处没有明确的完成定义。

我建议把“完成”拆成可检查的证据。例如，代码完成要能关联提交和构建；测试完成要能查到范围、结果及未覆盖风险；运维准备完成要能查到部署步骤、监控与回滚验证；业务确认完成要能说明验证人和验收路径。口头确认可以用于沟通，不能代替可追溯记录。

3. 版本发布具有不同的风险轮廓

一次低风险文案修正，与一次涉及数据库结构、账户权限和核心交易链路的发布，不应使用完全一样的审批强度。若所有版本走同一套重流程，小改动会被流程拖慢；若所有版本都按轻量变更处理，高风险变更就可能缺少必要控制。

因此，发布时间流程需要先做风险分层。风险分层不等于降低高风险版本的质量要求，而是让控制强度与影响面、可逆性、依赖数量和用户受影响程度匹配。

4. 工具的价值在于把依赖与证据串起来

在跨团队协作中，版本管理工具或项目管理平台可以帮助团队关联需求、缺陷、迭代、构建、审批和发布记录，但工具本身不会自动产生有效流程。字段填得再完整，如果责任人不清、口径不一致、例外不留痕，信息仍然无法支撑决策。

以 PingCode 为例，对于百人以上、中大型研发组织，适合把需求计划、研发任务、缺陷、测试活动与版本节点放在同一协作链路中观察；但是否适用，仍要看组织的系统集成、权限治理、审计要求和现有工作方式。选型时我更关注能否追溯“需求为什么进入这个版本、缺陷由谁放行、构建对应哪批代码、上线后如何关联问题”，而不是只看有没有一个名为“版本发布”的页面。

三、常见误区：看起来在管发布时间，实际只是在填日期

1. 把准点率当成唯一成绩

准点率容易理解，也容易误导。若团队通过提前删减范围来保证时间，版本可能准点，但承诺价值缩水；若团队拒绝延期，即使回滚和线上事故增加，单看准点率仍然“表现优秀”。因此，准点率必须与变更失败率、延期原因和发布后质量联合解读。

我的判断原则是：任何单一指标都不能证明流程健康。准点率要与用户影响、质量结果和范围变化一起看。若准点率提高但发布后缺陷同步上升，应优先调查质量门槛是否被放宽，而非继续奖励按时发布。

2. 把“测试通过”误解为风险为零

测试通过意味着在既定范围、环境和用例下，未发现达到阻断标准的问题，不代表所有路径都没有风险。测试环境与生产配置差异、并发量变化、数据分布差异、第三方依赖异常，都可能使已通过的版本在生产环境表现不同。

更可操作的做法是记录测试覆盖范围、未覆盖部分、已知缺陷、生产验证计划和回滚触发条件。让评审者知道剩余风险是什么，比用一句“测试已通过”营造确定性更有价值。

3. 把冻结时间变成“冻结后仍可随便改”

冻结并不意味着绝对禁止变更，而是意味着变更成本和审查级别上升。若冻结后仍可直接塞入新需求，冻结就没有管理意义；若任何极小修复都被一刀切禁止，团队又可能为了守规矩而延迟必要的安全修复。

建议冻结后变更必须登记原因、影响面、风险、测试范围和批准人。对于安全漏洞修复、生产阻断问题，可走紧急变更路径；对于体验优化和非阻断需求，原则上进入下一版本。核心区别不是“能不能改”，而是“改动是否重新通过风险评估”。

4. 把延期视为个人失败，造成风险信息延迟暴露

若组织只惩罚延期，团队会倾向于晚报风险、缩小问题描述或把未完成工作挪到发布之后。这样统计表上的日期可能更漂亮，但决策者失去提前调整范围和资源的机会。

我更愿意区分“可预见但未管理的延期”和“合理暴露的外部风险”。前者需要改进依赖识别、估算和跟踪；后者需要判断是否有备用方案、是否及时沟通、是否保护了质量底线。评价流程，应看团队何时发现风险、何时升级、采取了什么动作，而不仅仅看最后晚了几天。

5. 发布完成只看部署命令返回成功

部署工具显示成功，只能证明部署动作完成，不一定证明业务已恢复。新版本可能启动正常，却出现关键接口错误、订单积压、权限异常或数据写入偏差。生产验证应以业务关键路径和服务指标为准，而不是以“发布任务已结束”为准。

• 检查关键接口成功率、延迟、错误率和资源水位是否在约定范围内。
• 抽查关键业务路径，确认用户实际操作得到预期结果。
• 确认告警、日志和支持渠道正常，异常能被值守人员发现。
• 对涉及数据变更的版本，核对数据一致性和迁移结果。

四、专业判断逻辑：用风险、证据和决策权设计放行机制

1. 先定义版本风险等级，再决定流程强度

我通常把版本风险评估放在排期阶段，而不是发布前一天。可以用四个维度打分：用户影响范围、失败后果、变更可逆性、依赖复杂度。每个维度按团队自定义的低、中、高等级评分，不必追求看似精确的小数，重点是让高风险信号提前出现。

例如，涉及全量账户权限、数据库不可逆迁移和多个外部系统联动的版本，即使代码量不大，也应按高风险版本处理。反过来，一个代码改动较多、但仅限内部工具且可通过开关关闭的版本，未必需要与核心交易变更同等的审批层级。

2. 对高风险版本设置“证据门”，而不是增加会议

会议本身不是控制措施。评审时真正有用的是证据：测试结果、变更清单、迁移演练记录、监控方案、回滚验证、值守安排和已知风险。若材料缺失，开再长的会也无法弥补事实空白。

3. 发布决策必须有明确的否决权和升级路径

很多团队表面上有审批流程，实际所有人都认为“别人会负责”。我建议在版本规则中明确：谁可以批准放行，谁可以基于质量、安全或运行风险暂停发布，暂停后由谁协调补救。高风险版本可采用共同放行，低风险版本则可授权给明确的发布负责人，避免所有变更都等待高层签字。

否决权并非为了增加权力，而是避免责任模糊。测试负责人可以说明测试风险，运维负责人可以指出恢复能力不足，安全负责人可以指出合规问题；最终决策人应对继续、延期或缩小范围作出明确记录。

4. 把“可逆性”作为发布时间安排的重要变量

可逆性常常比代码量更能决定发布风险。能够通过功能开关关闭的改动，可以渐进放量；数据结构变更若采用兼容性设计，可以先扩展、再迁移、最后清理；不可逆的数据覆盖则需要更严格的备份、校验和恢复演练。

我会优先推动“先兼容、后切换、再清理”的变更策略。它不一定缩短开发工期，却能降低单次发布失败的恢复成本。对于没有办法快速回滚的变更，发布时间表要预留更长的验证窗口，不能仅因部署动作很快就安排在低值守时段。

5. 决策逻辑可以归纳为四道检查

1. 价值检查：本次发布的目标是否仍然成立，范围是否被无声扩大或缩小。
2. 质量检查：阻断级缺陷是否关闭，剩余风险是否有人接受并记录。
3. 运行检查：部署、监控、值守和恢复方案是否经过验证。
4. 用户检查：用户是否需要通知、培训、迁移支持或临时降级安排。

任一道检查不通过，都不必自动意味着整版延期。团队可以选择剔除高风险变更、缩小放量范围、分批发布或改变发布时间窗口。真正重要的是，替代方案必须重新评估风险，不能把“拆分发布”当作不需要验证的快捷方式。

五、案例与数据观察：一个月度版本节奏如何从“总在延期”变得可解释

1. 用模拟案例说明指标如何形成闭环

下面是一组情景模拟数据，不代表行业平均水平，也不是某个组织的真实业绩。假设一个中大型研发团队每月发布两个主要版本，之前只记录“原计划日期”和“实际上线日期”。连续三个月中，团队发现多次延期，但无法快速判断究竟是需求变化、测试返工、依赖阻塞还是发布窗口冲突。

团队随后为每个版本记录冻结日、放行日、实际完成日、冻结后变更、发布失败、回滚、线上缺陷和延期原因，并将变更与需求、缺陷和构建记录关联。经过一个季度的观察，团队发现最大的改进不是所有版本都准点，而是延误原因开始可分类，风险可以在发布前被识别。

这组数据的重点不是数字看起来改善了多少，而是每项指标都对应了流程动作。冻结后变更比例下降，说明变更入口更清晰；回滚决策耗时下降，说明运行方案更可执行；发布后缺陷减少，仍需检查版本复杂度、缺陷严重度和统计范围，不能直接归因于单一流程动作。

2. 用漏斗找出发布流程中的等待损耗

如果版本总是临近发布日期才暴露问题，可以把版本从计划到放行的路径按阶段统计。比如记录版本进入计划、范围确认、测试开始、测试通过、评审放行和生产验证的数量与耗时。数量逐级减少不一定是坏事，关键是判断减少发生在正常筛选还是反复返工。

下面同样是情景模拟：每季度 20 个计划版本中，18 个按计划进入测试，15 个一次通过测试，14 个在目标窗口放行，13 个完成生产验证。若大多数损耗发生在测试入口前，优先检查范围和依赖；若测试通过后仍频繁错过窗口，优先检查审批、值守和发布窗口安排。

3. 指标必须有分母、时间窗口和版本边界

“发布成功率”看起来简单，实际需要至少明确三个口径：分母是所有计划版本还是实际启动部署的版本；成功是部署命令成功还是线上验证通过；观察窗口是发布当日、24 小时还是七天。口径不同，数值就不能直接比较。

“发布后缺陷率”也要明确缺陷归属。若同一缺陷被关联到多个版本，是否重复计算？用户报告何时算入？只统计线上严重缺陷还是全部问题？没有稳定口径，团队会在指标上产生争论，而非讨论改进。

4. 不要用模拟数据伪装为外部行业基准

如果团队没有可信的外部对标数据，先用自己的历史数据建立基线。建议至少覆盖三个完整发布周期，并按版本类型、风险等级和服务范围分层。样本少时，不必急着建立绩效排名；先用趋势识别异常，查看改善是否持续。

如需引用行业调查、标准或研究报告，应记录来源、发布日期、调查对象和定义。不同组织的部署频率、发布单元和服务形态差异很大，外部数字只能提供参照，不能直接成为所有团队的硬性目标。

六、指标设计：让数字推动改进，而不是制造新的表面工作

1. 先定义四类指标，避免只看结果

版本管理指标可以分成结果、过程、风险和恢复四类。结果指标衡量版本带来的运行结果；过程指标观察计划与交付的稳定性；风险指标捕捉范围波动和缺陷暴露；恢复指标衡量出问题后能否及时止损。

2. 发布时间偏差应看分布，不只看平均数

假设一个团队有八个版本，七个只晚一天，一个晚了二十天，平均偏差会被极端版本拉高。反过来，如果多数版本准点、少数版本提前很多，平均数也可能掩盖延期问题。建议同时观察中位数、偏差区间和延期比例，并给提前发布设置合理解释，避免“越早越好”成为隐性激励。

偏差还要区分方向。提前上线可能意味着团队完成效率高，也可能意味着质量门槛被跳过或对外承诺管理混乱；延期可能是估算问题，也可能是合理的风险控制。指标应引出复盘问题，而不是自动生成奖惩结论。

3. 变更失败率不能脱离发布频率和变更规模

团队每月发布一次，与每天发布多次，面对的单次变更规模和暴露方式不同。比较失败率时，至少按服务、变更类型和发布方式分层。小批次持续发布降低单次风险，不意味着每个团队都能在没有自动化测试、监控和快速恢复能力时直接提高频率。

失败事件也要有统一定义。是否把功能降级、紧急修复、回滚、数据修正都计入？若定义只包括整站故障，团队可能漏掉大量影响用户的局部异常。口径应简明，但不能只选择有利于达成目标的部分。

4. 指标的价值要通过决策动作验证

每个指标都应能回答“超过阈值后做什么”。例如，冻结后变更率持续升高，就检查需求入口和产品决策周期；回滚决策耗时偏长，就检查告警阈值和授权路径；测试返工增多，就分析需求验收标准、环境差异和缺陷发现阶段。

如果某项数字连续几个周期变化，却没有改变任何决策、流程或资源安排，它可能只是报告装饰。此时应考虑合并、替换或停止收集，而不是继续要求团队多填一列。

七、落地流程：从排期到复盘，建立能够执行的版本节奏

1. 排期阶段：先确认目标、边界和依赖

版本计划建立时，除了发布日期，还要登记发布目标、用户范围、关键需求、候选缺陷、外部依赖、风险等级和责任人。此时不要求所有细节已经冻结，但必须把未知项暴露出来，并标明何时能够确认。

对于跨团队依赖，建议记录提供方、需要的交付物、承诺日期和逾期升级路径。仅写“依赖某团队”没有操作价值；若对方无法承诺，应把不确定性纳入版本风险，而不是默认依赖会按时完成。

2. 开发阶段：让版本内容始终可追溯

开发过程中，需求、代码、缺陷和构建之间要保留关联。发生范围调整时，记录变更理由、影响、审批人及对测试和发布时间的影响。关联并不是为了追求所有数据都进同一系统，而是确保发生问题时能快速还原版本构成。

大规模研发组织可以借助研发管理工具或项目管理平台集中查看版本与工作项的关系。像 PingCode 这类面向研发协作场景的平台，可作为连接需求、迭代、缺陷、测试和发布信息的一种选择；具体部署要结合团队现有工具、数据权限、系统集成与审计需求评估。无论选什么工具，核心仍是先确定字段定义、责任边界和流程规则。

3. 冻结阶段：冻结范围，不冻结风险识别

冻结日前，版本负责人应核对需求范围、未关闭缺陷、外部依赖、测试环境和构建计划。冻结后，新增变更进入例外流程，而不是在原任务中悄悄替换内容。这样团队才能知道实际交付范围与最初承诺之间发生了什么变化。

冻结规则要考虑不同发布类型。安全修复和生产阻断问题可以有紧急通道；非必要优化应进入后续版本。若团队无法区分紧急修复与体验优化，说明变更分类和审批责任尚未建立，而不是说明冻结规则过于严格。

4. 测试与放行阶段：按证据做决策

测试阶段应明确回归范围、自动化结果、环境差异、未覆盖风险和阻断缺陷标准。进入待放行状态前，版本负责人检查部署步骤、监控、值守、恢复方案和业务验证人员是否齐备。

放行评审不宜只报“完成率”。可以按风险点逐项确认：是否存在未关闭的高严重度缺陷、是否有不可逆数据变化、恢复步骤是否演练、流量如何放大、达到什么条件需要停止。若答案不清楚，评审应输出补充材料或延期决定，而不是用模糊的“原则上通过”放行。

5. 发布阶段：把停止条件写在发布前

发布执行记录应包含执行人、开始时间、阶段结果、异常、验证结果和最终决定。对分批发布，需明确每批比例、观察时长和扩大条件；对功能开关，需记录默认状态、开启责任人和关闭路径。

停止条件要可观察、可触发。例如，关键业务成功率连续一段时间低于约定阈值，或错误率超过基线区间，就暂停扩大流量并启动分析。阈值应由服务基线和业务影响确定，不能直接把示例数值复制到所有系统。

6. 观察与复盘阶段：完成闭环而非补写报告

版本进入观察期后，团队应核对服务指标、业务关键路径、用户反馈和支持工单。观察结束的条件提前约定，避免版本长期停留在“已经上线但还没结项”的模糊状态。

复盘聚焦系统问题，而非寻找替罪者。检查延期是否可提前识别、冻结后变更是否合理、缺陷在哪个阶段首次可发现、上线异常是否及时触发、回滚路径是否有效。每个复盘结论要转成有负责人、完成期限和验证方式的改进事项。

1. 发布前：确认版本范围、风险等级、变更清单和依赖状态。
2. 放行前：核对测试证据、部署步骤、监控、值守和恢复计划。
3. 发布中：按批次执行，记录异常，依据停止条件决定继续或暂停。
4. 发布后：完成业务验证、观察期检查、缺陷归属和改进项追踪。

八、不同情况下的行动建议与取舍

1. 团队规模较小、版本影响面有限

小团队不必照搬大型组织的多级审批。可以由版本负责人维护一份简洁清单，包含范围、测试结果、部署步骤、恢复方法和验证人；低风险变更采用授权放行，高风险变更才增加跨职能评审。

取舍在于少量流程换取更快协作。不要为了追求“规范完整”引入无法维护的审批层级，但也不要以人数少为由省略生产验证和恢复准备。一个人兼任多个角色时，至少确保关键决策和操作记录可追溯。

2. 百人以上、多团队并行交付

组织规模扩大后，重点通常从“有没有流程”转向“不同团队能否使用一致口径”。建议建立统一版本字段、状态定义、风险等级和指标口径，同时允许业务线对测试深度、窗口长度和审批层级做有边界的配置。

这类组织可以评估研发协作平台是否能连接需求、缺陷、测试、构建、审批与发布记录。选择时要看权限隔离、审计、报表口径、现有系统集成和迁移成本，不要把上线平台等同于流程治理完成。工具用于减少信息断点，流程所有者仍需对规则负责。

3. 涉及数据迁移、权限、安全或合规的高风险版本

高风险版本应尽量提前完成方案评审、测试环境演练和恢复验证。对于不可逆数据操作，安排备份校验、迁移前后对账、分批执行和异常停止条件；对于权限或安全变更，明确影响对象、审计记录与紧急关闭路径。

取舍是发布速度可能下降，但故障代价更低。若业务窗口不能调整，应优先缩小版本范围、分阶段放量或拆分可逆与不可逆变更，不应仅靠增加参与评审的人数来制造安全感。

4. 高频持续交付团队

高频团队可以采用更轻量的单次放行，但前提是自动化测试、构建、部署、监控和恢复能力足够可靠。团队需要关注变更批次大小、自动化检查失败率、生产验证覆盖和恢复时间，而不是单纯追求发布次数。

取舍是降低单次变更的影响范围，换来对工程自动化和可观测性的持续投入。如果发布流水线经常需要人工补步骤，频率升高可能只是把不稳定性更频繁地暴露出来。先修复重复性人工环节，再逐步提高频率。

5. 发布日期受市场活动或客户承诺约束

固定日期不等于必须固定全部范围。可以把版本分成必须交付项、可延后项和可通过配置控制的项，并在计划阶段定义范围调整的优先级。若核心能力未达到质量门槛，应提前启动替代方案，而不是在最后一天才宣布延期。

取舍是对外承诺的稳定性与交付范围之间需要显式交换。越早说明可选范围，业务越有机会调整沟通、培训或活动安排；越晚暴露风险，所有方案的成本都会上升。

6. 什么时候该买工具，什么时候先改流程

当版本信息分散在多个表格、聊天群和代码仓库中，团队反复手工汇总且经常出现版本关联错误时，工具可能有明显价值。若问题主要是无人负责、范围持续变更、审批权不清，即便导入管理平台，也只会把混乱搬到新系统里。

我建议先用一到两个发布周期统一字段和口径，再判断系统需求。评估平台时，安排真实版本做试点，观察需求到发布的追溯是否顺畅、数据录入是否增加负担、权限和审计是否满足要求、异常是否能被及时发现。试点结果应基于任务完成情况和数据质量，而非演示页面是否好看。

7. 不同目标之间的取舍顺序

当发布时间、范围、质量和风险无法同时满足时，团队需要公开取舍顺序。对涉及用户安全、数据完整性、隐私或关键交易的系统，质量与风险控制通常不能为了日期让步；对低风险功能，范围可以缩小以保持日期；对外部依赖不可控的项目，应尽早调整承诺而非等待最后一刻。

• 优先保日期：适用于日期不可移动且范围可拆分的场景，代价通常是缩小本次交付范围。
• 优先保范围：适用于核心承诺不可拆分的场景，代价是接受延期并提前沟通影响。
• 优先保风险底线：适用于安全、数据、资金和关键业务变更，必要时暂停发布或分阶段上线。
• 优先保恢复能力：适用于无法完全消除不确定性的场景，以灰度、开关和快速回退控制故障影响。

九、结语：把发布日期从承诺变成可管理的决策

1. 真正的流程优化不是让每个版本都按时

版本发布时间流程优化的核心，不是把团队训练成更会赶日期，而是让承诺建立在范围、依赖、质量和恢复能力之上。发布日期可以调整，质量门槛不能含糊；流程可以轻重不同，放行证据必须可验证；指标可以精简，口径必须稳定。

我尤其重视一个容易被忽略的判断：版本管理的成熟度，不体现在流程图有多少方框，而体现在团队能否在问题变成线上事故之前，准确说出风险在哪里、由谁处理、何时需要暂停。能提前暴露坏消息的团队，通常比只报告好消息的团队更可靠。

2. 下一步从一个真实版本开始

不需要先重建全部研发流程。选一个即将发布的版本，记录计划时间、冻结时间、放行时间和实际完成时间；明确版本范围、变更责任人、测试证据、监控方案和回滚触发条件；发布后再对照结果，统计延期原因、冻结后变更和线上问题。

连续观察几个周期后，再决定哪些规则值得固化、哪些指标有助于决策、哪些环节需要工具支持。好的发布时间流程，不是保证永不延期，而是让团队知道何时可以发布、为什么暂缓，以及怎样安全地继续前进。