与多个开发人员一起拉动和处理Mercurial存储库

Question

请忍受我......

（编辑...）

╔════════════╦═══════════════════╦══════╗
║ repo name  ║       role        ║ user ║
╠════════════╬═══════════════════╬══════╣
║ RepoMain   ║ production        ║ Mr.A ║
║ RepoTest   ║ test server       ║ QA   ║
║ RepoB_vm   ║ Mr.B's vm         ║ Mr.B ║
║ RepoB_home ║ Mr.B's final repo ║ Mr.B ║
║ RepoC_vm   ║ Mr.C's vm         ║ Mr.C ║
║ RepoC_home ║ Mr.C's final repo ║ Mr.C ║
╚════════════╩═══════════════════╩══════╝

你可以想象Mr.A和其他人合作，所以他有自己的存储库（同一个项目）

有几个热门的新问题，我认为我还没有结束。

在您自己的VM（虚拟机）上运行的基本工作流程

  

提交您的更改 - ＆gt;从测试服务器拉到Repo_vm - ＆gt;运行你的测试   在vm上 - ＆gt;成功然后要求QA从Repo_home拉出来

这可能是最好的工作流程吗？我总是害怕合并问题（有时更新的更改会丢失..我有一次可怕的经历）。 我不认为生产＆lt; ---测试服务器有什么大不了的，因为它是单向的。这听起来像是一个安全的合并。

但是多个开发人员使用相同的测试服务器回购，如果我们这样做，我们最终将迈克尔迈尔斯追逐我们。

更明确地扩展上述工作流程......

1. 在vm上提交更改
2. 从测试服务器拉
3. 在vm上运行测试
4. 如果全部通过，请更新主页回购
5. 要求QA从repo_home取消

---

考虑到拉取请求，这是一个更好的工作流程吗？

1. 在您自己的VM上提交更改
2. 从测试服务器获取最新alpha版本的更改
3. 在本地运行测试
4. 如果一切顺利，请使用自己的帐户推送到您的家庭仓库
5. 提交拉取请求
6. 如果您在队列的前面，在测试服务器（沙箱环境）上创建克隆版本，然后进行合并（测试服务器可能具有与在home repo中提交的最后一个alpha版本不同的最新版本）
7. 如果测试通过，他会告诉QA从合并的沙盒仓库中取出
8. 运行测试
9. 在scheulde上推送生产

Q2：质量保证给出有限的时间是什么意思？

第三季度：开发人员应该多久从测试服务器中提取（包含最新的alpha稳定版本）？

感谢。

Answer 1

合并是一个棘手的问题。 Mercurial可以自动处理事情，但无法解决冲突。这最好留给一个人，而做这件事的最佳人选是开发人员进行更改。不要让QA合并任何东西。合并冲突需要仔细注意细节，不应掉以轻心。粗心的合并是一个软件无法解决的问题。

我认为您的工作流程很好。 QA应该将拉取请求视为队列。当开发人员到达队列的前端时，他有机会进行拉取，合并和测试。一旦他完成，他就会通知QA，QA然后撤回他的更改。由于没有其他代码进入存储库，因此保证QA不必合并。

QA还可以为开发人员提供有限的合并，构建和测试时间，具体取决于流程的速度和开发人员更改的大小。这样一来，你就不会在糟糕的开发人员背后挣扎着一大堆变化，这些开发人员正在努力让事情发挥作用。