一文读懂敏捷开发的发布策略

随着数字化、信息化、网络化和智能化的普及和发展，企业对软件服务的质量和上线速度要求越来越高。传统研发模式难以满足要求，企业的开发运维模式逐渐向敏捷和DevOps 转型，敏捷和DevOps理念正被广泛认可并加速落地实践。本文主要阐述基于敏捷和DevOps的发布策略相关内容。全文3400+字，阅读时间约8分钟。

什么是发布策略

发布策略是不是发布方案、发布计划、发布方法？我们常听到的蓝绿发布、滚动发布、灰度发布是不是就是发布策略呢？下面我们就一起看一下。

发布

关于“发布”的含义，我们先看下它在整个软件开发生命周期中的位置，如图所示，发布是软件开发全生命周期中的最后一环，直接面向最终用户。

图1 软件研发流程

为了更好的理解交付，我们将各个环节逐一来看一下。

• 持续集成是开发人员提交了新代码之后，就对整个应用进行构建，目的是让正在开发的软件始终处于可工作状态；

• 持续交付是持续集成的延伸，将集成后的代码部署到类生产环境，确保可以以可持续的方式快速向客户发布新的更改；

• 持续部署是在持续交付的基础上，将代码尽早部署到生产环境，以确保可以小批次发布。持续部署是把部署到生产环境的过程自动化；

• 持续发布是把一个/组特性提供给（部分或全部）客户的过程，在对用户可见的这个过程称为发布。持续发布是以持续部署为基础。

• 持续测试是贯穿整个研发流程始终的，从持续集成到持续部署，都有自动化测试的存在。

更多相关的内容可以点击持续交付与持续部署概念解读 进行学习。

策略

根据百度百科，“策略”是为了实现某一个目标，首先预先根据可能出现的问题制定的若干对应的方案，并且，在实现目标的过程中，根据形势的发展和变化来制定出新的方案，或者根据形势的发展和变化来选择相应的方案，最终实现目标。简单来说，策略就是解决问题。详细的说，策略就是为企业实现商业目标提供问题解决方案。

我们看几个关键词：目标、方案、形式的发展变化，即策略是动态变化的，一直以实现目标为核心。

发布策略

基于上面的解释，在制定发布策略时，首先需要有目标。敏捷软件开发理念的核心是敏捷宣言和敏捷原则，其中可以用来指导发布的有2条原则：

a) 我们最重要的目标，是通过及早和持续不断地交付有价值的软件使客户满意。

b) 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。

从大方向上来讲，所有企业的发布都是为了创造价值，也就是对应到上面敏捷原则a）中的最重要目标——尽早交付可工作的软件。“尽早交付”就是要缩短周期，减少时间，关于周期的长度，在敏捷原则b）中指出可以相隔几星期或者一两个月；“可工作”需要保证发布的质量，做好发布的风险控制。由此可见，发布策略的具体化目标应该是实现产品的高频低风险的发布。

其次，发布策略不是在即将发布的时候才制定，应该是项目计划阶段的一部分。由产品从研发到上线过程中的所有相关团队负责人共同讨论制定，内容是整个产品生命周期中的发布相关事宜，包括发布前、发布中和发布后三个阶段。发布前最重要的是发布计划，发布过程中监控和日志管理、问题应对方案，发布后的维护方案，整个内容要形成一份文档记录下来。

最后，在整个生命周期中，随着需求的变化，发布策略也会动态的随着项目同时改变，文档要做好同步进行更新和维护。

高频低风险的发布

理解了发布策略之后，下面我们主要介绍实现高频低风险发布目标的核心要素，发布分支和发布方法。

发布分支的选择

使用合适的发布分支，可以减少执行发布所需的时间，是高频发布的前提。团队要根据产品的类型、业务的发布周期要求、企业的自动化程度和团队的能力及特点来选择不同的分支策略。发布分支主要有主干发布和分支发布两种。

主干发布

主干发布就是用主干代码进行软件发布，所有新特性的开发，都提交到主干上，当需要发布的时候，直接把主干上的代码部署到生产环境。这样可以一直保持主干代码处于随时可发布的状态。

基于主干发布，团队可以选择主干开发和分支开发两种对应的模式。不论是那种开发模式，都要做到两点：一是早提交，要将代码尽早提交到主干，缩短开发分支的生存周期。因为分支周期越长，积累的代码数量就越多，在提交到主干分支的时候产生冲突的机会就越大，这样就会增加合并的时间。关于开发分支生存周期多短算是合适，业界说法不统一，在《持续交付2.0》中给出的意见是控制在3天以下，可以结合自己的业务情况做参考。实现短周期需要在最初需求拆分的时候做好规划，控制好需求的颗粒度；二是早同步，每个开发分支在工作过程中，要及时和主干代码进行同步，至少每天1次，这样可以减少最后合并过程中的代码冲突问题。

