Gitflow和测试/部署

Question

我有几个问题，当许多开发人员都在做同一件事(不能进一步拆分)，而你仍然想每天部署时，你如何处理测试和部署。

目前我们遵循Gitflow，我们有自己的功能分支，每个人都在处理一个孤立的功能。功能被合并到开发分支中。每隔一段时间，我们就会花一些时间来满足用户的需求/ bug修复/快速特性等。

最终的目标是让它们尽快实现。我的问题是，你会建议什么样的过程，以便：

1)我们可以在不引入官僚机构的情况下进行部署(例如，在每个月的最后一个星期五发布)。

2)如果有人提交了引入错误的代码，它不会影响其他已经提交了无错误代码的人。换句话说，如果编码器A试图通过引入一个新的bug来修复一个bug，而编码器B已经修复了他的bug，那么编码器B的代码将进一步进入流水线，而编码器A将延迟修复该bug :)

3)我们不能有无限的测试环境。我们也不想把一天的时间花在设置测试环境上。我们需要一个可以绕过这个需求的解决方案(因此，除非我遗漏了什么，否则不能在功能分支上进行测试)

3)测试人员毫不怀疑地知道他们要批准进入prod的是什么。

顺便说一句，我们有一组相当广泛的单元/功能测试，但这个问题是关于过程的，所以这些并不是真正相关的。

此外，我已经研究了所有其他问题，但没有什么能真正解决我所有的问题。如果你认为有这样的一个，我很乐意去看看。

谢谢

Answer 1

在流程方面，与“标准流程”相比，您只需要多一个可选步骤:如果您发现一个bug (或可能是一个严重的bug)，您将回滚所有更改(即包含该bug的合并)。

下面是它的工作原理：

• 在测试下创建一个分支，或者简称为，从开发分支
• feature分支合并到测试分支，而不是直接合并到您拥有的开发分支
• 中，但它现在要么与上一个版本相同，要么从这个过程的上一次迭代中得到了良好的测试。
• 现在你可以合并你已经准备好的那个分支中的所有特性分支/bugfixes。
• 你可以测试它。如果出现关键问题，即使包含错误的特性/错误修复在下一个版本中变得不可取，您可以通过重置、重做所有合并或重新建立基础并移除提交来撤消该特性的合并，这基本上是相同的。请注意，这会更改分支的历史记录，因此在测试成功完成测试迭代(即没有重大错误)之前，任何人都不应该将此分支合并到任何内容中。您可以将其合并到development.

中

让我们来看看这是如何满足您的需求的：

我们可以在不引入官僚机构的情况下进行部署(例如，在每个月的最后一个星期五发布)。

你仍然像以前一样拥有你的发布分支。这里没有问题。唯一的开销是，如果合并出现but，您可能必须撤消合并，但我看不到解决方法。

如果有人提交了引入错误的代码，则不会影响其他提交了无错误代码的人。换句话说，如果编码器A试图通过引入新的bug来修复bug，而编码器B已经修复了他的bug，那么编码器B的代码将进一步进入流水线，而编码器A将延迟修复bug

检查

我们不能有无限的测试环境。我们也不想把一天的时间花在设置测试环境上。我们需要一个可以绕过这个需求的解决方案(因此，除非我遗漏了什么，否则不能在功能分支上进行测试)

您只需要一个测试环境。更多可能有助于促进多个测试人员的并行工作。但这是可选的。

测试人员毫无疑问地知道他们正在批准什么进入prod。

您可以很容易地使用标准的git命令来确定一个功能分支是否是BUT历史的一部分，这正是您所需要的。

缺点/你需要的东西

只要没有得到测试人员的批准，任何东西都不能投入生产，也不能与其他人的工作合并。这可能会成为过程中的瓶颈，特别是如果来自功能分支的东西是低质量的。如果测试人员必须拆分东西，他们将不得不重新测试其余的东西(至少我知道的测试人员会坚持这一点，而且有一个很好的理由)。所以bug会减慢你的速度(这并不新鲜，但在这样的过程中会变得非常明显)。

为了限制这种影响，你应该花大量的精力来使功能分支尽可能好：

• 在与合并之前运行功能分支的自动测试，但
• 在与合并后运行功能分支的自动测试，但是
• 有许多很好的自动测试。在测试环境中配对部署
• 代码审阅

基本上，所有减少测试人员必须做的工作量并加快其余工作的事情都会有很大帮助。

你说过你不能有很多测试环境。考虑一下，您是否可以拥有部分测试环境，该环境不需要所有资源，但仍然适用于某些测试。