3

请多多包涵....

（编辑...）

╔════════════╦═══════════════════╦══════╗
║ 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（虚拟机）上工作的基本工作流程

提交您的更改 --> 从测试服务器拉取到 Repo_vm --> 在 vm 上运行您的测试 --> 成功然后要求 QA 从 Repo_home 拉取

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

但是多个开发人员使用相同的测试服务器存储库，如果我们这样做，我们最终会被 Michael Myers 追赶。

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

  1. 在 vm 上提交更改
  2. 从测试服务器拉取
  3. 在 vm 上运行测试
  4. 如果一切通过，更新家庭回购
  5. 要求 QA 从 repo_home 中提取

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

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

Q2：QA 给予有限的时间是什么意思？

Q3：开发人员应该多久从测试服务器拉取一次（包含最新的 alpha 稳定版本）？

谢谢。

4

1 回答 1

3

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

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

QA 还可以为开发人员提供有限的时间来合并、构建和测试，具体取决于您的流程速度和开发人员更改的大小。这样一来，您就不会在可怜的开发人员努力让事情正常工作的背后堆积大量的更改。

于 2012-06-07T22:41:57.007 回答