前些天在评审项目的年度过程改进策划方案时，讨论了软件开发中的一个重要指标“版本发布周期”，这个指标年年讨论。我也觉得这是一个非常重要的指标，一直也有些自己的看法，这次把自己的看法完整的写出来，欢迎大家一起探讨。需要说明的是，出于信息安全的考虑，整个文章中不会有任何与公司相关的敏感信息，是纯技术问题的探讨和思考。本文包括如下内容：

• 基本概念
• 分析现状
• 诗和远方-持续发布
• 如何实现持续发布
• 小结

一、基本概念

在软件开发中，“版本发布周期”简单的说，就是我们多长时间可以交付一个可用的版本。
需要说明的是，版本发布和版本上线是两个概念，尤其在交付类项目中。我们通常说的版本发布是指研发人员将用户需求转换为可运行的软件版本的过程；版本上线指将可运行的版本部署到生产环境的过程，包括全新部署、版本升级、或打补丁。
一个需求（或想法）只有经过研发人员发布出可用的版本，并且在生产环境上线后，其价值才真正得到实现。所以从客户价值去考虑，版本上线才算真正的交付，因此一个完整的交付周期是由”版本发布周期+等待周期+上线周期“组成的。
不同的行业对交付周期会有不同的要求，比如互联网应用，企业内部的IT系统，交付周期越短越好；比如银行、电力、电信等行业的业务系统，它们的版本上线有严格的要求，并不是那么频繁。
对于我们研发来说，重点关注的是”版本发布周期“，那么”版本发布周期“多少适合呢？是越短越好，还是适中就好？这个问题先不讨论，后面再说。

二、分析现状

我们现在大多数项目都在使用敏捷开发中的Scrum方法来组织自己的研发交付，scrum方法有两个关键特征：
1、基于迭代和增量的开发和版本发布
2、自组织、跨职能的特性团队。
实际的情况，在这两个关键特征上我们都做的不够好，下面简单解释下。
理想的迭代开发，指每个迭代都能交付可用的版本，真能做到的话，我们根本不需要讨论”版本发布周期“，迭代的周期就是”版本发布周期“。但是我们做不到，核心问题就是我们无法做到在一个迭代内交付可用的版本，主要是质量过不了关，现在有个更高的产品安全要求，更过不了关了。所以我们就推出了所谓的”x+y“的发布模型，也就是一个发布周期包含x开发迭代+y个系统测试迭代，y目前大都是1。实际上很多项目，把这由多个迭代组成的发布周期做成了小瀑布的开发方式，背离了敏捷开发的原则。
上面提到scrum的第二个关键特征”自组织、跨职能的特性团队“，虽然我们比以前有了进步，但远远不够，其实看到所谓的”x+y”模型，就知道我们做的还不够好。

我觉得我们应该回归迭代开发的初心，把目标定在如何实现真正的迭代交付。现在达不到没关系，可以慢慢努力去达到，但如果不朝这个方向去努力，再怎么努力，也不可能达到目标。可我们现在是沿着另一个方向去努力，即如何把x+y模型做的更好,我觉得，方向有点错了（声明下，这是个人观点，不一定正确，仅供参考）。

三、诗和远方-持续发布

虽然我们连scrum方法的实施还没有达到理想的状态，但这不代表我们不可以畅想下诗和远方（这个远方仅代表我个人观点）。
在本文的开头，我抛出了问题：”版本发布周期“多少适合？这里直接给出我的个人观点：越短越好，理想的方式是按需持续发布。
比如对于已经上线的一个产品，如果我们需要改一行代码，从开发人员在本地改这行代码开始，一直到在生产环境下生效，这个过程和周期是什么样的？理想的情况是，有这样的一个流水线，开发人员提交代码，触发自动编译，代码质量检查，安全检查，版本生成，测试环境部署，自动化测试，试运行环境部署，生产环境上线。
如果是一个新增需求，经过需求分析和拆分后，可能会分解到多人共同开发，这里有一个协同的过程，一旦大家代码编写完成后，一样通过流水线完成发布和上线。

这里有两个关键的两点：
1、全自动化的流水线
2、通过Devops完成版本上线的最后一公里。
我们传统的产品开发中，开发基本上只关注到版本发布，也就是把版本做出来即可。而版本何时上线，如何上线则是另外一件独立的事。现在要把这两件独立的事情打通，形成一个贯穿的流水线。

