14、基础设施管理与测试实践指南

基础设施管理与测试实践指南

1. 持续交付与持续部署

持续交付（CD）常被误解为每次提交的更改在通过自动化测试后立即应用于生产环境。实际上，虽然有些采用持续交付的组织确实采用这种持续部署方法，但大多数并非如此。持续交付的重点不是立即将每个更改应用于生产环境，而是确保每个更改都可以应用。

持续交付使是否以及何时将更改应用于生产环境的决策成为业务决策，而非技术决策。将更改推送到生产环境并非具有破坏性的事件，无需团队停止开发工作，也不需要项目计划、交接文档或维护窗口。它只是重复在测试环境中多次执行和验证过的过程。

对于 IT 运维团队而言，持续交付意味着对基础设施的更改在进行时会得到全面验证。用户所需的更改，如向生产环境添加新服务器，无需 IT 运维团队参与即可完成，因为他们确切知道有人点击按钮将 Web 服务器添加到 Web 服务器池时会发生什么。

2. 基础设施管理的版本控制系统（VCS）

2.1 VCS 管理内容

在 VCS 中，应将构建和重建基础设施元素所需的一切内容进行版本控制。理想情况下，若整个基础设施消失，仅保留 VCS 中的内容，就可以检出所有内容并运行一些命令来重建一切，必要时还可引入备份数据文件。以下是需要进行版本控制的内容：
- 编译实用程序和应用程序的脚本和源代码
- 配置文件和模板
- 配置定义（如 Cookbooks、Manifests、Playbooks 等）
- 测试

不需要在 VCS 中管理的内容包括：
- 软件工件应存储在仓库中，如 Java 工件的 Maven 仓库、apt 或 yum 仓库等。这些仓库应进行备份