仍然是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
网友评论