[互联网]豆瓣阅读中的持续集成和发布实践.pptVIP

待解决的问题 移动端 前端 ut提速 Q A 您也可以通过以下方式找到我： 豆瓣主页： /people/tachikoma/ Email： sunyi@ Thanks * 必要性 python/js/ruby没有编译过程，需要加强静态检查 相关工具 pylint jshint 什么是好的检查结果 无噪音——定制配置文件 高效——去掉不关心的项；有diff的文件才做检查 可视化 快速 * 必要性 提交到master之前，应该做好本地集成 相关依赖nosetests 本地简易ci: nosy tag支持: -a tags=“gift” run failed: --failed fast fail: -x debug: -pdb * 必要性 伤筋动骨的修改需要webtest保证 虚拟环境 相关依赖xvfb/firefox/webdriver/nosetests 封装webdriver xunit模式写webtest xvfb代替x环境 * 必要性 python/js/ruby没有编译过程，需要加强静态检查 相关工具 pylint jshint 什么是好的检查结果 无噪音——定制配置文件 高效——去掉不关心的项；有diff的文件才做检查 可视化 快速 * * 特性分支集成难 review流于形式 提交习惯扭转 * * * * * * * * ios移动端ci 用ynm3k实施移动端自动化 * * * * * * * * * * * 豆瓣阅读中的持续集成/发布实践 豆瓣 孙毅 豆瓣阅读 豆瓣阅读是 豆瓣读书推出的数字阅读服务 拥有质量一流的内容 支持Web、iPad、iPhone、 Android、 Kindle等多种设备 提供极佳的阅读体验 社会化阅读 Why CI? 减少风险 减少重复过程 任意时间，地点可部署 可见性 信心 场景1-开发 本地服务起不来了？ 依赖！ 提交了才发现问题？ 开发服务器网速赶不上手速… 问题分析 开发环境复杂且不统一 本地构建困难 本地没有快速反馈机制 解决方案 本地的统一的虚拟开发环境 订阅上游依赖变更，用puppet管理 大家一起贡献模块 基准开发工具包 简单便捷的本地ci 订阅上游依赖变更 必要性 包依赖开发环境必须和线上环境同步升级 公司内部的服务依赖，lib依赖版本升级 现状：RSS订阅依赖更新消息 不是很先进，但是还算可靠 大家一起贡献模块 必要性 项目众多，每一个项目依赖和工具不同 现状： fork，pull-request Puppet主文件中用注释进行特性开关 基准开发工具包 工具的种类/版本 工具的配置 现状： 静态检查 单元测试 Web测试 简单便捷的本地集成(1) pylint/jshint 基准开发工具包包含工具 随项目代码进行检查项配置 git pre-commit hook 简单便捷的本地集成(2) unittest/apitest 不干扰本地开发服务 coverage nosy/tag/etc.. 简单便捷的本地集成(3) web测试 headless webdriver js error collection html error collection xunit 对比 before now 只能在服务器开发 可迁移/可定制的完整本地开发环境 先提交，再跑集成测试，改bug 本地先进行测试，再提交 web测试只能在中心服务器 本地web测试 场景2-提交 好大一个diff！ 懒得review 合入的时候咋办啊。。 这功能谁搞挂的？ 问题分析 review流于形式 分支合并成本高 问题定位困难 解决方案 git / pull-request git分支的切换和合并成本极低 以pull-request作为review单元 鼓励更多提交，强制review后合并 review覆盖面，针对性和参与度高 几乎每次merge都会触发构建 pull-request的粒度保证问题追查较容易 通过构建job通知提交作者 对比 before now 定期review，覆盖面小 每个pull-request必须review review意见很难定位到行 响应也不及时 review精确到行，提醒机制完善 修复一目了然 写一大堆再合并提交 天天合并/提交 (5个月，1275个pull-request，2725个review意见，全体参与) 构建diff太大，出问题不知道谁的 几乎每个构建只有1-2个merge (5个月，900次构建) 场景3-构建 大家都喜欢下班前提交 跑一遍要20分钟！ CI服务器又排队。。 跑了15分钟才告诉我没通过 : ( merge把主干搞挂啦 问题分析 分支集成不足 c