普通用户第一次登录后,通常需要进行账号设定,例如:修改初始密码。只要点击右上角下拉菜单的"My Account"选项即可。
如果要设定用户头像,需要登录http://en.gravatar.com进行免费注册并上传头像照片,只要注册的时候将邮件地址和review board里注册的邮件地址填成同一个即可。
Review Board支持pre-commit review和post-commit review两种模式,简单的说,就是先review再提交还是先提交代码再做review。每种模式都不做强制设定,每个项目组可以自定义review流程。通常情况下,开源的代码必须做强制性的先review后提交,以保证代码质量。如果是这种情况,git hub推出的Gerrit是更好的选择。如果是封闭的公司环境下,同一项目组的成员,先提交代码的方式不会影响开发进度,并且非强制的模式不要求所有代码必须review,会更贴合实际的开发情况。
所谓code review通常是显示diff file,让reviewer通过检查这些代码更改来确定是否改动得有问题,或者有没有什么逻辑错误。虽然review board提供了从网页上上传diff文件的方式来创建review request的方式,更为灵活可行的方式是程序员在本地通过命令行上传指定的某几次提交内容来申请review,其中命令行所调用的是review board提供的python程序,要想使用这些程序,还要在windows客户端安装下面的组件:
1. python 2.x,最好是2.7。众所周知,python 3.0有重大变化,2.x的脚本无法在3.0上运行。
2. 安装python setuptools Installer from https://pypi.python.org/pypi/setuptools#windows
然后将python27目录和python27\Scripts目录加到环境变量PATH中去。
3. 将文件ez_setup.py从 http://peak.telecommunity.com/dist/ 复制到客户端本地。
4. 从命令行窗口运行:python ez_setup.py
5. 从命令行窗口运行:easy_install -U RBTools
6. 设定review board server的url。有两种方式,一是通过命令行git config reviewboard.url yourserver设置局部参数,另一种是全局设定:在%home%下创建文本文件.reviewboardrc(不要省略最前面的点),里面只写一行:REVIEWBOARD_URL = yourserver,请将yourserver换成实际的server url。
7. 下面是常用的几个创建review request的命令:(更完整的内容请参见http://www.reviewboard.org/docs/manual/1.7/users/tools/post-review/)
这样,以后需要运行post-review的地方就直接换成git post-review,这样就再也不用输入用户名和密码了。
一 提出review请求
在客户端运用命令行创建review request之后,我们就可以转到web页面上,登录review board后,在My Dashboard Tab下看到如下内容。
最左边列出四项主要内容:
1. Starred Reviews主要是列出你标记为Star的review request。标记的方式就是点击右边列表里某行的小星星,单击变成黄色就表示点选,再点就又变成灰色。这个功能是用来关注那些你感兴趣,但是又没有发给你review的review request。选择关注之后,这些review的状态有任何变化,你都会收到邮件通知。
2. Outgoing Reviews是所有你提交的并处于open或draft状态的review request。
3. Incoming Reviews列出所有assign给你或者你所在的group的review request。
4. All My Requests就不用再解释了。
右边的列表可以通过点击列标题选择排列顺序,点击右上角的小铅笔会出现如上图所示的下拉菜单,可以选择由那些内容组成列表。
列表中的第一条有一个[Draft]的标记,这就是我们刚刚用命令行创建出来的review request。点击进入这条review的详细页面。如下图所示:
页面中凡是有小铅笔图标的地方,点击小铅笔就可以进行编辑,毋庸置疑,Reviewers是必须要填的,分别点击Groups和People旁边的小铅笔图标选择请求那个组的哪几个人帮你做review。注意,这里支持多人review。
请注意图片上方的绿色banner,其中有两个选项: Publish和Discard Review Request。在publish之前,这些处于draft状态的review request只有你自己能看到,这时你可以选择Discard Review Request放弃review请求,也可以选择Publish,让系统通知你指定的Reviewer来review你的代码。
也可以给review请求增加附件,只要把文件拖拽到页面上就可以了。
二 执行review操作
好,现在Reviewer收到一封通知邮件,告诉他别人提交给他的代码需要review。于是,他用自己的账号登陆review board,在Incoming Reviews的To me条目下找到所有分配给自己的review请求,点击之后进入详细内容页面。这个页面同上图类似,不过是没有上面那条绿色的banner,现在我们可以点击最右边的"View Diff"选项查看具体的代码改动。会看到如下的内容:
系统用左右两边对比的方式显示改动的内容。点击任意一个行标号就会弹出如下所示的对话框,可以在对话框里填写review comments。
需要注意的是绿色对话框下部的勾选项"Open an issue",如果勾选,说明你认为这是个严重问题,系统会进行issue track,否则说明你填写的只是些严重程度比较低的建议。
一旦有comments填写并保存,页面最上边立刻会出现一个如下图所示绿色的banner。同样,没有publish的review comments也只有你自己才看得见。现在,我们选择publish,这样review请求的提交者就会收到一封通知邮件,报告review状态的改变。
三 针对review comments再做修改
review请求的提交者收到通知后,立刻登录review board,会在页面上看到一块新的内容:
这里的issue summary列出了所有reviewer提comments时勾选“open an issue”的那些严重问题点。这个summary表格下面是详细内容部分。每个issue点都会显示下面的一个banner:
如果点击Fixed,表明你已经将这个问题点改好了,如果点击Drop,表示你不认同Reviewer的意见,这时会要求填入你自己的意见。
如果你认同这个问题点,需要在本地的代码库里作修改,之后再次提交review,不过,这次我们必须使用特别的post-review参数-r,后面跟的数字是review request的序号。如下图红色方框中的数字:
在本例中,这个数字是五,于是我们再次修改后提请review的命令行就应该是: git post-review -r 5
重复第一条的页面操作并publish review request,这时reviewer在"view diff"页面上就能看到多次的修改,并比较任意两次代码提交之间的差别。
当Reviewer觉得代码已经没有问题了,也没有什么新的comment要添加了,就可以点击"Ship it"认可改动内容。
四 关闭review请求
当review结束后,有两种关闭的方法:Submitted表示你已经将代码和改动都提交到中央代码库了,Discarded表示本次review请求撤销。
另外,Review Board还提供了一套完整的WEB API,供用户开发定制。从我们日常的使用体会来说,Review Board确实是一款不错的review工具,它还支持subversion,perforce,clearcase等多种版本控制工具。其他所有未尽的内容,请读者参考review board的官网http://www.reviewboard.org。