持续交付CD：如何实现一周多次安全发布

"一周发一次，每次都要熬夜盯着，发完还得留人守到第二天早上。"这是不少规模化研发团队对发布的真实印象。难点往往不在构建有多慢，而在于一次变更牵动的模块太多，出问题后恢复的成本比发布本身还高。

持续交付 CD 要解决的就是这件事：让软件随时处在可发布状态，并且每一次发布都能被验证、被观测、可回滚。做到这三条，一周多次发布靠的不是加班，而是把大变更拆成小变更、把人工步骤换成可重复的流水线、把风险限制在小范围用户和短时间窗内。

下文按落地顺序展开：先确认前提条件，再看流水线该设哪几道门，接着比较几类发布策略的取舍，然后处理出错后的回滚与恢复，最后用指标验证效果，并给出一条从一周一次到一周多次的推进路径。

一周多次发布的瓶颈，通常不在"发得多"

持续集成（CI）、持续交付（CD）和持续部署经常被混着说，但三者解决的问题不同。持续集成指开发者频繁把代码合并到主干，每次合并都触发自动构建和自动化测试。持续交付在持续集成的基础上再往前一步：让通过验证的版本随时可以发布到生产环境，但发布与否、什么时候发布仍由人决定。持续部署则把发布动作也交给流水线自动执行。

DORA（DevOps Research and Assessment）长期用四个指标观察交付效能：部署频率、变更前置时间、变更失败率和服务恢复时间。报告按表现把团队划分成不同等级，部署频率从每月一次以下到按需部署都有对应区间，变更失败率则被当作发布稳定性的核心指标。这组指标的价值不在于排名，而在于它同时看速度和质量，避免用降低质量的方式换频率。

把频率提上去以后，风险会转移而不是消失。发布次数从每月一次变成每周三次，单次变更的规模变小了，但每一次发布都要走完整的验证和观测流程，团队对工具链和值班机制的依赖反而更强。所以一周多次发布需要同时满足三个条件：变更能拆小，过程能重复，结果能回退。缺少任何一条，频率都会在几次事故之后被打回原形。

前提条件：让发布成为一个可重复的动作

持续交付 CD 的落地顺序，是先解决前提条件，再动流水线。以下四项不解决，后续所有自动化都只是把手工步骤搬进脚本。

用小批量变更替代长周期分支

长周期分支的代价不在合并冲突本身，而在于变更在这段时间里失去了验证。分支上跑通，不代表和主干合起来能跑通。把需求拆成可在一两天内完成的提交单元，提交到主干或存活时间很短的分支，让每次合入的范围可控，出问题时定位范围也随之缩小。代码评审的粒度要跟着变小：一次评审几百行，评审人只能看结构；一次看几十行，才有机会发现逻辑问题。

让构建产物和环境保持一致

同一个版本在不同环境表现不同，多数是因为构建过程本身不可重复，比如依赖版本漂移、构建机环境被污染、配置写死在代码里。一个可用的做法是一次构建、多处部署：流水线只产出一次不可变的构建产物，用提交标识作为版本号，测试环境和生产环境部署同一份产物，环境差异只通过外置配置注入。这样"测试环境没问题、生产环境出问题"的情况会明显减少。

测试门禁只拦关键路径，不追求全覆盖

自动化测试要拦的是会阻断发布的问题，而不是所有问题。单元测试覆盖核心逻辑和边界条件，接口与集成测试覆盖主要业务链路，发布前跑一轮冒烟验证关键功能可用。分层之后，反馈时间能压到分钟级：单元测试每次提交都跑，集成测试按小时或按批次跑，端到端验证留在发布前。测试用例、Bug 跟踪和需求变更放在同一处管理，才能看清某个版本的测试结论是否足以支撑发布，这也是测试管理在交付链路中的位置。

给数据和配置变更设计单独的回退路径

代码可以回滚，数据结构往往不能。加字段、改索引、拆分表这类变更一旦上线，回滚代码可能留下不兼容的数据。可行的做法是把数据库变更拆成前后兼容的两步：先做只增加、不改动的变更，例如加新字段并双写，等新版本稳定后再清理旧结构。配置变更同样要纳入版本管理和发布流程，否则一次误改配置就足以让整条流水线失去意义。

流水线设计：从提交到生产的四道门

流水线的价值在于把发布拆成几个有明确准入和准出条件的小阶段，每一段都有可观察的成功信号。规模不同的团队可以合并阶段，但不要跳过检查点。如果构建、代码管理与测试数据分散在多个系统，交接成本会在高频发布时被放大，DevOps 平台这类把 CI/CD、代码管理与研发流程衔接在一起的方案，主要作用就是减少这种断层。

提交门禁：构建与单元测试

触发条件是一次代码合入。这一关要做的事情固定：拉取代码、依赖还原、编译构建、静态检查、单元测试。成功信号是构建产物生成并通过全部单元测试，失败则直接向提交者反馈并阻断后续阶段。这一关的作用是防止问题扩散到下游，而不是代替代码评审。

预发布验证：集成、验收与性能冒烟

把构建产物部署到和生产尽量一致的预发布环境，跑集成测试、关键业务流程的验收测试，以及一轮性能冒烟。这里要特别关注数据量和依赖的差异，预发布环境的数据规模过小，压不出生产环境才会暴露的问题。

生产前的决策点：审批与发布窗口

是否需要人工审批，取决于变更的风险等级和业务对停机时间的容忍度。面向内部用户的系统可以把审批降为通知，面向外部交易类系统通常需要保留审批，但审批内容应该从"要不要发"，变成"这一版的风险等级、观测指标和回滚方案是什么"。发布窗口也要提前约定：高频发布不等于随时发布，核心业务仍应避开流量高峰。

