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