数字化研发工作流平台建设和应用

如果无法正常显示,请先停止浏览器的去广告插件。
分享至:
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

首页 - Wiki
Copyright © 2011-2024 iteam. Current version is 2.123.1. UTC+08:00, 2024-03-29 08:10
浙ICP备14020137号-1 $访客地图$