gerrit是google出品的一个开源的review工具.

感觉这个工具使用挺普遍的,但是好像没有”深入”的介绍.这里自己也浅尝辙止一下.

gerrit

web

gerrit本身就是一个web端的工具.而且从名字本身就可以看出,这个是从git衍生出来的.

集成gerrit的典型流程

• clone
• checkout -b [branch]
• modify / stage / commit
• push / CI test / review
• rebase / merge

CL vs. branch

gerrit的一个明显特点就是,只能够以CL的形式来提交代码.

CL: Change List

是根据commit中的Change-Id来进行判断的.这个Change-Id的生成依赖于本地git的一个hook.

当完成commit的过程之后,会自动检查在commit的最后是否是Change-Id,如果有的话,则不做任何操作.没有的话,则会生成一个,然后添加到commit的最后.

这也的话,后续的push / review循环,就是可以继续的,因为只要保持Chnage-Id不变,gerrit系统就会据此检测到一个CL,(而再一次的提交就是一个新的patch-set).

这也意味着,提交多个依赖关系的commit的显得很不方便.

因为代码的提交都是一个孤立的CL嘛.(当然也可以在CL中设置依赖关系,当时review是按照CL会单位的,因此还是不方便啊.)

这点可以对比github/gitlab之类的工具,这些多按照branch为单位进行review,也就是可以review多个commit一起,并且可以在review的过程中提交新的commit,从而可以方便看到一个branch上的修改.

rebase vs. merge

上面的特点,其实也决定的代码合并的方式.

以CL为单位,合并的单元其实是一个孤立的commit,从而没有merge的必要.或者说只允许fast-forward方式的mrege.

这种方式下面,如果CL完成之后,而trunk的代码有了其他的变动的时候,这个时候就需要rebase了.

而以branch为单位进行提交那么就必须进行merge.

以CL为单位的有一个潜在的好处,就是在出现regression的时候,可以方便的进行revert,而branch merge的话,相对会略微麻烦一点.

gerrit的其他

gerrit还有其他缺点啊.

• syntax highlight效果不好
• 不能插入图片作为review内容

归根结底,gerrit比较适合相对重型的开发过程.

这里的重型,是指dev / build / test / review / integrate / verify / release 的过程.(唉,每一步都很重,好烦躁啊!)

而gerrit本身CL的特点,也比较容易造成commit比较容易累积在一起,从而形成一个重的CL.(好重,好烦!)

gerrit接口

我所注意的,gerrit有两大类接口

plugout

gerrit本身的系统主体有java构成,部分扩展可以采用prolog.

因为我不能在工具选型上有发言权,而且这种工具的时候,已经是相对稳固的,替换成本也很高.同时我还不是系统管理员(如果真的就让我当admin,说不定我还不愿意呢)

而我还是有一些扩展gerrit的需要.

这个时候就不能采用一般的plugin了,因为我不是管理员嘛,根据没有办法给它配置插件.

而且,我们的需求有着太多的细节点,用gerrit的插件的话,也不容易满足灵活性的要求.

CLDog

这是一个集成发布的提醒系统.

主要功能,就是在新的发布版本出来的时候,给新加入的每个CL的作者发送邮件提醒,他的CL已经进入trunk了.对于bug fix的CL,同时提醒其在bug track系统中标记.(呃,还没有和JIRA集成)

在将所有的commit汇总,做一个总结的excel文档出来,发送给manager.

关键工具

• crontab
• python
• xlsxwriter
• sh
• git

细节就不展开了,也没有太大的意思,如果有需求,我可以再展开讲.

CLDog和gerrit其实基本没有关系的.

gering

对于不同的模块,肯定有比较熟悉的人或者负责人,那么就需要他进行review.

gerrit有插件reviewer和git-blame reviewer插件.其中blame插件的比较有意思,就是根据修改模块,它在历史上被修改的行数最多的那个人,让他来review.

不过在相对集中的组织里面,这种方式不是很好用.

而且,我们开发的周期比较长,大家又比较忙,我们的模块也不是简单按照文件或者文件夹来划分的.

这个时候就需要一个插件来完成这部分功能.

原理非常简单,现在简单总结完毕:

• ssh gerrit stream-events, 从gerrit得到内部的事件,以JSON格式作为一行内容返回到标准输出
• python脚本,读取,解析JSON,根据相应的类型,内容,来具体进行一些信息.
• 调用ssh gerrit set-reviews, 设置reviewer.

其他额外需要考虑的有:

• xlrd读取excel文件,得到相应的模块或者branch对应的review的人的列表

进阶

对于set-reviewers可能比较简单,对于检查是否达到submit标准,可能需要记录下类似的信息
{(CL-Number, PatchSet) : {VRIF: vrif_val, REVW: [author0, author1, …]}, …}

这样的话,其实也没有别的问题,但是为了方便调试,可能会重新启动程序,这个适合上面的字典信息,就可能会丢失.
而无法重现gerrit的event,就存在问题了.

这个时候,就可以利用一些持久化的库,利于pickle,或者json.

在收到对应的例如KeyboardInterrupt的时候,调用持久化的功能,将其存储到硬盘上.
当下一次启动的时候重新载入.

总结

好像也没有什么特别的,早知道就不专门写一篇东西出来啦.

主要是感觉gerrit的这方面的中文资料好像不是很多,这里就作为一个补充吧.

如果有需要拓展gerrit的,可以随便看下,找个思路.