我们正在尝试在我们的环境中实现持续集成管道。我们有很多不同的服务，每个服务都有自己的 Git 存储库。部署是通过 Puppet 完成的，使用外部节点分类器来确定要将哪些类部署到每种主机类型。Puppet 文件位于它们自己的 Git 存储库中，如下所示：
只是，它不只是 3 个服务，而是 100 个。所以 Puppet 项目是一个包含多个清单的庞大整体，当然它位于自己独立的 Git 存储库中。
现在，我来负责为 CI 设置一个模式，这样当有人请求将某个分支（比如说服务 A）合并到主分支时，我们就能够启动 CI 构建，启动虚拟环境，将服务 A 部署到一些虚拟机，并确保新分支通过所有自动化测试。当然，问题在于，要部署服务 A 的新版本，我不仅必须构建它，还必须更新 Puppet 清单以引用新版本……而且 Puppet 文件位于完全独立的存储库中，而不是我的分支中。因此，我没有任何简单的方法告诉 Puppet Master，对于这分支，我们需要使用 CI 构建，而不是主版本。
我并不是第一个想要为这样的环境设置 CI 的人，但我在网上搜索过解决方案，却一无所获。也许我使用了错误的搜索词。
有人能建议一个合适的设计模式，使我能够为所有服务存储库实现 CI 吗？
答案1
我认为最简单（但不一定是最佳）的方法是设置一些东西，要求 CI 构建测试环境，它需要匹配分支名称或其他东西。这将迫使开发人员在 Puppet 代码中创建一个分支来部署他们的构建版本。
有效地：
- 开发人员 Dave 根据工单创建了一项服务的新功能分支：例如
feature/JIRA-999-some-task - Dave 推送了他的代码
- CICD 检测到新分支或 PR 等，开始运行
- 管道阶段寻找相同的Puppet 仓库中的分支名称
- 如果分支不存在，管道将出错并告诉 Dave 去创建分支
- 如果它确实存在，也许至少添加一些验证来检查它是否已被改变？
- 测试运行
- 测试通过，每个人都很高兴
这不是一个容易解决的问题，并且这种方法必须确保开发人员知道在哪里更新版本（也许在 Hiera 数据文件中？）。
我认为唯一可行的方法是向容器化等方向进行更大规模的转变，这样你就可以用 Puppet 管理一层（基础设施），然后在顶层部署容器。然后，你可以为开发人员提供部署容器的工具，同时保留对平台的控制权。
最后一个随机想法 - 您是否可以在云中做一些测试，以避免将 Puppet 代码用于除生产/暂存之外的任何用途？或者以某种方式利用基于云的 Puppet？
答案2
这里的挑战是代码与部署脱节。
我的方法是将 Git 提交哈希传递给 Puppet，然后 Puppet 将使用该提交哈希来获取要部署的代码。但是，我不知道 Puppet 是否支持将此类参数传递给作业。
在实际代码库的检出阶段，哈希值将被记录并传递给 Puppet。