当前位置: 首页 > 关于新炬 > 新闻资讯 > 正文

有了DevOps持续交付,还需要应用发布吗?

2021-08-05 14:21:55
一、为什么要聊这个话题?

 

有太多的朋友问过我持续交付(简称CD)与应用发布的问题,发现大家常常会混淆两者的概念,常见的问题例如:

 

  • CD是不是等于应用发布?

  • CD的概念已经涵盖了部署,是不是可以理解为CD包含应用发布?

  • 我们已经具备了CD自动化能力,为什么还要建设应用发布的能力?

 

因此针对这些问题,谈一谈我的浅见。

 

二、持续交付与应用发布的定义
 

持续交付(Continuous delivery)指的是频繁地将软件的新版本,交付给质量团队或者用户,以供评审。如果评审通过,制品(也就是常说的程序包)就进入生产阶段。

 

应用发布(Release)指的是将线上流量转移到新版本的过程。这个过程与上线新的制品所有风险有关,例如:发布失败会导致服务中断、会影响用户使用而被投诉等等。

 

\

 

通过上图简单区分,胜过千言万语,CD与应用发布分别处于软件生命周期的开发测试阶段与运维阶段,那么有些朋友可能会疑惑,开发/测试阶段的部署,运维阶段的发布,是不是一个意思呢? 或者说部署的对象是测试环境,发布的对象是生产环境?在这里通过两幅图简要说明一下,帮助大家理解。

 

部署(Deploy)指的是在指定环境的基础设备中安装新版本服务的过程。部署不需要向用户提供新版本的服务,如下图:

 

\

 

发布(Release)不仅需要把新版本服务安装到指定环境,更重要的是让用户体验新版本的服务,可以简单理解为发布=部署+流量控制,如下图:

 

\

 

这里用图帮大家区分发布与部署,由于不是本文的主题,这里不再累述。

 

三、CD与应用发布的差异
 

 
1、从作用范围角度上看

 

CD主要作用在开发测试域,支撑需求设计、开发、测试等人员的软件交付工作。

 

应用发布主要作用在生产域,支撑运维人员的软件交付工作。

 

 
2、从能力要求上看

 

我们以一个业务系统A为例,如下图:

 

系统A由产品服务、订单服务、用户服务组成。

 

\

 

CD面向的就是服务,强调标准化的过程提高服务交付的效率与质量,这个过程包括需求代码—编译打包—部署—测试验证—提交生产等。服务之间互不影响,可独立变更。

 

应用发布是面向业务系统的,把通过审核的服务组合在一起,按照一定的先后顺序安装到生产环境并让用户体验;强调的是服务之间版本的匹配是否正确。

 

有朋友可能会问,为什么还要组合呢?直接上生产不就好了,也不复杂啊。但试想一下,如果一个业务系统由10+,20+服务组成呢?(我遇到过由50+服务组成的业务系统,不要低估企业业务的复杂性),如果需要管理100+业务系统呢?更复杂的情况是业务系统之间还有依赖呢。

 

对于不太了解DevOps领域的朋友,是不是依然觉得比较抽象,不好理解?下面,我用造车再做个比喻吧。

 

CD就是汽车组件(服务)生产线,例如轮胎、座椅、车门、发动机等等,每一条生产线都是标准化的,生产线之间是互相独立的,相互不影响。那么轮胎、座椅的好坏取决于原材料(源代码)质量与加工技术(软件架构、算法等)的先进性。

 

应用发布就是整车(业务)的组装流水线,例如不同的汽车(不同的业务)奥迪、奔驰,不同的型号A4、 A6、GLS、GLK(不同版本),组装过程必定是有差异的,这就需要组装线条支持灵活配置,以应对业务变化的需要。 

 

聊到这里,相信朋友们对应用发布的定义已经有了比较清晰的理解,那么,应用发布应该具备哪些自动化专业能力? 我们从应用发布工作模式开始说起。

 

四、应用发布工作模式
 

