Git Flow流程如何将功能发送到测试环境，只部署特定功能到生产环境

Question

Git Flow流程如何将功能发送到测试环境，只部署特定功能到生产环境

7

我们正在努力解决Git Flow流程问题，以及将功能部署到我们的测试和生产环境中：

- 我们希望所有准备好进行测试的功能被合并并部署到测试环境中。 - 我们只想将特定的功能部署到生产环境中。

我们使用Git Flow的方式存在问题：

1. 开发人员A按照正常的Git Flow流程从“develop”创建一个新的功能，并在新功能中进行开发。当准备好进行测试时，他将其功能合并到“develop”分支中，并将“develop”分支部署到测试环境中。 2. 然后开发人员B遵循相同的流程。两个功能现在都合并到了“develop”分支中，并且两个更改都可见于测试环境中。 3. 客户在测试环境上进行测试，但只批准由开发人员A进行的更改发布到生产环境。因此，他将从“develop”创建一个新的“release”分支。但是这会包括来自开发人员B的更改。

那么，如何最好地只发布来自开发人员A的更改呢？

当前，我们遵循以下过程，允许我们按功能发布到Live服务器。但肯定有更好的方法吧？

我们遵循正常的Git Flow设置，但还创建了一个名为“qa”的新分支，它将从主“branch”创建。我们遵循以下过程：

1. 拉取最新的“develop”分支 2. 使用Git Flow从“develop”创建一个新功能 3. 在功能中进行所有开发 4. 一旦准备好进行测试， - 拉取最新的“qa”分支 - 在“qa”分支中，将您的功能合并到“qa”中 5. 将“qa”分支发布到QA服务器 6. 如果需要进行任何错误修复，请从步骤3重复 7. 如果客户不再需要此功能，并且需要将其删除， - 删除该功能 - 撤消您对qa的合并 8. 如果客户满意测试，请选择您的功能，并按照Git Flow流程完成该功能。（这将合并到“develop”） 9. 选择Development分支，并使用GitFlow创建新版本 10. 使用Gitflow完成版本（如果需要，可以捆绑多个版本） 11. 准备上线时， - 确保您在master分支中 - 如有可能，请测试项目和更改 - 复制所有所需文件到Live服务器

但是通过创建此“QA”分支，我们根本没有使用预期的开发分支，使其变得多余。

我看了这些答案，但并没有对我们有所帮助，或者说我不理解这里和这里

- David Smit

2

对我来说，一个功能只有完全完成才能被合并到“develop”中。如果仍在等待批准，那么这是完成所必需的一步。如果需要逐个经过客户批准/撤销功能，为什么不从每个“feature”分支直接发布和测试它们呢？在你的例子中，在完成功能之前，但一旦准备好进行测试，Dev A会将Feature A分支直接推送到服务器上，Dev B也会对Feature B执行相同的操作。 - Hugo Ferreira

1

这可能意味着QA服务器的repo现在将包含这些功能分支。在服务器上，您将设置几个虚拟主机端点，每个功能分支都将被检出以供客户评估（例如，客户在一个URL中检查功能A，在另一个URL中查看功能B等）。经批准的功能将遵循正常的git flow周期，即develop > release > master。release甚至可以推送到一个_集成测试_主要QA URL，以进行所有已批准功能的最后一分钟测试。 - Hugo Ferreira

1

@HugoFerreira，感谢您的回复！客户的基础设施以及进行测试的人员不允许多个实例进行测试。他们只有qa.site.com和live.site.com。他们希望能够在qa.sites.com上同时测试多个小功能。（附注：他们测试某些功能非常缓慢）。我知道这并不理想，因为将一个功能移到生产环境时，该功能尚未进行独立/适当的集成测试。但这是他们想要的。是否有适当的git流程可供使用？您认为我们应该继续使用我们描述的流程吗？ - David Smit

1

@DavidSmit，我们目前处于类似的情况。由于这个问题发布已经有4年了，您能否分享一下您解决这个问题的细节，或者在这个问题下发布一个答案？ - Rithin Chalumuri

2个回答

2

修正您的流程，使您将 git 合并到主分支与客户测试解耦。如果他们想确定功能是否应该上线或者请求不呈现，则他们需要参与合并到开发分支的讨论，或者您可以使用特性开关来允许您部署该功能，但可以关闭它以使其不可见。

- AlBlue

2

感谢您的反馈！希望我理解了您的答案，但目前我们希望保持我们的发布策略尽可能简单（纯特性分支）。我们对git还很陌生，不知道是否要实现特性开关（在生产中_broke / dark code_似乎很可怕）。正如HugoFerreira所指出的那样，一个特性只有在完全测试后才能合并到develop。而对于我们客户端的某些东西来说，在qa.site.com上的测试人员签署后才能被完全测试，其中可能包含多个正在测试的特性。然后我们只将该特性合并到develop中。 - David Smit

在这种情况下，保持使用 git 之前的方式。 - AlBlue

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- David Smit · Accepted Answer

在4年后，我将尝试回答我自己的问题。虽然来自@AlBlue的另一个答案是100％正确的方法，但并非总是可行。

以下是四种Gitflow选项，允许单独的测试环境，并允许仅将特定功能合并到主分支中：

1. 如最初的问题所述，为集成测试创建单独的分支，并将每个功能合并到该分支以进行批准。有关更多信息，请参见Git分支模型策略。缺点是你会有很多分支，如果其他选项可行，则我不喜欢这个解决方案。 2. Cherry pick：经常合并到develop分支上，在develop分支上进行集成测试，一旦测试得到批准，挑选应该进入发布/主分支的功能。（我没有尝试过，但似乎很麻烦）。 3. 使用功能开关（正如Alblue提到的）。 4. "修复您的流程，以便您将git合并到主测试与客户测试分离" - 正如AlBlue在他的答案中所说。这现在是我们首选的选项，因为我们现在已经解决了自动化部署的问题。对于每个功能，可以通过点击按钮（Azure devops + Azure hosting）创建单独的托管环境，因此每个功能在合并到develop分支之前都需要进行测试。