.net - Gitflow 和测试/部署

Question

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

目前我们遵循 Gitflow，我们有我们的功能分支，每个人都在处理一个独立的功能。功能 merge 到开发分支中。我们时不时地花一些时间来满足用户需求/错误修复/快速功能等。

最终目标是尽快将它们投入生产。我的问题是您建议采用哪种流程:

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

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

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

3) 测试人员确切地知道他们批准什么进入产品。

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

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

谢谢

Answer 1

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

这是它的工作原理:

• 从开发分支创建一个正在测试的分支，或简称 BUT

• 特性分支 merge 到测试分支，而不是直接 merge 到开发分支

• 您有一个 BUT，它现在要么与上一个版本相同，要么在此过程的最后一次迭代中经过良好测试。

• 现在您将所有功能分支/bugfixes merge 到您准备好的分支中。

• 你测试一下。如果出现关键问题，即导致下一个版本不希望包含错误的功能/错误修复，您可以通过重置和重做所有 merge 或通过 rebase 和删除提交来撤消该功能的 merge ，这基本上是相同。请注意，这会更改分支的历史记录，因此在测试完成之前，任何人都不应将此分支 merge 到任何内容中。

• 如果测试迭代成功完成(即没有重大错误)，您将其 merge 到开发中。

让我们检查一下这如何满足您的要求:

We can deploy without introducing bureaucracy (e.g. Release on the last Friday of every month).

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

If someone commits code that is introducing a bug it doesn't affect someone else that has committed bugless code. In other words, if Coder A tries to fix a bug by introducing a new bug, and coder B has fixed his bug then coder's B code will get further into the pipeline while coder A will stay late fixing the bug

检查

We cannot have unlimited testing environments. We also don't want to spend our day setting up testing environments. We need a solution that can work around this requirements (so test on feature branches is not an option unless I m missing something)

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

The testers know exactly without a doubt what they are approving to go into prod.

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

缺点/你需要的东西

只要未经测试人员批准，就不会投入生产，也不会与其他人的工作 merge 。这可能成为流程中的瓶颈，特别是如果来自功能分支的内容质量低下。如果测试人员必须取消 merge ，他们将不得不重新测试其余部分(至少我认识的测试人员会坚持这样做，并且有充分的理由)。所以错误会减慢你的速度(这并不新鲜，但在这样的过程中变得非常明显)。

为了限制这种影响，您应该付出很多努力使功能分支尽可能好:

• 在与 BUT merge 之前运行功能分支的自动测试
• 在与 BUT merge 后运行功能分支的自动测试
• 有很多优秀的自动化测试。
• 代码审查
• 结对编程
• 在您的测试环境中自动部署

基本上，减少测试人员必须完成的工作量并加快其余工作的一切都会有很大帮助。

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