28、Puppet 代码部署与 Bolt 编排指南

Puppet 代码部署与 Bolt 编排指南

1. 代码部署工作流

在代码部署过程中，有两种常见的工作流方法。

1.1 以控制仓库作为版本的中央把关者

这种方法将控制仓库作为版本的中央把关者，Puppetfile 中的每个模块声明都有特定版本，通常会用特定引用（如标签、提交或分支）更新最低级别的环境。这些更改在功能分支中进行测试，然后通过将更改从一个分支合并到下一个分支，在服务器上运行代码并确认预期结果，逐步推广到各个环境。具体步骤如下：
1. 创建控制仓库的功能分支，并将 module1 的标签版本从 1.1 更新到 1.2。
2. 将功能分支与开发分支合并并部署开发环境。
3. 将开发分支与 UAT 分支合并并部署 UAT 环境。
4. 将 UAT 分支与生产分支合并并部署生产环境。

这种方法并非自然的 Git 工作流，不使用主分支，非常注重部署，需要更多的环境管理。对于多个团队来说，这种方法可能特别困难，因为需要一个把关者（如 Puppet 平台团队）来管理 Puppetfile 控制仓库的更改，并安排代码部署的时间表。如果采用这种方法，建议使用前缀配置设置创建多个控制仓库，这对于想要使用不同模块集（如 Windows 和 Linux），或者想要对控制仓库进行隔离和保护，并分别拥有代码和服务器但共享基础设施的团队很有用。

1.2 控制仓库依赖模块本身

这种方法将控制仓库中的 Puppetfile 中的所有模块设置为使用 control_branch 分支，默认使用 main 分支。Puppetfile 的维护只涉及模块的添加和删除，版本管理将在模块本身进行。代码更改从