我想知道人们使用什么机制来执行和跟踪对 SVN 承诺的同行评审。
对于每个提交,我希望能够跟踪人们是否进行了同行评审(我不确定在他们不能提交的情况下执行规则是否是一个好主意,我的直觉是不应该像那里那样强制执行可能是在没有同行评审的情况下提交的正当理由),但是应该能够跟踪未经审查的提交,以便在发布之前我们可以查看所有这些提交。
您可以要求每个开发人员以固定格式(如 [REV:XYZ])将审查开发人员的标签添加到提交中。这允许您过滤历史记录。正如这里提到的,如果需要,您可以使用源代码版本控制工具的预提交挂钩来强制执行此操作。
然后,需要向所有开发人员传达未经同行评审不得提交任何代码的规则。还展示了在提交之前审查代码的优势。最初的几个月,应该有人检查提交历史中没有审阅者标签的提交。如果他们找到了一些,请询问开发人员为什么要进行审核以及与谁进行审核。当没有审查时,提醒他们注意规则。如果某些开发人员多次故意违反此规则,可能会产生影响,但同行压力通常会阻止这种情况发生。
通常,当该规则生效时,没有理由不进行审查。尤其是“但我必须快速修复这个错误才能向客户提供修复版本”不能成为借口,因为开发人员更容易在匆忙中犯错误。
这个问题听起来像是 git 或 bzr 等分布式 VCS 的广告:您需要开发人员能够经常提交更改,但要提交到他们自己的分支,然后在被拉入中央存储库之前对其进行审查。
就个人而言,我经常可以每天使用 svn 接近 50 次,所以我不会喜欢它;)
我知道 Atlassian 的 jira greenhopper 插件可以作为 pre-committ 钩子运行,以在提交中要求 jira 引用。如果您也使用 greenhopper 来规划开发任务,则可以强制所有提交都应连接到 jira 问题。
即使您不使用 greenhopper,您也可以创建一个 pre-committ 挂钩,强制执行包含一些问题跟踪参考号的提交评论。
这可能会让您收集与 jira 问题相关的已收集变更集,这对我来说听起来是一个更好的主意。
开发人员可以为每个更改(不是每个提交)创建一个分支。他们可以在这个分支中提交任意多次。但是,在将更改合并到主干之前,您可以强制进行同行评审。所以你的主干只会包含同行评审的代码。
你可以通过权限来做到这一点,所以只有选择的人可以提交到主干,他们可以在这样做之前检查代码是否正常。
我一直在使用版本控制,并认为在分支模型中工作(而不是在主干中工作)很好。像 git 这样的 DVCS 系统更进一步,并且似乎对很多人都运行良好。
您可以做到这一点的一种方法是在您的团队中使用审阅者提交规则。也就是说,不允许开发人员提交他们自己的代码,他们必须说服其他人代表他们提交他们的代码。
我以前做过这样的项目,而且效果很好。缺点是使用 Subversion,这意味着审阅者的姓名,而不是开发人员的姓名,会显示在日志中。使用 git,你可以保留开发者的名字,并且审阅者添加一个 Signed-off-by: 行。