版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/sunxiaoyu94/article/details/88934617
16 | 持续交付知易行难，想做成这事你要理解这几个关键点
什么是持续交付
首先要把持续交付做好。
做持续交付就是提升整个研发体系效率的关键。
持续交付代表着从从业务需求开始到交付上线之后的端到端的过程。
业务/产品——开发——测试——运维：持续交付
开发——测试：持续集成
开发——运维：DevOps
业务/产品——测试
持续交付的关键点
- 配置管理
标准化是一个持续的过程 - 需求拆解
- 提交管理
- 构建打包
- 自动化测试
- 部署发布
17 | 持续交付的第一关键点：配置管理
-
版本控制
举例：svn & git
-
依赖配置
举例：Maven, Ant
- 仓库管理
- 依赖管理
- 构建打包
-
软件配置
-
代码配置：代码配置是跟代码运行时业务逻辑相关的。
-
应用配置：应用配置就是应用这个对象的属性和关系信息。
- 应用构建时配置：编程语言，git地址，构建方式
- 应用部署时配置：源代码目录，应用日志目录，web日志目录，临时目录，脚本目录
- 应用的运行配置：应用启停，服务上下线方式，健康监测方式等
- 应用运行时与基础组件的关联关系：比如依赖的DB、缓存、消息以及存储的IP地址、域名、端口、用户名或Token等。
-
两者区别：代码配置和业务或代码逻辑相关，应用配置和业务和代码配置无关。
-
-
环境配置
不同环境中的应用配置管理。
18 | 如何做好持续交付中的多环境配置管理？
多环境问题
- 开发环境
- 集成环境
- 预发环境
- Beta环境
- 线上环境
不同环境下的应用配置管理
- 应用属性信息
- 应用对基础组件的依赖关系
环境配置管理主要是针对应用对基础设施和基础服务依赖关系的配置管理
环境配置管理解决方案
- 方案一：多个配置文件，构建时替换
- 方案二： 占位符（PlaceHolder）模板模式
- 方案三： AutoConfig方案
推荐的解决方案：基于AutoConfig做一下二次开发，将配置项做到一个管理平台中，针对不同环境进行不同值的管理，然后根据AutoConfig的规则，在变更后生成对应不同环境的配置文件，然后再结合AutoConfig针对配置管理文件的能力，这样就可以很方便地做多环境的软件包构建了。
19 | 开发和测试争抢环境？是时候进行多环境建设了
环境分类
- 线下环境
- 线上环境
线下环境分类建设
- 线下环境区域内，建设的第一个环境是集成测试环境。
- 线下的第二套环境：开发测试环境。
- 解决冲突，第三套环境：项目环境。
环境建设上的关键技术点
维护工作量大。
- 网段规划
- 服务化框架的单元化调用
- 环境的域名访问策略
- 自动化管理
20 | 线上环境建设，要扛得住真刀真枪的考验
生产环境
即使有影响，也要把它控制在小范围内，或者是在萌芽状态时就发现。这样就可以提前处理，而不是全量发布到生产环境后才发现问题，影响全局。
Beta环境
模拟真实。
预发环境
办公网生产环境