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