基础设施管理中的软件开发实践与测试策略
1. 持续交付与持续部署
持续交付(CD)常被误解为每次提交的更改在通过自动化测试后立即应用到生产环境。实际上,多数采用持续交付的组织并非如此。持续交付的重点是确保每个更改都具备可应用的条件,而非立即应用到生产环境。它将是否以及何时将更改应用到生产环境的决策变成业务决策,而非技术决策。向生产环境推出更改不会干扰开发工作,无需项目计划、交接文档或维护窗口,只需重复在测试环境中多次执行并验证过的流程。
对于 IT 运维团队而言,持续交付意味着对基础设施的更改会在进行时得到全面验证。用户所需的更改,如向生产环境添加新服务器,无需 IT 运维团队参与,因为他们清楚点击按钮添加 Web 服务器到服务器池时会发生什么。
2. 用于基础设施管理的版本控制系统(VCS)
2.1 VCS 中管理的内容
即使是有 VCS 使用经验的开发者,也需思考基础设施团队应在 VCS 中管理哪些内容。应将构建和重建基础设施元素所需的一切纳入版本控制。理想情况下,若基础设施消失,仅依靠 VCS 中的内容,通过检出文件并运行几个命令,再按需引入备份数据文件,就能重建一切。
以下是需要进行版本控制的内容:
- 编译实用程序和应用程序的脚本和源代码
- 配置文件和模板
- 配置定义(如 Cookbooks、Manifests、Playbooks 等)
- 测试
不需要在 VCS 中管理的内容包括:
- 软件制品应存储在仓库中,如 Java 制品的 Maven 仓库、apt 或 yum 仓库等,这些仓库应备份或有可重建它们的脚本(存储在 VCS
超级会员免费看
订阅专栏 解锁全文
500

被折叠的 条评论
为什么被折叠?