生产验证：部署后校验与观察期

发布动作完成不等于发布完成。上线后要跑一轮线上校验，确认关键接口返回正常、核心指标没有异常波动、日志中的错误率在正常区间。观察期内的告警要有人看，并且这条链路必须能在几分钟内把流量切回旧版本。

发布策略：把一次大上线拆成多次小放量

前面四道门解决的是"能不能发"，发布策略解决的是"怎么把它放到用户面前"。几种常见策略的差别，主要在于回滚速度、资源成本和流量控制精度。

选择依据可以归结为三个问题：这次变更影响的是全量用户还是部分用户；出问题时是切换流量更快，还是关闭开关更快；团队是否具备同时运行两个版本的资源和数据兼容能力。灰度发布和特性开关通常可以组合使用，开关控制功能是否开启，灰度控制开启的范围。

发布计划本身也需要管理。把版本、发布范围、关联需求和测试结论登记在一处，发布时才容易回答"这一版包含哪些变更、哪些需求还没验证"。禅道已为国内 100 万+ 团队提供研发管理支持，其发布管理把需求与版本关联起来，便于规模化团队在多次发布之间保持记录清晰。

发布出问题之后：回滚、止损与恢复

发布的稳定性和恢复能力是两件事。指标好看不代表不出故障，而恢复速度决定了故障的影响范围。

先决定止损动作：回滚还是前滚

判断依据是问题的性质。如果问题由新版本代码引入，且旧版本能承接当前数据，回滚通常是更直接的路径；如果数据已经按新格式写入，回滚会带来不一致，那就需要前滚，也就是尽快提交修复而不是退回。这个判断应该在发布前就写进发布方案，而不是在故障现场临时讨论。

回滚要演练，不能只写在方案里

回滚路径要具备三个条件：开关或流量切换的动作足够简单；执行权限在值班人手里，不需要层层审批；数据层面的可回退性已经验证过。建议在预发布环境按季度演练一次完整回滚，记录实际耗时，把它作为服务恢复时间的基线。

观测与值班要以恢复为目标

告警要能回答三个问题：是哪一个版本、影响了哪些用户、是否还在扩散。值班机制要让第一个接到告警的人有权执行止损动作，而不是先找人确认。把恢复时间当作改进对象，比追求零故障更现实。

怎么判断一周多次发布是否安全

频率提高之后，需要用数据回答两个问题：交付是不是真的变快了，稳定性有没有被牺牲。

DORA 的四个指标正好覆盖这两个维度。部署频率和变更前置时间衡量吞吐能力，回答"交付快不快"；变更失败率和服务恢复时间衡量稳定性，回答"稳不稳"。用法上要注意，这四个指标适合作为改进参考，不适合直接挂钩个人考核。指标一旦和绩效绑定，团队就有动机把失败部署悄悄回滚而不记录，看板上的数字会变好，真实风险却被藏了起来。

落地时还有两个细节。口径要固定，只统计成功进入生产环境的部署，把测试环境发布排除在外，变更失败率要事先定义清楚什么算失败。数据要能和需求、任务、Bug 记录对应起来，否则看到一个指标变差，也不知道是哪一环节造成的。

禅道的研发效能度量与 DORA 看板把需求、任务、代码、Bug 等研发过程数据与交付指标放在同一套体系里，让团队在调整发布节奏时有据可依，而不是只看单一维度的数字。

落地节奏：从一周一次走到一周多次

提高发布频率更适合分阶段推进。一次把所有自动化做完，往往会在中途因为不稳定而回退。

第一阶段，先让发布可重复：固定构建产物、环境配置外置、补齐提交门禁的自动化测试。这一阶段的目标不是提高频率，而是让每次发布的结果可预期。

第二阶段，把发布和变更解耦：引入版本管理规范，把发布范围与需求、测试结论绑定，让"随时可发布"成为一个可验证的状态。验证方式是看任意一个已经通过测试的版本，能否在约定时间内完成一次不受阻的发布。

第三阶段，引入小范围放量：为影响面大的变更配置灰度发布或特性开关，把风险限制在部分用户和有限时间窗内。

第四阶段，缩短反馈链路：把部署后校验和告警接入发布流程，明确回滚责任人和完成时间目标。

也要接受有些场景不适合追求高频。受强合规要求约束的系统、需求本身低频的业务、依赖第三方交付节点的项目，把节奏定在自己能验证的范围内更合理。发布频率是结果，不是目标，真正的目标是让每次交付都更小、更可验证。

回到开头的问题，持续交付 CD 的难点从来不是"一天能发几次"，而是每一次发布是否都在可控范围内。把变更拆小、把过程做成可重复的流水线、把回滚当作常规动作，一周多次安全发布才是可持续的状态，而不是一次集中攻坚的结果。

常见问题

持续交付和持续部署有什么区别？

持续交付要求软件随时可发布，是否上线由业务决定；持续部署把上线这一步也自动化，通过验证的版本会自动进入生产环境。前者保留了发布决策点，后者要求在测试、监控和回滚能力上更成熟。多数企业从持续交付起步，等验证和回滚能力稳定后再考虑自动化发布。

一周多次发布适合所有团队吗？

不一定。判断标准是变更能否被独立验证、故障能否被快速恢复，而不是团队人数或所处行业。需求变更频率低、外部依赖多、合规审查环节长的团队，把节奏定在每周一次或每两周一次同样合理。频率需要和验证能力匹配。

发布频率提高后，变更失败率是不是一定会上升？

没有这个必然关系。DORA 的长期观察显示，高绩效团队在提高部署频率的同时，变更失败率可以保持在较低水平，关键在于变更粒度、自动化测试门禁和回滚能力是否同步跟上。如果只提高频率而不减小变更规模，失败率上升的概率会明显变大。