二、持续交付篇

本系列教程是学院君在极客时间学习赵成的运维体系管理课记录的学习笔记，希望对有这方面需求的同学有所启发，如果想要深入了解细节可以去极客时间订阅该专栏。作者介绍：赵成，美丽联合集团技术服务经理。

为什么要做持续交付

想要前面提到的运维基础建设发挥出更大的作用和价值，就需要针对运维场景进行场景化设计和自动化，在这一阶段，首先要把持续交付做好。

持续交付是提升整个研发体系效率的关键。

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

持续交付代表着从业务需求开始到交付上线之后的端到端的过程。

配置管理->需求拆解->提交管理->构建打包->自动化测试->部署发布

配置管理、提交管理、构建和部署发布是持续交付的重中之重，是关键路径，是从开发代码开始，到发布上线的必经之路。

推荐书目：《持续交付：发布可靠软件的系统方法》

配置管理

版本控制

依赖配置

软件配置

• 代码配置：跟代码运行时的业务逻辑相关（qconf）
• 应用配置：应用这个对象的属性和关系信息（语言、仓库、目录、启停脚本、健康检查、与基础组件关联关系）

环境配置

不同环境中的应用配置管理

多环境配置管理

开发环境、集成环境、预发环境、Beta环境、线上环境

线上线下环境应该严格隔离

不同环境下的应用配置管理

• 应用属性信息
• 应用与基础组件依赖关系

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

环境配置管理解决方案

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

持续交付中的流水线模式

需求拆解

开发模式（分支管理）

• 主干开发模式（master）
• gitflow开发模式（develop release master）
• 分支开发模式（feature/bug release master）✔︎

代码评审

构建环节

代码编译打包：静态语言如 Java/C/C++/Go 需要编译，动态语言如 PHP 只需打包即可。

以 Java 为例：

• Gitlab：代码管理工具
• Maven/Gradle：依赖管理和构建工具
• Docker：用于提供干净的编译平台
• 自动化脚本和平台：将上述流程串起来的脚本

编译打包后的软件包就可用于发布到不同环境了，如测试、预发、线上等。

质量保证

• 规则限制：版本检测、代码提交检测、包依赖及维护升级
• 功能测试：单元测试、接口测试、联调测试、集成测试（后两者主要依赖人力操作）
• 非功能测试：安全审计（源码扫描：XSS、CSRF、SQL注入、木马等）、性能测试和容量评估（压测）

流水线完整过程：

源码扫描工具：https://github.com/wufeifei/cobra

软件的持续部署发布

将构建完成和验证通过的应用软件包，发布到该应用对应环境下的 IP 主机上的指定目录下，并通过应用优雅上下线，来实现软件最新版本对外提供服务的过程。

注：与服务化的软负载和注册中心进行交互，确保应用是可以优雅上下线的，而不是简单粗暴地启动和停止

以上是单机发布，集群发布怎么做？

灰度发布 + 分批次发布

• 灰度发布：保留 1-2 台应用主机，引入较少的线上真实用户流量进行监控
• 分批次发布：即每批次发布 10 台或 20 台，升级完成后，再启动下一批次发布

持续交付体系运作起来后，整个流水线过程完全自助发布，运维无需介入，达到了 DevOps，或者说是 NoOps 的效果。

本系列教程导航索引：

• 赵成的运维体系管理课学习笔记系列（一） —— 基础设施篇
• 赵成的运维体系管理课学习笔记系列（二） —— 持续交付篇
• 赵成的运维体系管理课学习笔记系列（三） —— 云计算篇
• 赵成的运维体系管理课学习笔记系列（四） —— 稳定性实践篇
• 赵成的运维体系管理课学习笔记系列（五） —— 故障管理篇