吴思振 如何使超大型⼯程矩阵高速运转及⾃下而上的技术演进揭秘

前端狗

2019/07/09 发布于 编程 分类

GMTC2019 

文字内容
1. 25% 如何使超大型⼯工程矩阵高速运转及⾃自下而上的 50% 02. 让大家一块开发—组件管理平台 技术演进揭秘 75% 吴思振 100% 01. 平台概述 03. APP高速开发的安全保障—CI-CD 04. 闭环的开发体验—应用管理平台 05. 小结
4. ⾃自我介绍 吴思振 北京邮电⼤学09级 字节跳动 iOS基础技术部 架构师 iOS 组件化 分布式编译、超⼤型⼯程组件化、iOS CI/CD GitHub · github.com/bupterambition
5. 平台概述 项目背景 平台定位 平台技术
6. 平台概述 项目背景 业务线单一 开发人员少 代码基本相同
7. 平台概述 项目背景 开发人员剧增 异地化现象凸显 测试效率低下 业务膨胀 代码管理混乱
8. 平台概述 项目背景 工程结构简单 结构耦合,单仓库开发 功能相对单一
9. 平台概述 项目背景 工程结构复杂 组件化开发 多业务线并行 功能复用性加强
10. 平台概述 项目背景 业务 头条 抖音 西瓜 火山 多闪 …… 工程质量 技术中台 用户体验 组件 平台 版本管理 二进制化 加固混淆 分发订阅 静态分析 文档管理 项目管理 信息安全 CI-CD 应用 管理 现状 现状 横向主题 Savitar编译系统 分布式缓存 稳定性保障系统 定制式PipeLine 多仓管理 组件化开发 智能合码 批量升级 研发效率 隐私保护 • • • • 接入业务线 39 条 托管组件 688 个 最高编译速度优化提升 10 倍 配套Native支撑工具 4 个 规划 • • • 统一的客户端研发中台 完善的GUI配套工具 更加稳定的服务体验
11. 组件管理平台 ——让大家一块开发 平台背景 平台技术 平台收益
12. 组件管理平台 项目背景 抖音 基础功能重复 Feed、Account、Image、 ShortVideo、Live 维护困难 西瓜视频 代码冗余 Feed、Account、Image、 LongVideo、Tracker 内涵段子 Feed、Account、Image 今日头条 Feed、Account、Image、 ShortVideo、Tracker
13. 组件管理平台 项目背景 Analysis 01 Analysis 02 基础库混乱,重复造轮⼦子,通⽤用库 团队合作代码依赖和冲突多,协作 维护和迭代流程不不清晰 困难 Analysis 03 Analysis 04 代码逻辑互相影响,测试效率低, 代码合并困难,打包慢,流程低效 质量量难保证 Analysis 05 Analysis 06 没有完善基础流程,新APP上⼿手困 缺少⼀一个统⼀一的管理理平台 难
14. 组件管理平台 项目背景 Target 01 项⽬目组件化 Target 03 ⾃自动化构建流程 Target 02 规范的通⽤用库维护流程 Target 04 基础功能⾃自动化
15. 组件管理平台 平台功能简介 通⽤用组件管理理 开发信息数据收集 Native⼯工具⽀支撑 ⽂文档管理理
16. 组件管理平台 通用组件管理 二进制化 为所有组件提供二进制化功能,可以提高编译速 度、避免源文件暴露等问题 组件订阅 通过关注组件,可以即时的了解组件的升级动态 Issue管理 用户可以通过平台入口,向关心的组件提ISSUE 组件升级 统一三位版本号管理规则,避免版本升级混乱 静态分析 自定义规则分析组件质量 历史维护 维护组件的历史升级版本,方便回溯与追查问题
17. 组件管理平台 通用组件管理 组件维护 历史版本 信息索引 数据收集 通⽤用能⼒力力 组件 维护 升级 组件化平台 反馈 通知 查询 组件 使⽤用 屏蔽细节 CocoaPods Maven Dart Pub npm…
18. ⼯工具的探索历程 START 14:50 AM 今⽇日头条iOS版构建异常 70 Pods -> 200 Pods 业务不不停、持续组件化 测试不不停、急出测试包 • • • • 重新梳理理依赖 重构Molinillo依赖解析算法 15:10 PM 分析探索 Ruby效率太低,使⽤用C重构 不不解析依赖,类美团双Source⽅方案 18
19. • 重新梳理理依赖 • 重构Molinillo依赖解析算法 • Ruby效率太低,使⽤用C重构 • 不不解析依赖,类美团双Source⽅方案 16:10 PM 探索分析结论 使⽤用C重构、不不解析依赖 • • • • • 依赖打平 ⾃自动解析Podfile.lock 16:50 PM 确定⽬目标 Hook CocoaPods-Core 操作可逆 通⽤用、简易易、可复制 19
20. 18:10 PM 开发出解决⽅方案 形成了了iOS端平台级APP的依赖解析⽅方案 END 20
21. Pod
22. Podspec Sub
23. Pod
24. Pod Subspec1 Subspec2 Subspec3
25. Pod Subspec1 • Subspec2 单个Subspec⽆无法独⽴立编译 Subspec3
26. Pod Subspec1 • 单个Subspec⽆无法独⽴立编译 • 多⼯工程差异化复⽤用 Subspec2 Subspec3
27. Pod Target1 Target1 Subspec1 • 单个Subspec⽆无法独⽴立编译 • 多⼯工程差异化复⽤用 Subspec2 Target2 Target2 Subspec3
28. Pod • 单个Subspec⽆无法独⽴立编译 • 多⼯工程差异化复⽤用 • 全量量Build、按需取 Subspec1.a Subspec2.a Subspec3.a
29. Pod • 单个Subspec⽆无法独⽴立编译 • 多⼯工程差异化复⽤用 • 全量量Build、按需取 Subspec1.a Subspec2.a Subspec3.a
30. Pod • 单个Subspec⽆无法独⽴立编译 • 多⼯工程差异化复⽤用 • 全量量Build、按需取 • 转化维度 Subspec1 1 22 Subspec2 5 3 4 6 7 Subspec3
31. 2 Subspec1 1 3 4 • • 单个Subspec⽆无法独⽴立编译 多⼯工程差异化复⽤用 • 全量量Build、按需取 • 转化维度 Subspec2 2 5 3 6 3 4 Subspec3 6 7
32. 组件管理平台 平台收益 多样化代码检测工 具,定制化代码质 量服务 通用的组件管理, 更专注于开发本身 完备的开发信息收 集,自动化管理代 码问题 明确的责任人与维 护流程,完善的使 用文档
33. CI-CD APP高速开发的安全保障
34. CI-CD平台 高速稳定建设 平台背景 积累代码量庞大,编译缓慢 业务激增,打包量持续攀升 各类编译错误持续困扰
35. CI-CD平台 高速稳定建设 Savitar稳定性建设 异常缓存清理系统 预编译、daily build策略 错误分类分发系统 错误自动修复重试系统 数据收集系统(编译惩罚)
36. CI-CD平台 高速稳定建设 Savitar稳定性建设 Pre_Build Daily Build Feature Build 发布平台调⽤用打包 cocoapods异常缓存定向清理理系统 xcodebuild 错误分类系统 ⾃自动修复系统 IPA产出 信息收集 db
37. CI-CD平台 高速稳定建设 Savitar稳定性建设 出包失败 5.8% 取消打包 0.3% 5⽉: 出包次数:1885 成功次数:1770 其中有259次成功是由于稳定性系统保护的 这套稳定性策略系统,使得打包失败率降低2倍以上 出包成功 93.9% 出包失败 出包成功 取消打包
38. CI-CD平台 高速稳定建设 Savitar效率建设 105 101 调度系统 105 102 监控单元 103 决策单元 104 执⾏行行单元 关键词: 分布式、监控、决策、增量编译 105 105
39. CI-CD平台 高速稳定建设 Savitar效率建设 105 206 203 101 调度系统 105 102 监控单元 103 决策单元 104 纠错系统 202 最⼩小编译单元 查找系统 任务分配引擎 206 204 纠错系统 207 分布锁 产物同步聚合 执⾏行行单元 206 105 205 纠错系统 通知系统 105
40. CI-CD平台 高速稳定建设 Savitar效率建设 Cache更新重制系统 新缓存源源不断生成 Proj_File处理系统 工程文件配置 Library生产系统 链接库生成 Cache处理系统 缓存的增删改查处理 Distance裁决系统 计算出最小差值缓存
41. CI-CD平台 高速稳定建设 平台收益 360秒内 24.5% 420秒内 12.4% 不不使⽤用Savitar构建 12.0% 240秒内 18.1% 270秒内 15.9% 300秒内 17.0%
42. CI-CD平台 高速稳定建设 平台收益 110% 业内情况 (不算排队时间,实际全流程更长) • 某电商类 APP:20~40 Min • 某支付 APP:8-10 Min • 某工具 APP:30~40 Min • 某信息流 APP:40-60 Min 55% 40% 30% 某电商类APP 某支付APP 某信息流APP 39% 某电商类APP 火山
43. CI-CD平台 高速稳定建设 平台收益总结 效率以及稳定性的提升,使得业务同事技术深度投入度更高
44. 应用管理平台 ——闭环的开发体验
45. 应用管理平台 最初的开发模式 功能单一的业务线 大锅饭式集体开发 小规模的研发团队 10+ RD 1 业务线
46. 应用管理平台 进阶的开发模式 协同方式 发布的灵活性 • 迭代依赖 • 分支管理 • 代码检查割裂 • BM压力极大 • 版本发布不透明 • 需求与开发不关联 开发效率 调试自测效率 异地跨团队开发,沟通成本大于开发成本 测试资源严重不足! 其他模块引起的不稳定性因素 • 异地跨团队开发 • 几百个组件并行开发 • 代码风格混乱不统一 • 模块依赖下的不稳定因素 • 业务多,回归成本大 合并依赖关系过于复杂! 严重的人工约定式发版本
47. 应用管理平台 过去的组件管理平台 Bug 开发流程割裂 PodA review 平台升级 测试 merge流程繁琐 review Rocket 创建需求 Main + PodB merge review 不适用于组件化开发 review PodC review 平台升级 测试 Config Jenkins 测试 手动更新文档 冲突 发布
48. 应用管理平台 现在的组件管理平台 APP 开发托管 组件分发渠道 开发流程集中 自动化程度高 feature 冲突检测 PodA 智能提示 准⼊入系统 需求创建 需求 映射 PodB PodC 需求与开发强关联 出包 Main Project 可靠交付 需求 测试 + 批量量 组件升级 编译保障 正式版产出 Podfile调整 智能 合码 ⽂文档 更更新
49. 应用管理平台 现在的组件管理平台 需求与开发强关联 开发流程集中 自动化程度高
50. 应用管理平台 现在的组件管理平台 多仓组件化开发 智能合码 定制化分发 信息实时同步 独立调试
51. 小结
52. 小结 统⼀的组件分发及监控平台 丰富的开发⽀撑⼯具覆盖主流 基本覆盖公司所有业务线 业务线客户端研发同学 可插拔式的编译优化⽅案 ⼀站式开发体验 平均效率提升5倍 从需求到开发的闭环
55. Q&A