Question

我有多个部署的CHEF烹饪书。每个都根据语义版本控制进行版本控制。

我的生产环境正在使用食谱0.1.1
我的舞台环境是使用cookbook 0.2.0

版本2.0有一个很大的变化，我无法将其部署到生产中。发现了一个需要在0.1.x中修复的错误。如何在不将cookbook 2.0的重大变化合并到生产中的情况下，如何创建和部署cookbook 0.1.2到生产？

使用git-flow。新版本是从开发分支创建的。然后合并回开发和测试。测试完成后，它会合并到master，给定一个git标签并自动部署到Chef服务器。

    0.1.1              0.2.0
   /      \           /      \
o-o--------o-o---X---o--------o-o-------- develop
 \            \                  \
  o------------o------------------o------ master

发布食谱时，将删除发布分支。

我假设我需要结帐X，然后创建食谱0.1.2。但是我发现当我尝试将cookbook 0.1.2合并到develop分支时，metadata.rb和CHANGELOG.md会发生合并冲突（Y）。虽然我可以在 0.2.0食谱发布之前重新，但这会改变我的整个历史。

_________________ / \ 0.1.1 0.1.2 0.2.0 \ / \ / / \ \ o-o--------o-o---X---------o--------o-o------Y-- develop \ \ \ o------------o------------------------o------- master

部署旧菜谱的最佳方法是什么？

我知道有关向后移动git提交的类似问题已经在SO上提出，但它们都没有涵盖如何处理不可避免的合并冲突。我应该接受会有冲突并手工解决吗？

How do I backport a commit in git?

Git strategy to backport bugfixes into older branches (cherry-pick vs. merge)

http://glicksoftware.com/blog/backporting-a-topic-branch-with-git

更新

为了澄清，我已经有了一个使用environment.json文件和version pinning在不同环境中使用不同菜谱的策略。

Answer 1

这里有两个不相关的问题：

首先是如何在git-flow下管理维护分支。我不喜欢他们的结构，但我认为主要的官方方式是从现有标签创建一个新分支，进行更改，标记维护版本，然后将该分支合并到master。

其次，如何在Chef中进行发布管理。通常，这是通过Chef环境完成的。每个环境都可以有一组约束，以限制在该环境中允许每个烹饪书的版本。您可以将生产约束设置为~> 0.1.0，以便允许维护版本，但不允许新的次要版本。也就是说，为了与SemVer（及相关）保持一致，您应该使用主要版本来指示compat中断。

Answer 2

@StephenKing建议的Git流“support branches”是git问题的答案，也是厨师部署问题解决方案的一部分。

我最终做了什么：

创建一个名为“support / 1.0”的新git分支

将我的修补程序应用于该分支，然后将metadata.rb和CHANGELOG.md更改为v0.1.2并添加git标记。

然后我将该分支合并为master，跳过develop（Z）。 meatadata.rb和CHANGELOG.md存在冲突，我手动解决了这些冲突。 Jenkins随后将0.1.2食谱上传到厨师服务器。

删除“support / 1.0”分支。

                       v0.1.2_________________
                      /                       \
     0.1.1       support/1.0      0.2.0        \
   /      \     /                /     \        \
o-o--------o---X----------------o-------o--------\-- develop
 \          \                            \        \
  o----------o----------------------------o--------Z- master

优点采用此方法：

没有长期生活支援分会
还有git标签版本控制的食谱
没必要改变历史

<强>缺点

Master branch将继续显示旧版本，直到下一个版本

开发metadata.rb =“0.2.0”
掌握metadata.rb =“0.1.2”

当版本0.2.1发布时，两个分支中的metadata.rb将显示正确的最新版本。在此之前，这可能会让人们误以为0.1.2是最新的食谱。

厨师从以前的git分支发布了一本食谱

2 个答案: