当许多开发人员正在处理同一件事（不能进一步拆分）并且您仍然想每天部署时，我有几个关于如何处理测试和部署的问题。
目前，我们遵循 Gitflow，其中我们有我们的功能分支，每个人都在开发一个孤立的功能。功能将合并到开发分支中。我们时不时地花一些时间来满足用户要求/错误修复/快速功能等。
最终目标是尽快将它们提供给 PROD。我的问题是，你会建议什么过程：
1）我们可以在不引入官僚主义的情况下进行部署（例如，在每个月的最后一个星期五发布）。
2）如果有人提交的代码引入了错误，则不会影响提交无错误代码的其他人。换句话说，如果编码员 A 试图通过引入新错误来修复错误，并且编码员 B 已经修复了他的错误，那么编码员的 B 代码将进一步进入管道，而编码员 A 将延迟修复错误:)
3）我们不能有无限的测试环境。我们也不想花一天时间设置测试环境。我们需要一个可以解决此要求的解决方案（因此，除非我缺少某些内容，否则无法选择对功能分支进行测试）
3）测试人员毫无疑问地确切地知道他们批准进入生产的内容。
顺便说一句，我们有一套相当广泛的单元/功能测试，但这个问题是关于过程的，所以这些并不真正相关。
此外，我已经研究了所有其他问题，但没有真正解决我的所有问题。如果你认为有一个，我很乐意看看。
谢谢
与"标准流程"相比，您只需要一个可选步骤：如果您发现错误（或可能是严重错误），您可以回滚所有更改（即包含该错误的合并）。
以下是它的工作原理：
-
从开发分支创建待测分支，简称 BUT。
功能分支合并到测试分支中 ，而不是直接合并到开发分支中
您现在有一个 BUT，它要么与上一个版本相同，要么从此过程的最后一次迭代中经过充分测试。
现在，您将所有功能分支/错误修复合并到您准备好的分支中。
你测试它。如果出现关键问题，即使包含错误的功能/错误修复在下一个版本中不受欢迎，您可以通过重置、重做所有合并或变基并删除提交来撤消该功能的合并，这基本上是相同的。请注意，这会更改分支的历史记录，因此在测试完成之前，任何人都不应将此分支合并到任何内容中。
如果测试迭代成功完成（即没有重大错误），则将其合并到开发中。
让我们检查一下这如何满足您的要求：
我们可以在不引入官僚主义的情况下进行部署（例如，在每个月的最后一个星期五发布）。
您仍然像以前一样拥有发布分支。这里没问题。唯一的开销是，如果合并是错误的，您可能必须撤消合并，但我看不到解决此问题的方法。
如果有人提交引入错误的代码，则不会影响提交无错误代码的其他人。换句话说，如果编码员 A 试图通过引入一个新错误来修复一个错误，并且编码员 B 已经修复了他的错误，那么编码员的 B 代码将进一步进入管道，而编码员 A 将延迟修复错误。
检查
我们不能有无限的测试环境。我们也不想花一天时间设置测试环境。我们需要一个可以解决此要求的解决方案（因此，除非我缺少某些内容，否则无法选择对功能分支进行测试）
您只需要一个测试环境。更多内容可能有助于促进多个测试人员的并行工作。但这是可选的。
测试人员毫无疑问地确切地知道他们批准进入生产的内容。
您可以使用标准 git 命令非常轻松地确定功能分支是否是 BUT 历史记录的一部分，这正是您所需要的。
缺点/你需要的东西
没有任何东西进入生产，或者可以与其他人的工作合并，只要它没有得到测试人员的批准。这可能会成为流程中的瓶颈，特别是如果来自功能分支的内容质量低下。如果测试人员必须取消合并内容，他们将不得不重新测试其余内容（至少我知道测试人员会坚持这一点，并且有充分的理由）。所以错误会减慢你的速度（这不是新的，但通过这样的过程变得非常明显）。
为了限制这种影响，您应该付出很多努力使功能分支尽可能好：
- 在与 BUT 合并之前运行功能分支的自动测试
- 与 BUT 合并后运行功能分支的自动测试
- 有很多好的自动化测试。
- 代码审查
- 结对编程
- 在测试环境中自动部署
基本上，所有减少测试人员必须完成的工作量并加快其余工作速度的东西都会有很大帮助。
你说你不能有很多测试环境。考虑是否可以使用部分测试环境，这些环境不需要所有资源，但仍然适用于某些测试。