[置顶] 持续交付之二——配置管理

其他持续交付相关文章：《持续交付》系列文章目录

第二章 配置管理

1. 引言

定义: 配置管理是指一个过程, 通过该过程, 所有与项目相关的产物, 以及他们之间的关系, 都被唯一的定义, 存储, 检索和修改

2. 使用版本控制

2.1. 对所有内容进行版本控制

至少要将那些用于重新创建应用程序的安装文件和安装环境所必需的所有信息保存在版本控制库中，包括

• 代码
• 文档
• 工具
• 构建环境的信息

持续集成，自动化测试，一键式部署的前提都是所有与项目相关的内容都在版本控制库中

2.2. 频繁提交代码到主干

两个最佳实践

• 提交之前运行自动化测试
• 增量式引入变化，改一点提交一点

2.3. 使用意义明显的提交注释

包括下面三个部分

• 总结性描述
• 细节性描述
• 相关问题或者bug的链接

3. 依赖管理

3.1. 外部库文件管理

3.2. 组件管理

关于依赖管理更多的会在第十三章 组件和依赖管理中进行讨论

4. 软件配置管理

4.1. 配置与灵活性

就像性能调优一样，没又遇到性能问题时不要过早优化，配置也是同样道理，除非真的需要，否则没必要增加复杂性

4.2. 配置的分类

我们可以在构建，部署，测试和发布过程中任何一个阶段引入配置

不建议在构建打包时引入配置，应该保证部署之前所有的包是一样的

4.3. 应用程序的配置管理

1. 获取配置信息

让所有应用程序通过一个中央服务系统（关系数据库，LDAP，Web服务等）得到他们所需的配置信息

ESCAPE工具

1. 为配置项建模

一个配置项取决于三个方面

• 应用程序
• 应用程序的版本

• 运行环境（开发，测试，生产）

  1. 系统配置的测试

• 保证外部服务都开启

• 对与配置项相关的功能进行自动化的冒烟测试

4.4. 跨应用的配置管理

每个应用程序的配置管理都应该在项目启动时纳入一个议题

4.5. 管理配置信息的原则

• 确定注入配置的时机
• 配置项和配置值分开存储
• 总是自动化获取配置
• 每个人应该都能容易的获取当前应用当前版本在当前环境下的配置信息
• 命名简单易懂
• 确保配置信息修改的模块化，改一边不会影响另一边
• 不要重复定义配置项
• 最少化配置
• 避免过分设计
• 确保对配置操作也有测试

5. 环境管理

关键在于全自动的创建一套环境，使创建环境比修复受损环境要容易的多

为什么需要重现环境的能力

• 避免人员离职产生的知识遗失
• 修复时间往往大于重建环境的时间
• 可以保持各个环境的统一

需要考虑的环境配置信息如下

• 操作系统（版本，补丁级别和配置设置）
• 第三方包（版本，配置）
• 网络拓扑
• 所依赖的外部服务（版本，配置）
• 现有的数据及其他相关信息

为了符合我们的管理策略，评估第三方产品或服务时，应该考虑下面的问题

• 是否可以自动部署
• 是否可以对配置做版本控制
• 是否能适应我们的自动化部署策略

5.1. 环境管理工具

Puppet，CfEngine，虚拟化技术等

更多讨论在第十一章 基础设施和环境管理

5.2. 变更过程管理

严格控制生产环境，未经组织内部正式的变更管理过程，任何人不得对其进行修改

6. 小结

配置管理是一切自动化的基础