带你了解敏捷和DevOps的发布策略

原创
2021/11/30 11:11
阅读数 3.9K
摘要:随着数字化、信息化、网络化和智能化的普及和发展,企业对软件服务的质量和上线速度要求越来越高。传统研发模式难以满足要求,企业的开发运维模式逐渐向敏捷和DevOps 转型,敏捷和DevOps理念正被广泛认可并加速落地实践。

本文分享自华为云社区《一文读懂敏捷开发的发布策略》,作者:敏捷的小智。

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

什么是发布策略

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

发布

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

图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)》. 云计算开源产业联盟发布。

 

点击关注,第一时间了解华为云新鲜技术~

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
0 评论
2 收藏
0
分享
返回顶部
顶部