分支发布

分支发布是专门从主干上拉出一个发布分支，用于对外发布。这样可以在发布的同时，主干持续进行开发，不会受到版本发布的影响。新版本发布后出现缺陷，可以在发布分支修改后同步到主干，也可以在主干上修改后合并到发布分支。

使用分支发布的时候也要注意两点：一个是分支的存在周期不要过长，如果在发布分支上修改了缺陷，要及时同步到主干分支；二是不要从发布分支创建新的分支，所有的分支都应该来源于主干分支，保证代码源的唯一性。

综上所述，我们看到不论是主干发布还是分支发布，如果想实现高频低风险，重要的就是要做好三个控制：

一是控制分支数，越少越好，最好只有主干分支。

二是控制分支生存周期，越短越好。

三是控制发布周期，越短越好。软件发布频率越高，发布周期就越短。当达到了一定的发布频率时，就不需要发布分支了，主干发布即可。

常用的发布方法

开篇提到的蓝绿发布、滚动发布、灰度发布都是发布策略中常用的发布方法，可以降低发布风险，实现零停机发布，是发布策略中的核心内容。

蓝绿发布

蓝绿发布，是一种可以保证系统在不间断提供服务的情况下上线的部署方式。“蓝”和“绿”代表两套独立的环境，使用完全相同的主机集群，有两种使用策略：

• 一种是一套环境在线提供服务，一套环境闲置，准备用于下个版本的发布。

• 另一种是将两套环境都在线提供服务，可互为容灾。此时蓝绿两组主机工作方式如下：

1、无新版本发布时，蓝主机组和绿主机组同时对外提供服务；

2、当需要升级版本时，首先把蓝主机组从负载列表中摘除，进行升级，绿主机组依然对外提供服务；

3、蓝主机组升级完成，则将流量切换到绿主机组，同时将绿主机组从负载列表中删除，进行升级；

4、当蓝绿主机均完成升级，将绿主机组重新恢复至负载列表，两组主机重新同时对外提供新版本的服务。

图2 蓝绿发布

蓝绿发布的好处是可以实现零停机发布，可以实时升级和回退。不足是需要双倍的主机资源，而且切换是全量的，如果新版本有问题，则对用户体验有很大的影响。

滚动发布

滚动发布，是在发布的过程中先将一台或者几台主机停止服务，进行版本升级后重新提供服务。然后再选择下一批升级的主机同样操作，直到所有的主机都升级完成。

滚动发布的好处是用户体验影响小，体验较平滑。不足是版本在缓慢替换，发布和回退都比较缓慢；滚动升级期间，新老版本共存，如果发现问题，难以定位到底是新版本还是老版本的问题；滚动升级期间的流量控制对资源的要求比较高。

灰度发布

灰度发布是让一部分用户继续用版本A，一部分用户开始用版本B，如果用户对版本B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到版本B上面来。灰度发布是金丝雀发布的延伸，金丝雀发布是灰度发布的初始阶段。对于需要划分多少阶段，每个阶段的用户数量是多少，根据业务和产品具体情况进行制定。在下图中的内部用户可以看做是金丝雀用户。

图3 灰度发布

灰度发布的好处不需要进行停机，同时只有部分用户获取新版本，如果新版本出现问题，用户体验影响比较小，可以保证整体系统的稳定。不足是发布的时间会比较长；升级期间的流量控制对资源要求比较高。

其实，不论是哪种发布方法，降低发布风险的最佳方法就是真正地做发布演练，越频繁的将应用程序发布到不同的测试环境越好。这样就说明测试环境越可靠，从而在生产环境中发布时遇到问题的可能性就越小。

国内现状

高频低风险的发布已经成为了企业的主要趋势，根据云计算开源产业联盟发布的2021年《中国DevOps 现状调查报告》，国内企业部署频率为1周—1个月的占比超六成，相比2020年增长近一成。

图4部署频率现状分布

调查显示，仅有16.21%的企业能够每天多次在生产环境进行部署；此外，6.19%的企业平均1天到1周在生产环境部署一次；28.25%的企业平均1周到2周在生产环境部署一次；32.90%的企业平均2周到1个月在生产环境部署一次；部署频率超过1个月的企业占9.33%。

参考附录

1、Jez Humble. David Farley.持续交付：发布可靠软件的系统方法北京：人民邮电出版社。

2、乔梁.持续交付2.0：业务引领的DevOps精要.北京：人民邮电出版社。

3、《中国DevOps 现状调查报告（2021）》. 云计算开源产业联盟发布。

上云必读 DevOps 敏捷开发

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。