【每日一学 20260810】敏捷之道——从逐特性集成到逐特性发布

2026-08-10 16:02:00
蓉蓉
原创
11

1、逐特性集成

这里所说的特性（Feature）这个概念，大体上对应于敏捷需求管理中的用户故事（User Story），它是对用户有意义、有价值的一块改动，它是独立可区分的，可以独立开发、测试甚至发布。特性通常不太大，几个人日甚至更短的时间就可以开发完成。


为什么在用户故事之外还要引入特性这个概念呢？因为除了要为功能需求编写代码并测试和发布，还有非功能需求、缺陷修复、技术债等。除了一个用户故事是一个特性，一个线上缺陷的修复、一个软件实现上的优化或者一处安全上的加强，也都可以被看作一个特性。当然，前提是这个用户故事、线上缺陷的修复或者软件实现上的优化安全上的加强是独立的，并且不值得再拆分为更小的特性分别管理。


（1）程序员要做比较充分的自测试，以避免特性合并进集成分支了又要被踢出来或者反复找补，浪费时间。自测试是在程序员个人开发环境中进行，但它不应该是仅运行并测试正在改的这一个代码模块，而是应该运行整个系统，看这个代码模块上的改动对整体的影响。这该如何实现呢？举个例子，在微服务的架构下，可以考虑在程序员个人开发环境中运行的被修改的这个微服务，并让它去调用某个公共测试环境中其他微服务，甚至被其他微服务调用。
（2）特性分支上，代码提交应该触发流水线，至少进行构建、单元测试、代码扫描工作，随时发现问题并修复。这样的流水线不应该是每当新建一条特性分支时，就得人工新建并配置一条对应的流水线。这应当是自动完成的，新建一条特性分支，就会自动产生一条对应的流水线。也可以考虑，不是每条特性分支都对应一条专属的流水线，而是不论哪条特性分支上的代码提交都自动触发同一条流水线的运行。
（3）当把特性分支合入到集成分支的时候，使用类似合并请求（Merge Request）/拉取请求（Pull Request）这样的机制。不仅可以在此做代码评审，而且可以设置必须代码评审通过且流水线运行成功时，才能把特性分支合并到集成分支。这样的机制有利于保证特性提交时的质量。
（4）集成分支上持续测试。在集成分支上，不仅是特性分支的合入要触发流水线进行一系列自动化的检查，人工测试也应当比较频繁地开展，接近于逐特性测试。这些都是集成阶段要做的事情。不应该把这些测试推迟到所有特性都开发完，进入发布阶段再做，那就违背了持续集成的基本思想。
（5）自动化部署。由于测试变得频繁，测试前向测试环境部署待测版本也需要变得频繁，所以它必须是自动化的了。

2、逐特性发布

持续交付意在使用自动化等一系列手段，在保证质量和安全的前提下，提高部署到类生产环境和生产环境的频率，于是缩短了一个特性从开发完成到发布上线所需的时间。


发布上线的频率越高，一个特性在开发完成后等待凑齐一拨一起发布的时间就越少，一个特性从开发完成到发布上线所需的时间就越短。那么把它推到极致是什么情况呢？一个微服务每天发布1000次？不是。极致是每个特性都单独测试和发布，无需等待其他特性一起测试和发布。没有必要也做不到更高频率了，因为我们对特性的定义就是值得独立发布的最小改动。

（1）测试环境自动创建与分配。由于每条特性分支都需要相应的一个特性测试环境，流水线也需要它，人工测试也需要它。因此特性测试环境的数量是不固定的，随时可能需要更多的特性测试环境。当需要一套新的特性测试环境时，最好是可以很快很方便地创建出来。这就要求创建过程是自动化的，而且不需要繁琐的审批流程。当想要的时候，应该就是点个按钮的事儿。更进一步，考虑到创建毕竟还是需要一些时间，最好是总是保持少量已创建好的且空闲的测试环境实例，随时可以分配。
（2）必要时使用虚拟独占方式。当整体环境中包含了成百上千个微服务，那么提供一套测试环境就需要很高的成本，于是仅能有一两套功能测试环境，仅在特性分支合入集成分支后才做正式测试。此时，在技术上就限制了流程的优化。解决的方法是：一套测试环境，也就是一个整体环境实例，并不意味着其中每个微服务都是这个环境实例独占的——一个微服务实例可以为多个环境实例服务，而在技术上实现让一个微服务实例仿佛只为一个环境实例服务，不同环境实例之间看起来相互隔离。我们姑且称这一类方法为虚拟独占方式。这需要借助一些技术和方法来实现，比如通过消息路由、远程调用路由等来实现，这与具体系统使用的微服务架构有关，不能一概而论。
（3）特性分支上持续测试。在特性分支上，不仅是代码提交要触发流水线进行一系列自动化的检查，人工测试也应当尽量在开发过程中就做，而不是等到这个特性开发完成后。在特性开发完成后再做，测试以及随后的修复，就会变成关键路径上明显的一段。
（4）消除发布窗口。发布窗口是指只有在特定的日期或特定的时间才能发布。发布窗口造成积压和等待，使得逐特性发布变得没有意义，因为反正要等到发布窗口才能发布。
（5）消除发布审批流程。发布不太频繁时，有个发布审批流程尚能接受。当发布很频繁，每个特性都单独发布时，发布审批流程会让开发团队和领导都不胜其烦。反过来，考虑到发布审批流程会让开发团队和领导都不胜其烦，大家就不想频繁地发布。
（6）开发团队自行发布。在测试通过后，开发人员或测试人员点个按钮就发布了。发布不太频繁时，转给运维人员操作发布，尚能接受。当发布很频繁，每个特性都单独发布时，这道转手会让开发团队和运维人员都不胜其烦。反过来，考虑到这道转手会让开发团队和运维人员都不胜其烦，大家就不想频繁地发布。

逐特性集成可以做到特性隔离，这比“正统”的持续集成好，很多团队用的是这个改进版。如果你还没有尝试，那尽快试试看。


逐特性发布是持续交付的极致，要实现它得克服不少困难。向这个理想迈进的过程，就是每次发布所包含的特性逐渐减少的过程。在现实条件下，发布的颗粒度能多细就多细，同时不断改善现实条件，争取让发布的颗粒度更细，越接近每个特性都单独发布越好。


来源：《敏捷之道》——从逐特性集成到逐特性发布--文/董越

发表评论
通过审核后显示您的意见