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