GOPS2016-SZ-测试部门通过持续集成的破局之路TBD.pptx

测试部门通过持续集成的破局之路甘晖@阿里游戏项目背景原开发流程Bugfix验证指标需求PK需求评审设计评审编码研发自测拉取主干代码合并合并主干版本发布系统测试专项测试发布性验证原开发流程测试消耗结果滞后运维消耗难以排查代码冲突依次阻塞Bugfix发布指标需求PK需求评审设计评审编码研发自测拉取主干代码合并合并主干版本发布系统测试专项测试发布性验证惨状功能回归需3人日 6轮回归线上问题比例 12% 核心指标跳水不是正在回滚就是在回滚的路上时间不可控质量不可控解决思路持续集成Continuous Integration反馈化整为零分而治之改进品质并减少风险解决思路 进一步持续交付Continuous Delivery反馈快速验证快速反馈改进品质并减少风险持续交付 实施措施自动化工具/测试是持续集成的基础持续构建持续集成利器Jenkins持续构建最佳实践分而治之 小步快跑持续测试自动化，让测试高频、低成本地持续进行持续测试最佳实践代码层 测试服务层 测试功能 测试触发功能自动化测试触发测试工具汇总测试结果持续发布编译构建自动化测试审查评估达标反馈一键部署/平滑发布灰度控制系统名字服务调度立体化分层监控业务指标报表用户行为收集用户自动化是持续发布的基石持续交付交付是DevOps的核心能力持续反馈持续反馈反馈是PDCA的下一个开始实施方案缺陷难以收敛发现bug滞后回归工作量大双重持续交付5 主干持续交付合并效率低质量不可评估完成度未知指标无法收集1 拉取主干主干4 合入主干分支3 分支灰度通过2 分支持续交付破局效果如期 高效 高质实践小结破局的思考持续交付支撑部门的红利自动化-解放生产力数据化-对产品的信心频繁交付-迅速响应谢谢自我介绍，自动化运维会场，测试破局，和运维相通，如何与运维同学携手的案例在场都是运维同学为主支撑部门的测试和运维，主要提供内部服务的角色，如何更好协作，为业务加速。拳头产品：单一项目人数近百人，并行开发超级app，承载核心功能，业务关联强手游行业竞争激烈，用户用脚投票测试的苦逼，研发delay、项目经理催deadline、用户投诉，是夹心饼*瀑布流*分支开发，主干发布*手工测试，人工部署由于 线上指标 和 质量不稳定 影响研发流程分支开发主干发布-合并（代码冲突 依次上主干）手工测试-测试时间多次灰度，人工部署-运维消耗 （joke：以前运维的kpi是一天进行多少次发布）等到所有东西都完成了才向下个环节交付，导致所有的问题只能再最后才爆发出来，解决成本巨大甚至无法解决。然那么，发布时间更确定不了总结出核心问题就是，时间、质量项目规模太大，瀑布流，问题暴露晚，缺少项目可见性、信心。集成，是指软件个人研发的部分向软件整体部分合并；持续，是说每完成一个完整的部分，就向下个环节交付。（Martin Fowler说过，"持续集成并不能消除Bug，而是让它们非常容易发现和改正。"）持续集成还不够，只解决过程质量，是实验室环境，用户性产品，给用户使用。部署是代码尽快向可运行的开发/测试节交付，以便尽早测试；交付是指研发尽快向客户交付，以便尽早发现生产环境中存在的问题。** 对于产品来说，能提前接触到用户，进行实战**从配合上看，持续集成不能解放运维，持续交付可以此页内容太多，文字太长，需要精简。白盒/接口/UI自动化测试，专项，指标（覆盖率）全部行为由Jenkins串联起来这样可以尽早发现个人开发部分的问题，发现问题可以马上调整，问题不会放大到其他部分和后面的环节，防止雪球越滚越大。刚才持续构建可以看到，任何人提交代码都可以提交测试等于给每个研发配备了测试同学，单独为其服务最佳是自动化+分层测试，越底层的越接近代码，自动化的可能性越高越底层的测试，效率越高，成本越低编译、配置问题（运维同学头痛的多环境配置）空指针，野指针，常量异常Jenkins的界面 看到具体失败的方法 基本定位到代码级输出测试结果，数据驱动去测试平台截图功能自动化，内存分析，体现结果测试、运维同学组成虚拟团队，去开发支撑持续发布能力的系统。规划好蓝图之后，研发同学也参与进来，在开放框架、工具上给予配合和支持。通过JAE一键发布，和Jenkins打通。名字服务中心，控制发布和调度。运维对线上的情况一目了然，大大提高产品的交付能力。崩溃率实时监控，预警收集可用性、响应时间收集用户意见，用于反馈。快速整理热词 聚焦问题有解决思路，解决的方案如何。双重持续交付，让 影响发布指标的功能 可以被定位出来。平滑发布让研发过程工程化，提升交付成功率，减少生产线后端团队：测试运维的压力。支撑部门的红利，得到层次的提升最终通过技术拓宽业务边界