发布流程演进之路

1.前言

在***项目开始之前，整个项目组的版本控制工具都是采用的svn，代码合并以及发布工作都是由开发、运维来控制的，自***项目作为一个新项目启动，版本控制工具就由svn换成了git，我们考虑到如果git代码合并以及线上发布权限收归测试来掌控，一是可以控制上线发布的频率，防止产品随意插单，二是上线由QA来控制能够有效保证上线质量；既然对产品质量有利无害，那我们就妥妥的干起来。在这里我就介绍下在QA主导下的发布流程演进过程中发生的那点事。

2.前期项目的情况:

首先介绍下***项目的测试流程，我们测试流程一共分4个环节:

1)        测试开始，把feature开发分支代码合并到test分支，QA把test分支代码发布到测试环境测试，测试完毕没问题之后，把test分支代码合并到develop分支进入到第二个环节;

2)        把develop分支代码发布到测试环境进行回归测试，测试完毕之后把develop分支合并到master分支；

3)        把master分支发布到在线确认环境测试；

4)        把master发线上，在线上再确认一遍；

具体的git分支版本管理流程如下:

我刚开始接手发布的时候，git代码合并、发布上线的权限是分配给了项目组的所有测试人员，合并代码、上线发布大家都能操作，在这个过程中出现了以下问题:

1)        在feature→test→develop→master这个合并代码过程中经常出现每一步都有代码冲突的情况，每天花费在解决冲突上的时间较长，极大的耽误开发、测试的时间，一定程度上降低了工作效率；

2)        接口发布上线过程中由于等待所有接口测试完毕，导致过一次发布了26个接口，合并解决冲突就弄了2天，同时也造成了极大的上线风险；

3)        针对接口上线，由于DBA没有提前审核好sql、运维没有修改好配置和调数、运营没有提前配置好权限都会延迟接口上线时间，进而延迟客户端发版；

4)        从一个分支合并代码到另外一个分支，后台普通采用cherry-pick的方式来合并，针对提交次数少的情况下问题不大，但是对于大的功能有几十个提交，采用这种方式极易会丢失版本；

5)        从周一到周五随时提需求随时发，造成发布频率过高，给线上质量带来一定的隐患；

6)        由于没有提前掌握每天发布的需求数量，导致有时候一天一个上线需求都没有，有时候一天很多需求堆积上线，需求太多发布时间就会拖的很晚，而太晚发布时功能相关人员不一定都在，这样就可能会导致当天不能发布上线，需求延期；  

7)        一次上线的功能太多时，经常出现其中一个功能有问题导致其他所有功能都不能正常上线；

8)        功能测试正常之后，在利用ops系统发布时即使发布日志显示正常，发布线上之后也会出现线上问题；

9)        没有统一的沟通平台，由于欢乐购项目有4个系统:hyg、notify、api、g，在发布不同功能时，需要发布不同的系统，在QA发出发布邮件之后，只要开发负责人回复了邮件，QA就默默的发布了，直到最后大家一起来确认功能，但是这个发布过程发布了哪些系统哪些机器大家不可知，出了问题不能及时解决；

3.措施的制定及实施效果

3.1.措施的制定

针对上面的一些问题，在跟开发、测试沟通之后，采取了以下的一些措施:

1)        针对合并、发布权限问题，除了合并test分支，合并develop、master分支的权限全部收回(设置为了保护分支)，只给开发和测试组的leader保留，发布上线权限也只给各组leader保留，但是正常发布只让专门的发布人员进行发布；

2)        针对冲突问题，由于代码合并步骤是feature→test→develop→master，并且很多时候在合并之前没有同步develop分支代码，所以只要在第一步出现了冲突，后面很多时候只要是合并都会出现冲突，而且每个测试人员测试进度不同，合并的顺序打乱之后也会增加代码的冲突概率，所以这里要求开发、测试每天同步develop分支到本地，develop分支的功能代码不过夜，一旦代码合并到develop分支之后如果当天不能发布上线，全部回滚，保证develop分支和master分支代码一致，而且在develop分支合并代码到master分支的时候都采用 git merge的方式，这样一是保证代码不会挑漏二是能避免合并顺序的不同增加代码冲突概率三是这种合并代码方式更快捷；

