呼和浩特治白癜风最好的医院 http://baidianfeng.39.net/a_zhiliao/131209/4304458.html
背景

最近公司越来越重视代码管控和发版质量，目前采取的策略是：

研发人员每天提交一次代码，每周五进行一次集中式编译、打包、发版等一系列活动；代码需要研发人员先在本地编译通过后再提交代码仓库，在指定的执行机上由测试人员进行拉取代码、编译打包，然后测试手动上传到开发、测试、预发布等各个环境进行替换发版，最后再登录各个系统查看有无最基本的问题；每次构建，要确保能够顺利通过，发版后不能影响到旧功能，新功能不能出现影响业务流程的报错，最终提交的代码才能视为合格有效；

这么做的好处是：

明确了研发与测试人员的职责边界：研发就是写代码、上传代码，不负责编译、打包，测试人员负责编译、打包、发版等活动，避免研发人员私下修改代码；隔离开发人员本地环境与编译环境：研发人员本地编译通过，再提交代码至代码仓库，由测试在第三方机器上进行拉取代码，执行编译，二者环境相互隔离、互不干扰；确保了每次提交的都是有效代码：提交的代码不能影响到旧功能，也不能出现明显错误；

但带来的弊端也显而易见：

流程长：研发提交代码-测试拉取代码-测试执行编译、打包-测试将打好的包替换到指定服务器-重启服务、完成发布，手工测试验证基本功能；成本高：流程长同样也带来了高成本，众多项目叠加在一起，测试每个项目都要验证，平均每周五需要花费至少1-3h的时间成本；效率低：沟通都是通过口头或