需要说明的是，全自动化不代表一定没有人工参与，就如同现在的物流快递行业，中间很多操作是人工操作，但它的流程是全自动化的。用户一旦下单后，会有一个全流程的工单流程，有了这个流程，就会保证物品按照既定的路径和时间点被送达用户，有哪些人在哪些路径参与。在软件开发和发布中，有些也需要人参与，典型的如用户体验的验收，我们要做的是把这个人工环节纳入到整个流水线中，一旦触发了，就会自动触发相应的人去执行这个动作，而不是依赖临时的安排。

四、如何实现持续发布

要想实现上面说的按需持续发布，是需要很多前提条件的。
首先，不能使用Scrum方法了：
因为Scrum方法的迭代周期是一个固定的时间盒，有一些固定的规则（如4会），它这个迭代周期不能太短，太短了就无法操作了。

其次，要实现开发运维一体化，即实施DevOps：
最适合持续发布的软件产品是一个公司内部自研的IT软件系统和自运维的互联网产品；比较困难的是对外交付类产品，即开发者和所有者不是一个公司的；特别难的是为如电信、电力、银行等传统行业开发交付的产品。
因为对于公司内部自研的IT软件系统和自运维的互联网产品，开发者和运维者都是一个公司的，可以最大程度的发挥DevOps的优势，可以比较容易实现从代码提交到发布、部署上线的一站式流水线操作。
而对外交付类产品，开发者和所有者是两个公司的，而且交付的周期和方式往往受合同的限制。这时我们首先要做到的是具备持续发布的能力，比如能发布到测试环境或试运行环境上且能通过验收，也就是用户要不要是一回事，我们能不能做到是另一回事。另外牢记敏捷宣言四句话之一的”客户合作胜过合同谈判“，多与客户沟通，引导客户，把DevOps的理念和好处告诉给他们。

最后，需要有强大的研发能力，比如：
1、高质量的开发能力
想想，如果我们无法进行高质量的开发，每新增或修改需求，就引入一堆问题，这个无论如何能快不起来。

2、松耦合的系统架构设计能力
如果我们系统是一个紧耦合的系统，比如是包含很多模块（或功能）的单体架构。哪怕我们的研发能力再强，当有一个变更时，都需要考虑对其它模块潜在的影响。还有复杂的升级问题。想快也快不起来。好在虚拟化、微服务给我们带来了希望。

3、需求分析和分拆能力
用户的需求往往是不清晰的，颗粒度可能也是比较粗的，涉及到的模块（或功能）可能也比较多。为了能快速的发布，需要我们能进行很好的需求分析和拆分，将用户需求转化工作量可控的且相对独立的各个产品需求，并能做好波及分析，这个是能快速开发和交付的基础。

3、高水平的自动化测试能力
在软件开发中，有一个常见的名词叫“回归测试”，如果没有完善的自动化测试，我们很难保证变更带来的波及影响。只有具备完善的自动化测试，我们才可以放心的去修改代码。

5、制定有效分支策略的能力
如果我们要做到实时发布，我们就不能像以前一样每个发布版本对应一个分支，必须要有新的代码分支策略。比如单分支的策略是演进方向之一。

6、完善的基础设施能力
从开发到上线，要求全流水线，做到最大程度的自动化，一旦有问题，还能无风险的回退能力。这就要求我们有很强大的基础设施和完善的Devops工具链。

7、很强的团队协作能力
我们希望有自组织的、跨职能的团队，大家一起来进行研发交付，其中人是核心。团队成员如何有效的合作，是一切的基础，是持续成功的关键。正如敏捷宣言中另外一句话”个体和交互胜过过程和工具“。

上面只是列出了部分重要的能力，肯定还不够。实际上，我为什么提倡”版本发布周期“越短越好，因为这个目标会牵引上述能力的提升。想想，即使是采用scrum方法，如果我们要做到单个迭代能够对外发布，上面提到的一些能力是都要被牵引着进行提升，否则很难做到按迭代发布。

五、小结

本文对软件开发中的核心问题之一，版本发布周期进行了思考。分析了现状，畅想了诗和远方，认为最理想的方式是按需的持续发布，并浅显的分析了如果要做到这点需要具备哪些能力。
总结下，我认为缩短”版本发布周期“是牵引项目研发过程改进的一个比较好的出发点，我们当前的改进目标应该放在如何实现迭代版本的真正可交付，并在这基础上不断缩减”版本发布周期“。观点不一定正确，大家一起探讨！