我们使用puppet来分发我们自己的软件（也就是我们写的东西，我们要在自己的服务器上运行）。 所以我们必须编译这个软件。
对我来说，我可以把它拉到木偶大师身上，这是有道理的。 编译一次，分发，我们的机器是同质的，二进制文件运行在他们的受膏主机上。
但是当我们升级主机时，各种库将会改变，我们可能会发现自己需要重新编译新的库集。
看来是正确的做法是打包我们的软件，把这些软件放到我们自己的地方，然后在木偶中使用软件包指令。
Q1：这听起来不错吗？我错过了一些重要的东西吗？
Q2：那么deb是如何打包上传的？ 这是一个手动释放过程吗？ 这意味着我们将testing服务器升级到新的操作系统和库版本，以便进行编译和打包。
Q2B：现在假设我安装了CI服务器，我一直告诉我的团队我会安装。 据我所知，CI服务器对dist-upgrades一无所知。 那么这个部分必须保持手册吗？
您的构build过程可以是手动的，也可以通过CI自动化，通过一些触发器。 例如（这只是一个例子），你可以在Git中标签一个新的版本，或者移动一个现有的标签，你的CI应用程序监视这个版本库或者标签，并且构build/上传你的包。
您的发布程序也可以是手动或自动的。
package资源上使用ensure => latest ，这样一旦将包发布到你的资源库，它们就会被你的节点拾取和安装。 ensure => 'xyz'将一个包ensure => 'xyz'到一个特定的版本。 使用这种方法，您可以在特定节点/angular色/环境中手动打击版本。 您可以采用混合方法，通过使用hiera和参数化模块来组合上述两者 – 例如，您可以确保latest的开发/构build环境以及生产环境中的xyz 。
您可以完全从等式中删除Puppet，并使用Capistrano等工具进行手动发布。
一个单独的解决scheme完全是利用持续交付和对待你的服务器牛，并完全重新configuration他们每个版本 – 见马丁福勒的博客欲了解更多信息。
重要提示： 构build和发布过程最好是完全独立的，不应该交互，尽pipe成功的构build可能会触发向UAT环境的自动发布，然后使用手动/不同的发布过程进行生产。