仍然是DEVOPS场，因为第一场是行内的演讲。

1. DEVOPS全程质量保障体系（工行 杨卓俊）

（1）背景介绍

国家监管相关对质量守护的要求比较高，效能提升方面又有需求。

（2）质量保障体系建设

ATDD探索验收测试驱动开发：加强需求阶段投入，明确验收标准。

自动化先行支撑测试前移：基于NIT自动化测试平台开展测试前移。接口组合测试，安全测试，性能测试，基于文档编写脚本。

UTDD助力单元测试：将质量控制前移到软件内部，提升代码的有效性和可测试性。通过对被测程序注入编译，反向验证单元测试案例是否有效。

自动化建设：自动化测试脚本13万个。如何对这些脚本进行管理？通过平台封装进行脚本案例的自动化生产。

2. 千人团队产品大作战——深度解码产品制变革（OPPO 崔艳婷 瞿俊龙）

（1）变革背景

互联网产品线、公司内部产品（IT流程）、手机安卓开发（聚焦）

手机操作系统：超大规模复杂软件系统，亿级代码，快速迭代，统一交付

操作系统一次打包3-4个小时，每年安卓升级需要替换4000万行代码

17年开始出现一些突破类的需求（屏下指纹），全栈的需求，海外的需求等等，就开始遇到挑战：交付周期长、产品质量差、研发效率低、人力成本剧增。

• 一开始是项目制管理，项目经理的比例逐渐大于工程师的比例。
• 项目增多以后质量无法保障。
• 项目的需求在A项目出现后，B项目也会出现。19年以后，绝大部分人在解决bug，移植需求，移植周期大于新需求的周期

（2）解决方案

• Color OS版本火车
• 大方向年度规划，提前部署，动态调整

• 整机选择上车版本，选择规划特性

  
  
  产品制方向
  
  
  产品制总览
  
  

  围绕用户价值，关注核心需求，框定产品范围。软件的抽象能力和克制欲望。
  规划主线版本，通过主线版本对齐节奏。

建立双轨运作模式。

• 快轨运作：APP版本，遵循敏捷迭代独立演进，快速迭代上线（相册、短信、负一屏等等）
  • 通用应用组件
  • 定制组件
• 慢轨运作：Color OS版本，规模化团队，季度版本。慢轨OS版本遵循IPD，结合SAFE运作
  • 通用系统组件、系统SKU组件
  • 通用芯片组件、平台SKU组件

DEVOPS研发平台，通过门户封装敏捷协同、代码流水线、持续测试、持续发布、研发看板等模块

基础设施里包含IAAS，PAAS，DAAS。

（3）历程与实践

快轨：

2019年6月开始，进行团队试点，2个团队

2020.1月-4月，8个团队小规模扩大

2020.5月开始，整个应用中心推广

分支管理方面，看起来应该是gerrit+gitflow的模式：代码提交时需要评审，无develop分支，用master管理开发，拉出release来发布。

分支模式

• 技术与工具实践
• 转型组织运作
  • 变革项目工作组运作
  • 特性团队虚线运作
• 共性问题探索
  • 应用于OS解耦
  • 测试自动化

应用中心推广：

• 统一标准与模板：迭代节奏、状态末班、度量
• 人员培养：种子培养，系列课程培训，社区氛围营造
• 评估与度量体系：敏捷成熟度评估、用户体验成熟度评估、研发看板可视化

困顿&转折

• 局限在快轨应用层，效果有限
• 慢轨OS牵一发动全身，未有合适的时机
• 整机按照自己的节点交付，应用按照迭代交付，快轨节奏被打乱

===>

• 与业务专家思路契合
• 与组件化项目契合
• 产品制变革深入到慢轨

第二阶段：OS慢轨产品制运作

• 业务部落成立
  • 按照独立可交付的业务价值划分为部落
  • 部落是一个虚拟的全功能团队
  • 资源部门做能力建设（研发、测试）
  • 聚焦长期的技术预研
  • 部落：对看护本部落的业务长期竞争力负责，确保业务竞争力落地。
• 分级需求决策：部落级、系统级、公司级
  • 聚焦价值：有限的资源做最有价值的事
  • 全局最有：屏显默认
  • 保障需求的演进和可维护性
    • 根据问题确认解决方案，方案确保能提升某个部落的竞争力
  • 防止需求无序变更
• 规模化迭代运作
  • IPD模式下OS版本节奏规划：18月版本规划，再与整机规划对齐
  • EPIC、FEATURE、STORY的划分

• DevOps全景应用

  
  
  DEVOPS全景应用

（4）改变与思考

2年的实践

• 大规模变革是一把手工程
• 一个小问题，几何级放大后会变成大问题
• 软件领域没有银弹，需要探索适合自己的道路
• 软硬件结合，智能化是未来的趋势

3. 旷视AI产品背后的研发效能体系建设（旷视 刘天伟）

（1）背景

旷视传统的CI，以Jenkins、Gitlab-CI、放弃CI三大工具为主，彻底散养，各自为政

• 技术工具演进不一
• CI机器资源浪费或不足
• 不易复用自研的CI组件
• “粘合剂”效果差：内部各种系统难以和持续集成工具对接

整体思路：提升幸福感。

（2）从研发到交付的全流程PAAS平台实践

设计思路：DEVOPS、PAAS

使用公有云IAAS+k8s，再加上CI，对接GITLAB，就能满足公司的PAAS平台需求?

• 云资源与DEVOPS平台割裂的体验：devops流程中充斥着大量外部平台（xx云管）
• 研发/运维/基础设施关注点耦合：k8s的yaml中没有app概念，其定位也不是终端用户

==>在k8s基础上定义application概念，提供基于gitlab的ci和应用周边基础设施，形成内部完善的paas平台，让业务程序向云原生架构演进，提升devops水平和整体研发效能。

设计思路上：不愧是搞算法的，思维结构化且清晰。

image.png

image.png

对yaml的封装：

• 开发者视角：不照搬k8s的yaml结构，从开发者角度触发，对开发者友好
• 配置分离：将某些运营类的配置放到MCD web中

• 映射原则：每个app.yaml对应MCD中的一个产品线中的一个app，产品线可以自由赋值。离线部署时绑定一个app.yaml

  
  
  image.png
  
  

  需要关注：天然私有化

系统架构：

image.png

（3）未来愿景

image.png