关于管理厨师食谱版本的一般最佳实践是什么，以便与食谱要供应和配置的应用程序版本保持一致？
如果我正在为特定应用程序版本的配置自动化构建我的说明书 - 我需要将应用程序版本的一些相关性带入我的说明书版本吗？如果不是，那么说明书版本如何与应用程序版本相关联？
升级后的应用程序可能包含需要更改现有说明书的其他组件或配置更改。如果没有将说明书版本映射到应用程序版本的机制，供应给定的应用程序版本将是一个挑战。
所有关于如何管理的想法都值得赞赏？
【问题讨论】：
标签： chef-infra cookbook
当我们开始 Chef 之旅时，我们也有类似的担忧。我们的应用程序是通过基于 Jenkins 的管道构建的，其中构建编号由 Jenkins 分配。换句话说，我们的应用程序不使用 SemVer。迁移到 SemVer 对我们来说将是一项巨大的努力。由于您指出的原因，提供这些应用程序及其托管环境的厨师食谱需要有一个清晰的直观映射。我们发现使用 SemVer 方案管理食谱并让他们交付/配置的应用程序使用非 SemVer 方案让我们的用户感到困惑。在理想的世界中，我们会将所有内容都转移到 SemVer，但我们现在不是我们的选择。我们决定让我们的食谱通过相同的 Jenkins 管道并与应用程序代码并置，并在带有 Jenkins 内部版本号的 metadata.rb 文件中使用相同的自动化流程标记。陪审团仍不清楚这将如何长期运作，但我们已经这样做了将近一年，尽管有一些粗糙的边缘，但它似乎运作良好。
我只是将我们的方法分享为一种方式。我不确定我是否喜欢它来提倡将其作为一般的最佳实践，但我认为这对我们来说是轻而易举的事情。如果您决定走这条路，请花时间了解 berks（或 policyfiles）cookbook 版本解析以及 Chef Server 版本解析的工作原理 - 这将为您省去一些麻烦。
【讨论】：