协调 Git Flow 和 QA

Question

详见我们的项目是使用gitflow这里我的问题是如何做QA适应这个。

考虑我有一个 master 分支和一个 hotifx 分支。一旦修补程序完成，那么我相信 QA 应该在修补程序发布时做它的工作。如果它没有通过，则使用此修复程序更新修补程序。QA 再次发布。现在，当修补程序 RC 通过 QA 时，代码将合并回 master（应该没有冲突，并且只是作为 master 的直接副本没有更改）。然后从 master 完成生产发布。令人担忧的是，QA 尚未验证此版本。他们已经验证了一个修补程序版本。

我们如何协调 master 仅用于生产代码，但对接近足够的生产代码进行 QA 测试？任何人对这种情况有任何经验吗？我看不到任何详细说明 QA 和测试如何融入 gitflow 的内容。

谢谢

Answer 1

QA 适合哪里？遍。

我明白你的问题：如果你希望 master 始终准备好发布，那么你需要确保你的工作在合并到 master 之前经过测试。但是，如果您不针对 master 进行测试，那么如果您的更改和其他人的更改组合导致出现问题怎么办？如果两者都做的话，工作量不是很大吗？

IMO 的解决方案是自动检查和将测试工作分散到修补程序分支和主服务器上的组合，而不是全部集中在其中一个或另一个上。它确实假设你（作为开发人员）和我（作为测试人员）在同一个团队中非常密切地工作，而不是在不同的团队中，因为官僚开销和正式的交接会阻止我们有效地协作。

尽早获得测试人员的反馈是最有用的。我很高兴测试临时工作，因为如果我可以通过尽早发现问题来避免某人回去并撕掉一堆东西，那就太好了，而且它也使我能够更早地了解该功能（建立我的心理）模型、测试数据、自动检查的想法），因此当最终构建准备就绪时，我不会急于赶上。理想情况下，我会在您开发时为您编写一些自动验收检查，以便您可以针对您的分支和主控运行这些测试和单元测试，而无需付出很多额外的努力。（实际上，我并不总是能及时做到这一点，但当我做到了时，效果很好）。而且我还希望无论您对 master 运行什么检查，您也可以在提交之前对修补程序分支运行它们。

如果应用程序的同一区域正在进行大量工作，那么我希望在合并后至少对 master 进行一些快速探索 - 如果是关键区域，可能会进行更多探索。我们的自动化套件已经发现了一些回归问题，我不想没有它，但拥有自动化绝不是不对风险进行一点批判性思考的好理由。

这是一种方法：还有很多其他方法可能适合您，具体取决于您的环境。对于我最近听到的一种有趣的方法，请查找来自 Songkick 的 Amy Phillips 的“Improve The Process By Take Control” - 他们在发布后移动了一些测试工作，理由是嘿，生产是您可能达到的最接近的结果生产环境对吗？显然，这需要使用功能切换，并且在某些环境中可能不可接受，但这是横向思考将测试工作放在哪里有意义的一个很好的例子。