总体说明

技术中心目前的发布模式比较传统,通过人工方式进行拷贝,敲击重启命令发布应用,费时费力,并且容易出错,经常因为一个发布文件拷贝问题导致加班熬夜发布,对研发、测试、发布人员都造成了不少的伤害。

实际上,很多先进的科技公司早就实现了自动编译部署,那么下面我们就介绍一下目前技术中心将要执行的半自动化发布过程,其中研发环境实现全自动无人发布模式。

 下图为技术中心整体的发布模型:

 

1、  开发人员提交代码到SVN库。

2、  Jenkins服务检测到SVN库变更后,从SVN获取最新代码并自动编译和部署到开发测试环境。注意这个过程在研发过程中是持续进行的。

3、  当一个项目周期完结或者一个用户故事开发完成后,研发人员在开发测试环境测试已经没有问题了,这个时候发布人员会将最后一次成功发布版本标记为SVN tags版本,并将tag版本编译部署到beta测试环境,当然这个部署过程也只需要一个按钮点击部署就可以了。

4、  beta环境部署完成后,测试人员开始在beta环境验证测试,包括功能测试、压力测试等。

5、  当在beta环境测试过程中出现了不少bug,如果开发人员已经在新的分支开发,那么切换到原来的分支上修改bug,并将修改后的代码与现有分支合并。否则发布人员只是将代码合并到当天beta环境对应代码的tags,然后再次进行步骤3进行部署修复。原则上不允许单独发包到各个测试环境。

6、  beta环境功能验证通过,然后产品也验收通过,业务方也同意发布,即满足发版条件后,发布人员通过类似步骤3,将最后一次beta环境对应程序部署到正式环境,也只需要一键部署。

 

部署说明

上面描述了一键部署,那么具体如何部署?下面介绍jenkins的基本使用,将通过角色来描述。

Jenkins的常规操作这里不再描述了,主要介绍我们各个产品的发布方法。

 

开发人员

 开发人员默认不用关心发布过程,只要正常提交代码后,jenkins会自动进行编译发布,并且会将发布结果邮件通知到开发人员。

 But,有时候如果迟迟收不到邮件,那也没有关系,通过登录Jenkins后,找到自己的项目,点击立即构建即可,如下图红框位置:

 

   

 

测试人员

测试人员默认情况也不需要关系发布的过程,but,发布人员不再怎么办?

  那也没有关系,通过登录Jenkins后,类似开发人员的操作即可,不过发布beta环境不是自动的,而是要手工点击的,如下图:

其中红框位置为最后一次的tag标记。

注意:如果标记不是最新,那么发布上去的可能是旧版本,所以这里一定要和发布人员沟通好,及时合并最新可用TAG发布。

发布人员

发布人员统管整个发布过程,主要有:beta发布,release发布,版本维护,配置管理,资料整理等工作。

 

 

Jenkins任务

具体见下表:

任务名称

权限人员

任务说明

dev-build-api

开发人员

发布人员

公用API服务接口

dev-build-erp

开发人员

发布人员

开发测试环境部署任务

dev-build-bup

开发人员

发布人员

开发测试平台部署任务

dev-build-appserver

开发人员

发布人员

开发测试环境APP服务端部署任务

beta-build-erp

测试人员

发布人员

BETA测试环境部署任务

beta-build-bup

测试人员

发布人员

BETA测试环境平台部署任务

beta-build-appserver

测试人员

发布人员

BETA测试环境APP服务端部署任务

release-build-erp

发布人员

正式环境部署任务

release -build-bup

发布人员

正式环境平台部署任务

release -build-appserver

发布人员

正式环境APP服务端部署任务

 

 

从表中也可以看出:

dev开头的为开发测试环境编译任务;

       beta开头的为beta测试环境编译任务;

release开头的为正式环境编译任务;

aerfa开头的为与阿尔法测试环境编译任务;

 

在添加任务的时候谨记该规则,防止出现问题。

 

工作模式

在日常工作中,一般出现编译报错,需紧急解决编译问题,并且编译出现问题大多情况下:

1、  版本冲突

2、  代码错误

3、  提交不完善

4、  不符合开发规范或原则

5、  使用了非标准jdk开发

6、  。。。

 

为了工作有序稳定的进行,对代码的提交有硬性要求。

非紧急情况发布过程全部走系统,避免人为参与拷贝代码。



本文版权归作者,欢迎转载,但未经作者同意必须在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。