我们是一个庞大的团队（10-12个开发人员和4个质量保证团队），他们使用同一个git存储库处理多个项目。它是一个基于Spring Boot的后端Web服务。我们正在寻找一个好的git分支和部署策略。我们还有一个质量保证团队，可以确保我们的功能能够按预期运行（一定程度上没有错误）。
看了几篇文章后，我感到Gitflow模型对我们来说很好用。我的问题来了。
我们的质量检查团队应该在哪里测试我们的功能？
我很想知道哪种方法对其他人有效。
Answers:
质量检查可能应该测试两次。
第一次测试应围绕特定更改并在功能分支上进行。这样一来，质量检查人员就特定的更改进行了测试，并可以看到特定的更改已按照指定的要求完成且行为符合预期。它还为他们提供了第二轮测试的早期预览，这对质量检查实际上至关重要。
从我在各种受控环境中的背景出发，第二次测试需要在与发行版相对应的开发分支上的标签上进行，或者在发行分支上进行，或者在主分支上进行。在发布之前，QA应该在部署之前测试将要部署的完整代码。您应该能够断言，由QA测试的内容与部署到生产环境的内容完全相同。我的偏好是在代码冻结之后，将一个标签应用于发布分支，然后由QA进行测试。更改将在开发分支中进行，进行抽查，然后在发布分支中的新标签中再次进行测试。发布分支上的这些标签将对应于候选发布。
我在这里做一些假设。首先，您有一些不错的基于开发人员的测试范围。理想情况下，这将是开发人员运行并执行的自动化单元和集成测试，然后再将任何分支上的任何代码发送给QA。开发人员可能还希望围绕UI进行一些探索性测试，以确保在进行质量检查之前一切正常。其次，开发和质量保证之间要进行良好的协调，以计划要合并的更改，以确保基于功能的足够的质量保证时间。
好问题。我认为对此没有“官方”正确答案。这取决于您测试的速度。
根本问题是，每次合并，编译甚至部署，都可能潜在地产生错误。您测试的链越“向上”，您越早知道错误，而且您需要重新测试的次数也就越多。
为了确保您已经测试了客户正在使用的软件，在将客户流量（假设是Web应用程序）通过蓝/绿部署模式路由到这些服务器之前，您实际上必须测试实时部署。
但是很显然，这是您第一次检查代码的时候有点晚了！
如果您在质量保证环境中测试发布分支，则可以承担风险，并将实时测试减少到仅进行冒烟测试。并将错误修复应用到发行分支。但是您无法在创建发行版之前评估功能是否完整
如果您测试开发，那么您将获得迷你的bug修复功能分支。在评估功能之前，功能仍会合并，而下一个版本的功能可能会与测试当前版本相冲突。
如果测试功能分支，则需要一百万个环境，并且必须协调合并的顺序并测试签核。加上大量的重新测试。
根据我的经验，我建议：
在开发机上快速测试功能分支。只需确保其功能完整并且测试人员/开发人员就需求的含义达成一致即可。
在部署到Qa服务器的dev分支上进行日常测试/自动化测试。让您一起测试所有功能，并说出准备发布的时间。
如果所有功能都在，但测试尚未完成。例如，冲刺完成。进行发布分支并部署到第二个质量保证环境。这允许在版本1的错误修复/测试与版本2的功能同时进行。
（scsc奉献者会说您应该只将错误修复放入sprint 2中，但要切合实际）
切换之前，请对绿色/蓝色实时部署进行烟雾测试。这些是非常重要的，因为您会发现配置/环境错误，在开发时没有人真正地寻找。
我同意托马斯·欧文斯的观点。您可能应该测试两次。在合并之前先进入功能分支，在发布前先进入主分支。
实际上，我非常喜欢这个工作流程，因此我制作了一个主题软件Topico，该工具针对每个拉取请求自动构建并运行您的应用程序的一次性版本，每个版本都有自己的唯一测试URL。这使您的QA团队可以独立测试功能分支，而无需在自己的计算机上设置某种动态测试环境。
这种方法将意味着只有通过人工测试的代码才能到达您的主分支，从而保持其完整性。
我在多家公司中介绍了此功能，这对我们的发布周期有很大帮助。现在，我们能够准确地计划发布时间，而且我们更好地了解了可能将其发布到下一个版本中以及将要等待将来的版本中的哪些内容。它给了您更多的信心。