测试部门通过持续集成的破局之路.docxVIP

测试部门通过持续集成的破局之路 甘晖@阿里游戏 G O P S 2016 全球运维大会 · 深圳站 项目背景 功能繁复 多团队协同  迎合市场节奏 压缩开发周期 G O P S 2016 全球运维大会 · 深圳站 原开发流程 瀑布流 分支开发，主干发布 手工测试，人工部署 需求 开发 合并 测试 灰度 发布 需求PK 设计评审 拉取主干 系统测试 Bugfix 合并主干 需求评审 编码 代码合并 专项测试 验证指标 版本发布 研发自测 发布性验证 G O P S 2016 全球运维大会 · 深圳站 原开发流程 瀑布流 分支开发，主干发布 手工测试，人工部署 需求 开发 合并 测试 灰度 发布 需求PK 设计评审 拉取主干 系统测试 Bugfix 合并主干 需求评审 编码 代码合并 专项测试 发布指标 版本发布 研发自测 发布性验证 发布时间无法确定 G O P S 2016 全球运维大会 · 深圳站 惨状 线上问题比例 12% 6轮回归，还有bug 核心功能回归需1人日 漏掉4个需求点 核心指标跳水 ?不是正在回滚，就是在回滚的路上 时间不可控 质量不可控 G O P S 2016 全球运维大会 · 深圳站 解决思路 持续集成 Continuous Integration 提交 测试 代码 化整为零 分而治之 构建快速反馈 改进品质并减少风险  反 馈 G O P S 2016 全球运维大会 · 深圳站 解决思路 进一步 持续交付 灰度/ 编译 Continuous Delivery 发布 代码 持续集成不能解放运维 反 持续交付可以 馈 部署 构建 测试 快速验证 改进品质并减少风险 G O P S 2016 全球运维大会 · 深圳站 解决方案 双重持续交付 拉取主干 主干 分支 2 分支持续交付 ? 合并效率低 ? 发现bug滞后 ? 回归工作量大  ? 缺陷难以收敛 ? 质量不可评估 ? 完成度未知 ? 指标无法收集 主干持续交付 合入主干 分支灰度通过 G O P S 2016 全球运维大会 · 深圳站 实施措施 代码管理 构建 测试 灰度发布 自测通过方 自动构建 一键部署 可提交 自动化测试 平滑灰度 数据收集 日合主干 静态测试 功能体验 反馈 自动化工具/测试是持续集成的基础 G O P S 2016 全球运维大会 · 深圳站 持续构建 拉取编译 本地自测 检查反馈质量 每日提交 生成部署包 及时合并 触发构建 分而治之 小步快跑 G O P S 2016 全球运维大会 · 深圳站 持续构建最佳实践 G O P S 2016 全球运维大会 · 深圳站 持续测试 ? 编译 快速重复自动的测试 代码 -持续评估质量 ? 静态检查 部署运行 服务 ? 自动化 ? 功能 ? 内部体验 G O P S 2016 全球运维大会 · 深圳站 持续测试最佳实践 代码层测试 服务层测试 功能测试 UI测试  自测通过，方可提交 日合主干 自动构建 静态测试 自动化测试 专项指标测试 核心功能体验 一键部署灰度 数据收集反馈 G O P S 2016 全球运维大会 · 深圳站 代码层 测试 G O P S 2016 全球运维大会 · 深圳站 服务层 测试 G O P S 2016 全球运维大会 · 深圳站 功能 测试 汇总测试结果 触发功能自动化测 试 触发测试工具 G O P S 2016 全球运维大会 · 深圳站 持续发布 持续集成 ? 编译构建 ? 自动化测试 ? 审查评估 反馈 达标 立体化分层监控 业务指标报表数据采集 用户反馈收集 用户行为收集  一键部署/平滑发布 持续交付 ? 灰度控制系统 ? 名字服务调度 ? 动态升级 用户 自动化是持续的基石 G O P S 2016 全球运维大会 · 深圳站 持续交付 交付是DevOps的核心能力 G O P S 2016 全球运维大会 · 深圳站 持续反馈 反馈是PDCA的下一个开始 G O P S 2016 全球运维大会 · 深圳站 持续反馈 G O P S 2016 全球运维大会 · 深圳站 破局效果 发布 质量  线上问题：-33% 核心指标：稳定 更好 发布 效率  ?如期发布：80% 测试周期：-30% 更高 交付 成本 如期 高效 高质  业务运维：6 - 0.5 部署时间：15 - 1 回滚次数：5 - 0 更低 G O P S 2016 全球运维大会 · 深圳站 实践小结 目标 方案 关键行为 结果 ? 高效 ?工程化 ? 自动化 ? 如期 ? 高质 ?持续交付 ? 双重灰度 ? 高质 ? 低成本 ? 数据反馈 ? 高效 G O P S 2016 全球运维大会 · 深圳站