采用gerrit进行code review实现continuous deployment

在公司的开发过程中，以前代码开发，发布流程如下：

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

公司内部有个svn作为central repository，每个工程师checkout代码，并每天多次checkin(commit)

没有分支管理，大家都工作在trunk下，实际上大家在比谁手快，因为后面的人要处理conflict

公司内部用php开发了一个发布上线系统：每个人通过该系统发布代码(就是上传要上线的文件)，发布系统处理一些sanity工作：php lint检查代码是否有明显的语法错误(实际上就是php -l filename.php)，基本的代码规范(实际上很简单，没有用到CodeSniffer和PMD)，合格后，发布到公网的一个测试机(staging)，该测试机连接的服务器(包括memcache/mysql/ICE/etc)，也就是个基本真实的线上环境(还有部分失真，例如没有haproxy进行逆向代理)，然后QA进行测试。

测试没有问题后，提交代码的工程师通过发布系统提交code review request，基本上都是提交给自己的上级(单向的)，然后，发布系统会自动发送邮件通知reviewer，reviewer登录发布系统，检查diff(该diff很丑陋，没有语法加亮，没有side by side diff，如果diff行数很多，对reviewer这是个灾难)，合格就点击“review ok”按钮。之后，发布系统会发送邮件通知提交代码的工程师review passed，然后，提交代码的工程师点击“发步到正式环境”。

系统会采用多层级的rsync(被rsync的服务器比较多，有数千台)，分发到所有的web服务器上。

这就是以前的整个开发部署流程。

可以看到，存在很多问题：

code review过于滞后，变得流于形式

svn trunk是不干净的，每个开发人员时刻都在污染trunk

发布系统里的代码是开发人员通过web browser上传的，与svn是没有关系的

开发人员要花很多的时间处理发布的事情，他们应该仅关注代码，而非上线流程。上线的事情，应该有专门的角色来处理

本人经过痛苦的经历后，采用了新的方法，引入了git和gerrit，引入了分支管理和tag。

解决了以上的问题

但考虑到无法一步到位切换到git，因此还需要git svn共存很长时间：

过渡期流程：

最终流程：