移动App持续交付之路教学内容.pptx

移动App持续交付之路 持续交付介绍交付pipeline交付协同交付效率交付质量 2交付pipeline 135246代码变更以项目为粒度进行APP产品需求迭代测试通过自动化工具解决质量问题运维实时获取线上APP的异常情况集成通过发布区来协调不同的业务发布灰度/动态部署/渠道热修复实时修复线上突发情况 3交付协同 研发协同以项目为粒度协同开发、测试、安全、PM资源质量协同在发布前需要各项目确保测试验证成功发布协同通过设立发布区的方式协同不同的业务需求，集成同一周期的业务交付协同 项目：研发活动的承载空间发布区：用于发布的特殊项目，用于集成管控、构建、测试、发布协同等操作交付协同 4交付效率 平均5天一个全量发布问题发现+问题定位+bug修改+bug测试+热修复<1小时移动APP研发效能指标双十一weex页面秒开率 交付效率开发测试发布 开发框架通用组件二进制交付依赖管理开发效率 开发效率 测试效率针对空指针异常定义规则使crash占比从30%降低到10%以下代码扫描工具自动化工具智能monkey通过monkey发现的crash类型占比达到30%以上UI自动化有效降低测试成本提升执行效率 案例说明 测试效率0102030401月2月3月4月5月6月7月8月9月10月11月12月手淘客户端空指针异常导致的crash占比情况 分发要稳定实时数据用户舆情反馈性能监控实时crash率业务核心指标实时数据风险控制按业务核心指标（性能、效果）提前退出按稳定性（crash率）实时止血按用户反馈问题中断发布回滚限动态部署发布分发要精准发给谁？版本/渠道设备/机型/OS网络（2G/3G/4G/wifi）IP(基于LBS)发多少？用户量控制：通知上限多批次分发：过程可控发多久？时间设定：开始时间/结束时间怎么发？提升更新/静默更新/强制更新发布效率 案例说明缩短发布周期，更快响应市场稳定性提升，版本crash率可控不同FT之间的功能验证，不再互相依赖用户可以看到持续的改进某APP通过自身业务用户画像及发布版本的crash标准，自定义灰度策略，一旦crash率达到上限或者用户舆情反馈超过阈值或升级用户数已满足产品要求，即停止分发。某自2017年接入EMAS起采用精准推送进行灰度，正式发版时间缩短7天，javacrash率可控制在0.2%以下。提醒1w人安装650人反馈问题9人 5交付质量 手机淘宝质量数据在高速迭代的情况整体javacrash一直维持在极低的水平故障的监控发现率 效率1.问题定位时间长2.线下测试成本高3.问题多、解决意愿低度量体系检测组件库统计组件启动性能布局性能静默CPU消耗FPS页面分析ANRCrashTLogCustomErrorTrace资源检测内存泄露卡顿检测流量检测OverDraw检测…网络通道(卡口&在线)本地展现(Debug）通知栏客户端List展现REST接口AppMonitor智能分析体验指标度量错误度量业务度量多纬度分析异常数据实时展示错误聚合Detail跟踪自定义模式实时统计日志分析主因分析多维度精准告警体系精准1.发生了什么？2.什么原因导致？3.怎么解决？ 全生命周期集成工程理念效率质量持续交付