我们使用 puppet 来分发我们自己的软件（即我们编写的、希望在自己的服务器上运行的东西）。因此我们必须在某个地方编译这个软件。
对我来说，我可以使用 git pull 并在 puppet master 上编译它。编译一次，分发，我们的机器是同构的，二进制文件在其指定的主机上运行。
但是当我们升级主机时，各种库都会发生变化，我们会发现需要重新编译新的库集。
似乎正确的事情是打包我们的软件，为我们自己提供这些 deb，然后只需在 puppet 中使用打包指令。
问题 1：这听起来对吗/我是否遗漏了一些重要的东西？
问题2：那么 deb 是如何打包和上传的？这是一个手动发布过程吗？这意味着我们将测试服务器升级到新的操作系统和库版本，以便进行编译和打包。
Q2B：现在假设我安装了那个 CI 服务器，我一直告诉我的团队我会安装它。据我所知，CI 服务器对 dist-upgrades 一无所知。那么这部分是否必须保持手动？
答案1
你的构建过程可以通过 CI 手动或自动执行，通过多个触发器。例如（这只是一个例子），您可以在 Git 中标记新版本，或移动现有标记，然后您的 CI 应用程序会监视该存储库或该标记，并构建/上传您的包。
你的发布程序也可以是手动的或者自动的。
ensure => latest在您的 Puppet资源上使用package，这样一旦您将包发布到您的存储库，它们就会被您的节点拾取并安装。- 用于
ensure => 'x.y.z'将包固定到特定版本。使用此方法，您可以手动更改特定节点/角色/环境上的版本。 您可以采用一种结合上述两种方法的混合方法，即使用 hiera 并参数化您的模块 -例如，您可以确保
latest您的开发/构建环境以及生产环境。x.y.z你可以完全移除 Puppet，使用以下工具进行手动发布：卡皮斯特拉诺。
一个完全独立的解决方案是利用持续交付，并以牛的方式处理你的服务器，并在每次发布时完全重新配置它们 - 请参阅Martin Fowler 的博客了解更多信息。
重要的提示：这建造和发布理想情况下，各个过程应该完全独立，不应相互影响，尽管构建成功可以例如，触发自动发布到 UAT 环境，然后使用手动/不同的发布程序进行生产。