酷应用

跳出运维看运维：持续性交付，就是提升整个研发体系效率的关键 | 荐书

百家作者：InfoQ 2018-05-25 00:57:33

本文内容来自极客时间新书《进化：运维技术变革与实践探索》，十年运维老兵赵成对持续交付做了一个系统梳理。更多精彩内容，尽在他的运维新书中，带你直击运维本质。

作者：赵成

赵成，美丽联合集团技术服务经理，《进化：运维技术变革与实践探索》作者，《赵成的运维体系管理课》专栏出品人，公众号“Forrest随想录”作者，多届 ArchSummit运维专题明星讲师和优秀出品人，TGO会员，目前专注于云计算和人工智能时代的运维转型和提升。

为什么需要持续交付？

持续交付覆盖了应用的整个生命周期，涉及产品、开发、测试、运维以及项目管理等相关方面。从生命周期出发，自然就会牵出整个自动化的全貌，就会有从全局着眼的规划设计，这时无论是在开发还是运维过程中存在的问题，都会完完整整地暴露出来。

那么，应该以什么样的主线开展？各方应该如何配合？应该以怎样的优先级明确任务？这些问题就都清楚了。同时，也避免了各个环节只把注意力放在各自职责范围内的事情上，而忽略了整体的配合。所以，做好持续交付，对于整个研发体系意义重大。

持续交付代表着从业务需求开始到交付上线之后的端到端的过程。同时，还要有一些非常关键的准备工作，主要包括：配置管理、需求拆解、提交管理、构建打包、自动化测试以及部署发布。

配置管理

配置管理是持续交付的第一关键点。讲持续交付，一上来就先讲配置管理，主要还是想强调：配置管理是基础，是关键。我们后面将要讲的每一个持续交付环节，都对配置管理有很强的依赖。这个基础工作做不好，也就谈不上的持续交付的成功。

按照持续交付的理念，这里所说的配置管理范围会更广，主要有以下几个部分。

版本控制

版本控制的主要作用是保证团队在交付软件的过程中能够高效协作，版本控制提供了一种保障机制。

依赖配置

这里以 Java为例，我们使用 Java进行开发，必然会依赖各种第三方的开源软件包。同时，内部还会有不同组件的二方包。这些三方包和二方包就是一个应用编译和运行时所依赖的部分。

对于 Java来说，我们熟知的依赖管理工具有 Ant、Maven和 Gradle。

软件配置

这里我把软件配置细化为两类：一类是代码配置，一类是应用配置。

代码配置是跟代码运行时的业务逻辑相关的。比如应用的服务接口、并发线程数、超时时间等这些运行时参数；还有类似于业务或技术上的开关，比如商品评论是否开放、优惠时间段设置等等。

应用配置就是 应用这个对象的属性和关系信息。

从区别上讲，我们可以认为代码配置是跟业务或代码逻辑相关的，动一下就会改变系统执行状态，是运行时的配置，但不依赖周边环境。而应用配置，是跟业务和代码逻辑无关的，不管你怎么动，业务逻辑是不会改变的，但是它跟环境相关。

环境配置

环境配置管理，就是不同环境中的应用配置管理。环境配置是我们在持续交付过程中要关注的重中之重，也是最为复杂的一部分。

多环境配置管理

环境配置管理主要是针对应用对基础设施和基础服务依赖关系的配置管理。

我们通过一个简化了的场景来做示例，讨论环境配置管理的解决方案。

假设现在有三个环境：

开发环境
预发环境
线上环境

继续假设某应用有配置文件：config.properties，里面存储了跟环境相关的配置，简化配置如下：

缓存地址：cache.app.url
消息地址：message.app.url
数据库地址：db.app.url
支付调用地址：pay.url
支付调用 Token：pay.app.token

这里，我提供三个解决思路。

方案一，多个配置文件，构建时替换。
方案二，占位符（PlaceHolder）模板模式。
方案三，AutoConfig方案。

线下多环境建设

线下环境最初建设的时候，主要是提供给测试使用，帮助其建立一个模拟环境，在软件发布上线前进行需求功能验证，保障业务流程顺畅，以确保应用在上线前达到最低质量要求。

一般来说，我们在线下环境区域内，建设三套环境。

集成测试环境

主要供测试使用，这个环境会最大程度与线上版本保持同步。作为对应用的功能、需求、业务流程等在正式发布上线进行验证的主要环境，集成测试环境的稳定性和可测试需要加强保障，进行全套建设。同时，作为整个线下环境的中心节点，也要为开发测试环境和项目环境提供部分依赖服务。

开发测试环境

主要供开发人员使用，针对偏日常的需求开发、联调和功能验证，以最小化原则进行建设，但是一般情况下不对资源进行回收。

项目环境

供开发和测试共同使用，针对多团队多人员协作的项目型场景，可以同时存在多个项目环境，在这个环境中针对项目需求进行独立开发、联调和验证。测试也需要提前介入这个环境进行基本功能的验收，并遵循最小化的建设原则，但是要有生命周期，即项目启动时分配资源，项目结束回收资源，不能无限期占用。

线上环境建设

线上环境建设主要包括 生产环境、Beta环境、预发环境和办公网生产环境这四种。我们简单构建一张模型图来对线上环境作个展示：

持续交付中的流水线模式

从一个应用的代码提交开始，到发布线上的主要环节，整个流程串起来就是一个简化的流水线模式。如下图所示：

项目需求分解

比较通用的做法，就是要求业务架构师在做需求分析和功能设计时，要针对一个需求进行拆分，最终拆分成一个个的功能点，这些功能点最终落实到一个个对应的应用中，对应的逻辑体现就是应用代码的一个分支。

开发模式选择原则

一看这几种模式的适用场景；

二看我们实际的使用场景是怎么样的。

持续交付流水线软件构建

我们以 Java为例，来介绍构建环节。

构建过程中我们要用到以下 4种工具：

Gitlab，代码管理工具，也是版本管理工具；
Maven，依赖管理和自动化构建工具，业界同类型的工具还有 Gradle等；
Docker，用来提供一个干净独立的编译环境；
自动化脚本和平台，自动化构建的任务我们使用 Python脚本来实现代码获取、编译执行、软件包生成等。

具体整个构建过程图示如下：

质量保障

在持续交付过程中，我们还要做很多与质量保障相关的工作。

依赖规则限制

主要是对代码依赖的二方包和三方包做一些规则限制。比如，严格限定不允许依赖 snapshot版本；不允许引入有严重漏洞的版本，如 struts2的部分版本；检测 jar包冲突，如我们常用的 netty、spring相关的包；限定某些软件包的最低版本发布，如内部提供的二方包，以确保版本收敛，降低维护成本。

功能测试和非功能测试