数字化研发工作流平台建设和应用
如果无法正常显示，请先停止浏览器的去广告插件。
1. 数字化研发工作流平台建设和应用
鲍一翔
研发效能平台
2. 分享收益
1、建立数字化工作流平台是为了解决哪些问题？
2、了解平台的发展历程和部分服务架构等
3、平台为哪些业务场景提供了什么样的功能支撑？效果如何？
4、分享平台后续的规划，方便大家更好地理解我们的迭代思路
3. 目录
01 数字 化 平台背 景/ 目 标 02 平台 演进的过程
03 支撑 的 业务场 景 04 后续 的规划
4. 01
数字化流水线平台背景/目标
研发的心声
测试的心声
迭代Owner的心声
我被分了3个需求， 哪些需求分支已经建好 了？ 我负责的这几个需求，日清或准时提测数据可不要
拉胯啊 这个迭代我们需求有多少个， 研测比、冒烟
这个需求的 坑点有没有都测到 ？马上上线了
一个bug都没有，有点慌 开发 能不能准时提测啊 ，再拖下去都测不完
了 今天周二了，这个版本的需求，应该都测完二轮了
需求是上个版本延期下来的，让我 想想当时改 这个需求是在哪个分支上开发的？ 改了哪些代 测试过程中有什么问题吗？ 我好及时去跟
老说我日清不对，能不能告诉我到底 有哪些 又搞这么低级的问题，也不知道研发 有没有做 发布的时候我要 一个个去找每个域的人收
我感觉我有需求要提测，但又 不记得是哪几 咦？怎么 发布平台上的部署分支又变 开发请假了 ，我直接发布行不行啊， 需求分
支是什么
了什么配置啊
bug要修
个，还得找人问
码？哪些配置？
过自测，有没有好好CR
了 ，这个分支上没我要测的代码啊
通过率、提测率这些数据怎么样 ？
吧？ 哪些需求有上线风险？
进
集应用数据 ，挺麻烦的
5. 01
数字化流水线平台背景/目标
得物流水线平台研发效能方案
规划协同阶段 研发验收阶段 发布运营阶段
以需求为核心 以代码为核心 以应用/制品为核心
研发协同平台可以承载所有需求管理、需求
排期、任务拆分、缺陷管理等工作，并且支
持各职能线之间需求的状态流转，也就是项
目工作流。 开发可以根据需求通过代码管理平台产生代码，
CICD流水线验证代码的基础可用性并产生供测试验
证的制品，测试通过各个环境验证后，产生生产可
发布的制品单元，这里的制品单元可以是镜像或者
应用。 研发和验收阶段产生了可以生产发布的应用/制
品，经过应用依赖编排，根据各应用的发布流
水线，发布应用到生产环境，以提供切实的用
户价值。
6. 01
数字化流水线平台背景/目标
得物流水线平台蓝图
7. 01
数字化流水线平台背景/目标
!"#
一站搞定需求、开
发、测试、部署、
发布的所有迭代诉
求
$%&'(
)*+ ,-&'(
./+
管理迭代需求的准
入准出规范和质量
卡点，持续提升开
发&测试效率，提升
迭代过程价值流动
速度 对需求、源代码、用
例、缺陷、配置管理
等的关联，提高测试
环境稳定性，降低需
求/应用上线过程中的
前置准备耗时
0123+
项目全流程中，过程
资产数据的收集、统
计、分析，促成项目
结果指标提升
8. 目录
01 数字 化 平台背 景/ 目 标 02 平台演 进的过 程
03 支撑 的 业务场 景 04 后续 的规划
9. 02
平台演进的过程
!"#$%&'()*+,-./0+,-1234
$%56.78$%&'9
&*:;<=>
10. 02
平台演进的过程--时间节点
11. 02
平台演进的过程--部署方案
!"#$%&
12. 目录
01 数字 化 平台背 景/ 目 标 02 平台演 进的过 程
03 支撑 的 业务场 景 04 后续 的规划
13. 03
支撑的业务场景--规划协同阶段
在“EP蓝图”中的位置
1、 需求“中转场”：在研发和测试之间，通过各类消息触达，管理需求的研发自测、
提测、打回、发布数据准备等工作
2、 测试手段的承载：测试计划、接口自动化、UI自动化、覆盖率等平台的应用都和每
一个转测单据的不同测试轮次相关联。比如在回归测试阶段的自动化应用
3、 迭代数据的“主要供应商”：数据看板产出丰富的报表数据，每日的项目日报在跨
职能间起到信息同步的作用，并最终产出数据到质量大盘做迭代数据的呈现
14. 03
支撑的业务场景--规划协同工作流
!"#$
!
'()*+
%!$
"
,-./*+
15. 03
支撑的业务场景--研发&验收阶段（代码管理+持续集成流水线+测试管理平台）
在“EP蓝图”中的位置
1、 【分支管理】SCM分支管理工具解决了迭代内多需求、多分支的痛点，全域推进
Git分支管理规范
2、 【代码评审】通过CR流程的改进、CR插件工具的落地、火眼金睛活动的运营推动
全域CR技术文化氛围的提升
3、 【测试管理】通过迭代和打磨更好用的工具，进行更全面的质量保障工作，并产出
可信赖的制品
16. 03
支撑的业务场景--代码管理
!"
分支类型 命名规则 创建方式 作用
基线分支 master 自动 线上代码基线分支，只能有生产发布完成后合入
发布分支 release 自动 用于发布生产、预发环境
部分域直接采用release-${VERSION}替代
!"#$%&'()*+,-)./012
34567589:;<=>?@ABCDE'(
#$
%&'(TUVWXYZ)[\X]^
F8GHIJKLMN'(O4PQR&S
"%&'()*+
_2MN`abcdef)ghij'(klm
%&nf5&Sop5&Skq5rstuvwxy
z{|}~•€•@‚ƒD&S5„MQGoptu
&'$
"
01PRD2345678
(''
"
9:01;<=
(''
"
;<>?@
迭代分支 release-${version} 自动 用于持续集成Daily流程
用于部署测试环境、提测
部分域直接用于生产环境部署
环境分支 release-${ENV} 自动 用于各种环境部署
测试分支 test-${version} 自动 对于多个项⺫并行开发的时候，允许区分小版本
名称的差异
特性分支 feature-${version}-${自定
义} 手动 用于需求代码开发、合入到生产发布分支的时候
需要经过CR，需要关联PRD需求
热修复分支 hotfix-${自定义} 手动 临时紧急问题修复分支
17. 03
支撑的业务场景--代码管理
!"#$
01ABCDEFGECHIJKLMNO
提效数倍
%&'$
!$
#$
P@01QRAB
!$
%$
STUVWX
)$
#$
01QRMerge
18. 03
支撑的业务场景--持续集成流水线
()*+
(''
"
YZ[\/DailyCI]^_`=
,-.*+
(&$
&
#*$
"
.abcd .ab\e=
+'$ ('
"
*fgQRhWX
'()
ijkl
/012*+
&'
+''$
"
mno-78
!*'$
&
'Qqrbug
$
'Q*pqrsBtu
19. 03
支撑的业务场景--接口自动化平台
3456
(''
"
_`vwh
('$
"
QRhxyz{
提效 自动化替代人工，时间花在更具探索和挑战的事上
可维护 车同轨，书同文，由平台提供统一的性能保障
开源 优秀的组件可以设置为共享，帮助更多人的提升
可复制 通过平台规范化，将单域最佳实践复制到更多域
)'$
"
|}QRhz{
20. 03
支撑的业务场景--发布运营阶段（发布平台+质量大盘）
在“EP蓝图”中的位置
1、 提供日常发布、版本发布、小得物发布、蓝绿发布、前端发布、社区批量发布等满
足日常发布需求
2、 以质量大盘为基础，为技术部研发质量季度报告、CTO线技术效率季度报告、迭代
评审会、复盘会、OKR制定提供重要的数据依据
3、 通过发布数据和运营数据的打通，反向评估业务域现在所处的研发效能阶段和改进
方向
21. 03
支撑的业务场景--发布工作流线上化
22. 03
支撑的业务场景--发布工作流线上化
!"#$%&"'(% !")*%&"+,-.%/0
!"#$%&'()*+,-./01234
56-789:; <=>-?@AB;CD0E2FGH7IJ
KLMN0K<OP
('
'
"
2021*
(''
"
2021*
"
2022*
,)&
"
2022*
!"#$%&'()* +,-./01%&23
120% 120%
100% 100%
80% 80%
60% 60%
40% 40%
20% 20%
0% 0%
507
508
业务域1
业务域2
业务域3
业务域4
509
业务域5
业务域6
业务域7
508
业务域1
509
业务域2
业务域3
业务域4
业务域5
业务域6
业务域7
23. 03
支撑的业务场景--发布平台
7879:;
!$
&$
%+
.ab~•
)&
,+
€•‚ƒ.ab
('''$
"
\e=900„…†
-.
‡ˆ‰~Š‹
提效4+倍
7877:;
($
#+
+$
%+
.ab~• €•‚ƒ.ab
#& &'''$
"
\e=900„…†
-.
‡ˆ‰~Š‹
24. 03
支撑的业务场景--质量大盘
#$
!"
ABCDE67FG
AB,-FG
@PQRNOM.
STUVJKM.
%&'()*+
QRSTU
HIJKLM.
HINOLM.
,-.*/0*+
56789:;
<=67>,-?@
12345
!"#$%&'()*+,-
./01234
25. 目录
01 数字 化 平台背 景/ 目 标 02 平台演 进的过 程
03 支撑 的 业务场 景 04 后续的 规划
26. 04
后续的规划
更好的
体验
交付多少功能从来都不是我们
OKR，提供多少帮助才是！
更高的
效率 更快的
交付
提升结果指标的不断向好 探索适合得物的更快的价值交
付模式
27. 内容回顾
01
数字化流水线平台背景/目标
解决研发和测试吐槽做多的问题，利用平台化和流程机制把工具使用的体验提升上去
依托系统把业务域的最佳实践推广到更多的域，降低不同人不同习惯带来的协同问题
02
平台演进的过程
平台整体方案的演变，从单ECS、单应用、单语言演进成多集群、多应用、多语言
03
支撑的业务场景
规划协同阶段：以需求为核心，承载平台（RDC+转测&验证平台）
研发验收阶段：以代码为核心，承载平台（代码管理+流水线平台+测试管理平台）
发布运营阶段：以应用为核心，承载平台（发布平台+质量大盘）
04
后续的规划
更好的体验、更高的效率、更快的交付
28. Q&A
得 物技术 公 众号
29. THANKS