推荐的代码审查流程

我们通常在那时使用Perforce和SmartBear的Code Collaborator，Big Corp现在我们还将在某些项目中使用Mercurial。

Code Collaborator支持Mercurial（我们使用的是版本5），我正在尝试确定最佳时间（在提交/推送到服务器期间）是最佳/有效的代码审查时间。

谢谢

实际上，最近我们在公司中经历了几乎完全相同的事情。这是我们所做的：

• 我们将所有存储库的中央权威性副本保存在一台服务器上。当开发人员想要“签出”代码时，他们将转到该服务器并从那里的存储库中进行克隆。同样，当开发周期完成时，代码也被推送到相应的存储库中。

• 我们将稳定的存储库与开发的存储库分开。我们要求在将代码推送到稳定存储库之前对其进行检查。（这很重要，因为我们还要求稳定的存储库包含当前正在生产中运行的代码，仅区别于待处理的代码升级。）

为了执行代码审查，我们编写了一个pretxnchangegroup钩子（记录在HG Book中）。我们利用这样的事实，当该钩子运行时，它可以看到存储库，就像代码更改是永久的一样，而且还使我们能够阻止推送。基本上，过程如下：

1. 开发人员开始推送到稳定的存储库（是的，这确实是第一步）
2. 挂钩运行并获取事务中包含的所有变更集的列表（通过运行HG日志）。然后，它查询我们构建的数据库，以查看这些变更集是否包含在代码审查中。（该表将变更集的哈希与代码审阅ID相匹配）。
   • 如果这是第一次看到这些变更集，则我们将创建一个新的代码审查（使用Code Collaborator命令行），然后使用该代码审查的ID将这些变更集记录在数据库中。
   • 如果我们看到了一些（但不是全部）变更集，则运行（代码协作者）命令将新变更集附加到现有审阅中，并将这些新变更集记录在数据库中。
   • 如果在数据库中找到了所有更改（即，所有更改都已添加到代码审查中），那么我们将验证代码审查的状态为“完成”。但是，如果有任何新的变更集（或代码审查未完成），则该挂钩以非零状态代码退出（导致Mercurial退回事务），并在标准错误上输出一条友好的消息，向开发人员解释代码审查需要完成。

从本质上讲，这为开发人员提供了一个相当简化的过程（他们要做的只是推汞），并完全自动化了代码审阅的创建（并将其他更改的文件上传到审阅），同时确保所有代码都得到审阅。

注意：这是一个相当简单的过程（对我们而言相对较新），因此它可能不适用于每个人，并且可能存在一些我们尚未遇到的设计错误。但是到目前为止，它的运行情况还不错。

这取决于您的存储库结构如何以及要完成的工作。我们更喜欢进行“预提交”审查，这在DVCS的世界中确实意味着“预推送”。DVCS在这种环境下（与传统SCM相比）更好，因为它们具有内置功能，可以保存本地更改并恢复工作区，以便您可以进行其他工作。

如果您要进行推送后审查，理想的工作流程在很大程度上取决于您的存储库结构。例如，假设一个存储库结构看起来像本文中有关Git存储库布局所讨论的结构。在这种情况下，您可能需要查看已合并到中的更改develop。在功能分支上的单个提交可能没有意义进行审查。显然，hotfixes还必须对所有合并在一起进行审查master。

相反，如果您只有一个集成分支，人们可以直接签入，那么您将需要查看对该分支的所有推送。这可能效率略低，但仍然可以工作。在这种环境下，您必须确保在剪切发行版之前已审查所有已推送的更改。这可能会比较棘手。

至于b），我建议的唯一方法是直接通过电子邮件发送SmartBear支持（support@smartbear.com）。我们（是的，我为SmartBear工作）很乐意帮助您解决路径问题，但是此问题中没有足够的信息来解决您的问题。正常过程是仅运行安装程序，一切正常。显然在此过程中出现了问题。