3)        针对接口的问题，为了避免功能都堆积到一起发布，我们采用了一期客户端接口分多次上线方式，只要功能没有关联，测完一批上一批，不等待所有功能在一起发布，而且每批接口不超过10个，另外很多接口功能涉及到DBA建表、申请物品权限、在线确认等环节，一天很难全部弄完，为此我们把这些工作都要求在上线的前一天全部做完，保证在上线当天只需要完成在线上确认的工作，另外确保在客户端发版日提前三天就把所有接口都发布上线，这样可以让客户端发版之前直接在线上进行测试，提前发现线上问题；

4)        为了避免发布的无序以及经常临时发布需求，我们规定常规发布时间为周二、周四，并且在下午2点之前截止收版本，4点之前发布；紧急发布在每天4点之前，并且紧急发布的需求必须经过产品负责人和开发负责人邮件回复同意，否则不予发布；bug修复随时发布；

5)        另外我们建立了统一的项目发布群，并且申请了线上服务器权限，在每发布一个系统时都先发该系统的一台机器，确认发布日志和后台日志没问题，再发布该系统的所有机器，这样即使出了问题也能提前知道并且让影响面缩小，并且这个过程的每一步都在群里说明，让开发、测试及时查看日志，有问题及时回滚修复；

6)        每周五从产品、运营处提前收集下周需要上线的需求，周一把收集到的功能发给整个项目组周知，这样让项目组所有人员都掌握发布进度；

7)        我们开发了产品发布管理平台，把所有发布相关信息进行记录，对插单信息进行统计，预防产品插单；

3.2.实施的效果

• 按照上面措施执行之后，合并中代码冲突的情况大大减少，接口上线也再没有出现一次把所有接口上线的情况，而且都在客户端发版之前提前上线；跟产品沟通后，现在产品都能遵循常规上线日期为周二、四，插单需求也减少了很多；

• 建立了统一的popo沟通群，发布的整个过程都让项目组所有人知晓，通过查看服务器日志，中间出了任何问题都能及时的响应，对线上质量起到了保障的作用。

4.发布流程改进

但是上面流程执行了一段时间之后，一次对代码的回滚事件暴露了这个流程中的一个严重问题；

事情发生的经过是这样的:一般功能在在线确认环境中如果出现了问题我们首先会对master分支相关功能代码进行回滚，在git中关于回滚的命令有两个，一个是git revert，一个是git reset，这两个命令虽然都可以回滚代码，但是起到的作用差别很大，前面说过，我们合并代码的方式都由git cherry-pick改为了git merge，由于我们这边都是并行开发，所以在代码合并的过程中经常出现三方合并(参考http://git.oschina.net/progit/中3.2)的情况，针对这种情况如果采用git revert的方式去回滚，很多时候会出现两个父分支，这样回滚就非常麻烦，所以一般我们就采用了在本地执行git reset –hard commit_id再通过git push –f的方式推送到远程，此种方式针对cherry-pick方式合并的代码没出现过问题，但是针对git merge方式合并的代码就会导致版本丢失和回滚不干净的情况，所以针对这个漏洞，前端同学提出了一个方案:以后每天从master分支新拉release分支，线上发布用release分支发布，发完之后大家确认功能没问题，对master分支进行备份之后，再把release分支合并到master分支，master分支只是作为一个备份分支，不再充当发布分支的功能，回滚也不采用git reset的方式，而是通过直接发master分支进行回滚；

    修改了之后，新的git版本控制流程如下:

同时，由于流程做了修改，我们之前针对第一版流程的措施中同步develop代码的操作也相应的做了更改，以后开发分支都是从master分支上拉取，并且每天同步master分支，为此前端同学利用git 的web hooks功能开发了一个popo提醒功能，一旦代码push到master分支，会给相关人员发送popo信息，提醒大家同步master分支代码；

     经过此次的修改，该流程执行到目前已经有4个多月的时间，发布过程一直都非常顺畅；

5.写在最后

   上面就是***项目中发布流程演进的整个过程，这个流程中目前只是应用在运营活动、接口、wap端、后台发布中，对于线上发布流程，每个项目由于实际的开发测试流程不同而不同，把这个过程分享出来，也希望能给大家一点借鉴。