《豆瓣阅读中的持续集成和发布实践sunyi.ppt》由会员分享，可在线阅读，更多相关《豆瓣阅读中的持续集成和发布实践sunyi.ppt（34页珍藏版）》请在三一文库上搜索。
1、豆瓣阅读中的持续集成/发布实践,豆瓣 孙毅,豆瓣阅读,豆瓣阅读是 豆瓣读书推出的数字阅读服务 拥有质量一流的内容 支持Web、iPad、iPhone、 Android、 Kindle等多种设备 提供极佳的阅读体验 社会化阅读,Why CI?,减少风险 减少重复过程 任意时间，地点可部署 可见性 信心,场景1-开发,本地服务起不来了？,依赖！,提交了才发现问题？,开发服务器网速赶不上手速,问题分析,开发环境复杂且不统一 本地构建困难 本地没有快速反馈机制,解决方案,本地的统一的虚拟开发环境,订阅上游依赖变更，用puppet管理 大家一起贡献模块 基准开发工具包 简单便捷的本地ci,订阅上游依赖变
2、更,必要性 包依赖开发环境必须和线上环境同步升级 公司内部的服务依赖，lib依赖版本升级 现状：RSS订阅依赖更新消息 不是很先进，但是还算可靠,大家一起贡献模块,必要性 项目众多，每一个项目依赖和工具不同 现状： fork，pull-request Puppet主文件中用注释进行特性开关,基准开发工具包,工具的种类/版本 工具的配置 现状： 静态检查 单元测试 Web测试,简单便捷的本地集成(1),pylint/jshint 基准开发工具包包含工具 随项目代码进行检查项配置 git pre-commit hook,简单便捷的本地集成(2),unittest/apitest 不干扰本地开发服务
3、 coverage nosy/tag/etc,简单便捷的本地集成(3),web测试 headless webdriver js error collection html error collection xunit,对比,场景2-提交,好大一个diff！,懒得review,合入的时候咋办啊。,这功能谁搞挂的？,问题分析,review流于形式 分支合并成本高 问题定位困难,解决方案,git / pull-request,git分支的切换和合并成本极低 以pull-request作为review单元 鼓励更多提交，强制review后合并 review覆盖面，针对性和参与度高 几乎每次merge都
4、会触发构建 pull-request的粒度保证问题追查较容易 通过构建job通知提交作者,对比,场景3-构建,大家都喜欢下班前提交,跑一遍要20分钟！,CI服务器又排队。,跑了15分钟才告诉我没通过 : (,merge把主干搞挂啦,问题分析,分支集成不足 ci suite反馈速度慢 无法获取阶段结果 持续集成服务器资源问题,解决方案(1),基于opening pull request的分支持续集成,解决方案(2),构建链/测试分级,解决方案(3),冗余计算资源利用 虚拟机开启jenkins-slave模块即接入ci系统 控制node的tag来分配接入的job,对比,场景4-交付,上哪个版本？,XX不在，怎么上线来着？手抖了。,怕出线上问题啊,解决方案(1),继承ci suite的版本状态监测/标记 提交构建 打包打tag,解决方案(2),特性开关 重大变更 均使用feature-switch switch 多种状态，可在线切换,解决方案(3),直接从ci集成自动化上线 从ci suite传入可上线的tag 由jenkins job自动执行远程脚本 直接点击按钮触发,待解决的问题,移动端,前端,ut提速,Q & A,您也可以通过以下方式找到我： 豆瓣主页： http:/ Email： ,Thanks,