当前应用发布工作模式,如下图:

 

\

 

发布当晚,业务验证、中间件、数据库、开源组件、配置管理、流量控制、监控管理等等相关事项都要留下实施人员,由发布管理者居中协调,统一安排,大家风风火火地拼搏一通宵,保障顺利上线,然后回家美美睡上一天。然而这只是最好的情况,过程中一旦稍有不慎,就是鸡飞狗跳,甚至版本回退,一地鸡毛,更别说回家睡觉了。

 

这种发布模式,对企业而言不仅人力投入大,业务停机时间长,还容易造成误操作;对个人而言,长期以往会造成工作过劳,生物钟混乱,影响健康。

 

那我们看看一些大企业的应用发布工作模式,如下图:

 

\

 

如果我们把程序包、DB、配置文件、流量切换等实施工作分别封装成可以自动化的最小单元,那么在生产发布之前,我们就可以把所有的实施操作预先编排成待执行的流程,如此中间件、数据库、开源组件、配置管理、流量控制等环节的实施人员就可以不用参与到发布工作中来,从而大大减少对这些专业团队的依赖,缩减了发布人员的的沟通范围。

 

接下来通过专家审核把控编排流程的质量,由管理人员分配待发布任务,就可以合理的把发布过程中不同角色的职责解耦开,让大家不必要扎堆一起干活。

 

注意这里的发布编排与发布审核不影响生产业务,是可以在5*8的正常工作时间里开展的,所以说专家和管理人员也可以从通宵工作中释放出来。

 

这样一来,发布当晚只需要留下少数人员,一键触发发布流程即可,有问题才呼叫专家,甚至对于比较稳定的系统,直接交给服务台触发流程都可以。

 

如此,大量的专业人员不需要扎堆通宵发布,正常工作时间完成编排/审核即可;管理人员也不用担心找不到问题原因,因为流程会留下详细的记录;发布执行人员不用担心命令过多或者过于繁杂,因为只需一键触发流程。这样不但解决了通宵人力投入过大的问题,也解决了容易误操作的问题,还可以大大降低发布人员技能门槛,避免过度依赖于专家。

 

五、自动化发布能力
 

当然要做到这种模式的应用发布,只是依靠人力肯定不行的,需要有专业的自动化发布能力支持才行,具体需要什么专业能力?我们根据工作模式分析如下:

 

1、版本闭环管理:支持新版本关联上载—按版本配置—版本更新—旧版本备份/归档的版本生命周期管理,实时掌握生产系统版本的最新状态。

 

2、发布能力:支持制品、配置文件、SQL等基础发布能力,避免线上线下交叉实施,支持流量控制、告警控制、工单等快速对接。

 

3、仓库管理:支持制品包、配置文件、SQL脚本、容器镜像等发布物料的统一存储、清理策略等。

 

4、发布流程编排:支持一条流水线编排业务系统所有服务组件的能力,例如后端服务Jar、C/C++、Tomcat等;前端服务Nginx;容器镜像;DB变更脚本;配置文件变更;流量控制等等。

 

5、发布任务管理:支持发布流程编排人员(可以是开发、测试或者运维人员)、发布流程审核人员(可以是运维专家、运维管理人员)、发布执行人员(可以是一线运维或者服务台值班人员)的职责分工与任务传递。

 

当然,我们这里只是聊一聊专业能力,从平台角度看,高可用、高并发也是要考虑的,本文就不做展开了。

 

聊到这里,可能有朋友会问,这个工作模式可以把专家、管理人员从苦海中解救出来,那测试验收怎么办,能一并解救吗?

 

当然是有办法的,灰度、蓝绿就能解决,虽然有一定的限制条件,但办法总比问题多,我们下回分解。

上一篇:新炬网络助力某城商行落地全生命周期SQL质量管理,践行数据库DevOps
下一篇:新炬网络助力中国信通院编制智能运维(AIOps)能力成熟度模型系列标准,驱动企业IT运维效能提升