《DevOps+:科技赋能下的DevOps跃迁-张贺.pdf》由会员分享,可在线阅读,更多相关《DevOps+:科技赋能下的DevOps跃迁-张贺.pdf(41页珍藏版)》请在三个皮匠报告上搜索。
1、DevOps+:科研赋能下研发效能的跃迁南京大学 张贺2022/12/092软件研发效能实验室国内率先全方位开展DevOps/云原生科研、教学与产业合作的学术机构3ICS!#$%$&(&)*&中 华 人 民 共 和 国 国 家 标 准中 华 人 民 共 和 国 国 家 标 准 GB/T XXXXXXXXX !#$%&()*+,-./(0123456(!#$%&()*!+,$-(.%/)01)%.1)023%4%5+6&%)$()*76%.($1+)#28(6(9151$:($;.1$:+*%5 在提交反馈意见时,请将您知道的相关专利连同支持性文件一并附上。2 2 2 2!?%+,-.&/0/&
2、10 4&bcdefghPrst&成熟度三级 成熟度四级 成熟度五级 成熟度二级 PGL2 PGL3 PGL4 PGL5 PGL1 MA PDP SSP STP ESP MC ROM SM GOV PII PAM PROM PERM OT CAR CM SEC DAR PQA RQE AD IMP BI TE CICD SD SVCM SC STS ES 项目管理 过程改进 支持和保障 产品研发 服务管理 基础设施 DevOps.indd 1DevOps.indd 12022/7/26 9:48:532022/7/26 9:48:53o DevOps/云原生全方位科研o DevOps/云原生教
3、材及课程建设o DevOps/云原生知识体系构建o DevOps/云原生能力成熟度国家标准o DevOps/云原生全流程产业合作研究o DevOps/云原生中国年度调查o DevOps/云原生技术报告o DevOps/云原生中国社区建设o DevOps/云原生国内/国际学术论坛DevOps/云原生南京大学445DevOps+DevOpsDevelopmentOperationsBiz Strategy&PlanImprovements&InnovationDevOps+Big DataBlockchainArtificial Intelligence5G扩展赋能+P P T模 板 下 载:w
4、w w.1p p t.co m/m o b an/行 业 P P T模 板:w w w.1p p t.co m/h an g y e/节 日 P P T模 板:w w w.1p p t.co m/jieri/P P T素 材 下 载:w w w.1p p t.co m/su cai/P P T背 景 图 片:w w w.1p p t.co m/b eijin g/P P T图 表 下 载:w w w.1p p t.co m/tu b iao/优 秀 P P T下 载:w w w.1p p t.co m/xiazai/P P T教 程:w w w.1p p t.co m/p o w erp o
5、in t/W o rd 教 程:w w w.1p p t.co m/w o rd/E xcel教 程:w w w.1p p t.co m/excel/资 料 下 载:w w w.1p p t.co m/ziliao/P P T课 件 下 载:w w w.1p p t.co m/k ejian/范 文 下 载:w w w.1p p t.co m/fan w en/试 卷 下 载:w w w.1p p t.co m/sh iti/教 案 下 载:w w w.1p p t.co m/jiao an/P P T论 坛:w w w.1p p 目录持续集成及其问题PART 1 /案例分析PART 3/持续
6、集成的使能技术PART 2 /7持续集成及其问题PART 18测试通过开发完成01 持续集成及其问题|非持续集成的糟糕开发用户管理模块测试通过开发完成采购管理模块测试通过开发完成库存管理模块测试通过开发完成销售管理模块准备集成大量冲突901 持续集成及其问题|什么是持续集成?持续集成(Continuous Integration,CI)是一种软件开发实践,在实践中,团队成员频繁地(通常每天多次)集成他们的工作,每次集成使用自动化构建及测试,从而尽快发现缺陷、合并代码、减少冲突。版本控制系统(如Git)CI服务器(如Travis CI)轮询代码提交触发反馈结果可配置构建脚本编译测试审查数据集成尽
7、早集成!频繁集成!增量集成!1001 持续集成及其问题|基于持续集成的开发主干代码仓集成通过提交代码等待反馈同步提交代码集成通过等待反馈同步提交代码略集成失败等待反馈反馈修复缺陷提交代码集成通过等待反馈同步1101 持续集成及其问题|持续集成现状2016年2017年2018年2019年2020年2021年Gitlab:开发者调研报告77%的受访者表示持续集成非常重要,仅次于版本控制。71%的受访团队实现了持续集成我们:DevOps中国调研Gitlab:开发者调研报告只有10%的受访者没有使用持续集成Puppet:DevOps全球调研21%(第一)的受访者认为交付周期缩短是得益于持续集成我们:D
8、evOps中国调研准高性能团队的持续集成使用比例是其他团队比例的两倍54%的受访团队实现了持续集成我们:DevOps中国调研1201 持续集成及其问题|持续集成存在的问题第 12 页建议将单次持续集成的执行时间控制在平均10 分钟以内1Martin Fowler1 https:/ Ghaleb T A,da Costa D A,Zou Y.An empirical study of the long duration of continuous integration buildsJ.Empirical Software Engineering,2019,24(4):2102 2139.Git
9、Hub的67442 个项目中的共计104442 次持续集成里,40的集成花费了30分钟以上的时间EMSE 2019 2主干集成分支持续集成分支持续集成分支持续集成主干集成需要一周。即便对于各个微服务,服务器的压力也非常大,各分支排队现象明显,多次出现服务器崩溃。国内某IT企业高时间和资源开销是导致反模式的关键问题1301持续集成及其问题|持续集成面临的问题时间与资源消耗高自动化程度低分支与代码仓结构繁杂某业务子系统包含60多个代码仓某较大仓库代码量超300多万行某代码仓的分支数量达到200多万个需要有经验的人配置复杂依赖项增量构建与全量构建平均耗时分别为30分钟和3小时缺陷定位依靠人工导致阻塞
10、流水线2-5小时反模式某大型IT企业的调研结果关键痛点最佳实践示例违反导致反的是“持续”频繁的向远程仓库进行小而独立的提交遵循基于主干的开发或短期分支控制执行时间在较短范围内(如10分钟)出现问题时能提供快速反馈建议来源:M.Fowler M.DubeyP.M.Duvall1401持续集成及其问题|效能问题的求解路径在一系列约束下 项目目标 组织结构 开发者能力 服务器资源 人员配置 数据可用性 权衡质量和效率层次化求解的系统性解决方案尽早集成!频繁集成!增量集成!1501持续集成及其问题|效能问题的求解路径需要按怎样的顺序做?能不能进一步自动化?能不能进一步提升做的效果?问题问题DevOps
11、全过程视角持续集成实践层次活动层次测试更细粒度的需不需要实际做持续集成?需不需要完整的做持续集成?需要按怎样的顺序做持续集成?能不能进一步自动化持续集成?能不能进一步提升做持续集成的效果?需不需要实际做测试?需不需要完整的做测试?需要按怎样的顺序做测试?能不能进一步自动化测试?能不能进一步提升做测试的效果?需不需要实际做?需不需要完整的做?自顶向下破解问题自底向上验证结果16持续集成的使能技术PART 217持续集成结果预测持续集成优先级排序漏洞检测构建依赖错误检测测试用例优先级排序测试用例选择不稳定测试检测缺陷定位需不需要实际做持续集成?需要按怎样的顺序持续集成?能不能进一步提升检查效果?能
12、不能进一步提升构建的效果?需要按照怎样的顺序做测试?能不能有选择的做测试?能不能进一步提升测试效果?能不能进一步自动化定位缺陷?持续集成静态代码检查构建测试缺陷修复过程效能问题现有可用技术02 持续集成的使能技术|问题与技术的映射实践层次活动层次需不需要实际做测试?缺陷预测18 优化的目标:解决痛点,使“持续”成为可能 优化的阶段:集成前、集成时、集成后 优化的方向:降低集成时间、节省集成资源、提高代码质量等02 持续集成的使能技术|过程视角开发人员代码仓静态代码检查构建测试集成结果修复缺陷继续开发集成前集成时集成后持续集成结果预测持续集成优先级排序缺陷预测构建依赖错误检测测试用例选择测试用例
13、优先级排序不稳定测试检测缺陷定位漏洞检测提交代码通过失败19集成前置支持技术pre-integration2022/12/19192002 持续集成的使能技术|集成前当代码被推入代码仓后,实际执行持续集成前,预测执行结果:l 如果预测为通过,则跳过本次执行l 如果预测为失败,则触发本次执行集成结果预测目的:减少“非必要”的集成效果:减少总执行时间和等待时间跳过被预测为通过的集成思路第一次执行实际为通过第二次执行实际为失败第三次执行实际为失败基于代码提交日志和持续集成日志训练一个机器学习模型方法l 执行CI的时间开销(考虑事后定位问题Commit的代价):节省高达14.5%l 执行CI前的等待时
14、间:节省高达61.4%在GitHub和GitLab中大型开源项目上的实验结果效果数据要求:代码提交日志持续集成日志适用场景:代码提交频率高持续集成的失败率不高服务器资源有限需不需要实际做持续集成?2102 持续集成的使能技术|集成前当代码被推入代码仓后,实际执行持续集成前:l 通过预设规则重新组织各个代码提交触发集成的执行顺序集成优先级排序目的:优先执行“重要的”集成效果:提升问题代码的反馈效率重新组织代码提交的集成顺序思路基于优先级规则训练一个排序模型方法build 1build 2build 3build 3build 1Build 2排序前CI队列排序后CI队列优先级规则数据要求:代码提
15、交日志持续集成日志适用场景:代码提交频率高服务器资源有限在Google项目和开源项目上的实验结果效果l 相同开销下,使用算法比按原始序列的问题commits的检测效率提高20%25%l 算法的平均执行时间在0.0005s0.01s需要按怎样的顺序持续集成?2202 持续集成的使能技术|集成前目的:减少代码元素中的缺陷效果:提前反馈,降低集成失败率预测代码元素是否包含缺陷思路基于代码特征训练一个缺陷预测模型方法当代码被推入代码仓后,实际执行持续集成前,预测代码元素是否包含缺陷。用于预测的代码特征包括:缺陷预测l 代码度量特征,例如 McCabe 特征 和 CK 特征。l 过程度量特征,例如变更历
16、史记录。代码度量特征代码机器学习算法模型训练缺陷预测过程度量特征测试数据要求:软件代码历史代码和缺陷的映射测试报告适用场景:代码提交频率高服务器资源有限在7个开源的Java项目上的实验结果效果DBN和CNN的F1-Score优于传统方法,分别为0.329、0.335和0.505。需不需要实际做测试?23集成执行支持技术integrating 2022/12/19232402 持续集成的使能技术|集成时目的:减少软件中的漏洞效果:检出代码漏洞漏洞检测克隆检测:相似的代码漏洞相似思路1用匹配算法检测代码的相似性方法执行静态代码检查时,使用已知的问题代码去检测潜在的漏洞。预处理转换预处理转换问题代码
17、目标代码中间表示形式中间表示形式克隆匹配机器学习:提取特征进行分类思路2执行静态代码检查时,从已知的漏洞中提取特征建立分类模型,检测潜在漏洞。0基于漏洞特征训练机器学习模型方法特征提取问题代码训练模型测试漏洞检测多种克隆检测工具效果比较效果机器学习效果相关文献总结效果工具工具准确率准确率召回率召回率代码规模代码规模执行时间执行时间SourcererCC0.830.9100MLOC 1d 12m 54sCCAlinger0.830.9210MLOC24m56sVUDDY1.00.821BLOC14h7m文献文献检测效果检测效果漏洞类型漏洞类型Li et al.准确率 0.96缓冲区溢出Tian
18、et al.F1 score 0.899缓冲区溢出,数值处理Duan et al.F1 score 0.806缓冲区溢出,资源管理错误Ren et al.准确率 0.82缓冲区溢出数据要求:软件代码历史代码和漏洞的映射适用场景:对代码质量要求高服务器资源充裕能不能进一步提升检查效果?25执行持续集成时,根据构建执行过程分析构建脚本:l 缺失依赖:构建脚本中的构建目标未声明实际构建中使用的依赖项l 冗余依赖:构建脚本中的构建目标声明了实际构建中未使用的依赖项对比构建声明与构建执行方法对构建脚本和构建执行进行对比分析思路构建脚本构建声明构建执行构建系统依赖错误02 持续集成的使能技术|集成时第 2
19、5 页l 在30个项目中总共检测出,4097条缺失依赖和42551条冗余依赖l 误报率仅5%基于20个开源GNU Make和10个CMake项目验证结果效果目的:检测依赖错误,正确执行增量构建和并行构建效果:提升构建效率数据要求:软件代码构建脚本适用场景:对增量构建质量要求高对并行构建效果要求高构建依赖错误检测能不能进一步提升构建的效果?26目的:优先执行“重要的”测试用例效果:提高缺陷反馈效率执行持续集成时,根据预设规则对用例进行重新排序来执行测试用例。规则包括:基于成本(即用例对时间、资源的消耗)、基于覆盖(用例对源代码的覆盖程度)和基于历史(用例的历史执行情况)。测试用例优先级排序确立优
20、先级规则进行排序方法对测试用例进行重新排序思路测试用例1测试用例2测试用例3优先级排序算法测试用例3测试用例1测试用例2数据要求:测试用例集软件代码用例与代码之间的映射适用场景:单次测试耗时长测试用例存在冗余在国内某大型企业中的多个微服务上的验证结果效果l 排序后,平均执行完58%66%的用例即可发现所有缺陷l 排序的结果应用于集成时,但排序在集成前完成且阶段性更新,不同算法的时间复杂度差异较大02 持续集成的使能技术|集成时需要按照怎样的顺序做测试?2702 持续集成的使能技术|集成时测试用例选择目的:只执行“必要的”测试用例效果:减少时间和资源消耗选择少量的测试用例,对代码变更进行尽可能全
21、面的测试思想基于依赖或基于成本的测试用例选择方法l 平均减少测试用例比率8.83%l 平均减少离线测试时间8.46s基于GitHub上32个Java项目的验证结果效果基于依赖的测试用例选择基于依赖的测试用例选择基于成本的测试用例选择基于成本的测试用例选择l 静态依赖关系l 动态依赖关系l 主要指用例对于时间以及资源的消耗123456ABA依赖于依赖于B变更文件变更文件未变更文件未变更文件受影响代码单元受影响代码单元未受影响代码单元未受影响代码单元需执行测试用例需执行测试用例无需执行测试用例无需执行测试用例基于依赖的测试用例选择示意图基于依赖的测试用例选择示意图数据要求:测试用例集软件代码适用场
22、景:单次测试耗时长测试用例存在冗余能不能有选择的做测试?28不稳定测试检测相同的代码、输入和配置,重复测试但结果不同含义例如:分析执行失败但没有覆盖任何变更代码的测试用例方法基于测试日志脚本代码、测试坏味道、代码修改记录等信息:l检出不稳定测试l识别不稳定测试的根因l 在其中10个项目中发现了87次以前未知的不稳定测试l 从4846次失败中检测到1874次不稳定测试,误报率误报率1.5%基于TravisCI上96个Java项目的验证结果效果02 持续集成的使能技术|集成时数据要求:测试日志测试坏味道代码修改记录造成不稳定测试的根因类别:异步等待(最主要的问题)并发测试顺序依赖IO(环境问题)目
23、的:检测出“不稳定”的测试用例效果:减少重复测试和问题定位的开销能不能进一步提升测试效果?29集成后置支持技术post-integration2022/12/19293002 持续集成的使能技术|集成后缺陷定位实际执行持续集成后:l 根据用例集对语句的覆盖信息,计算每个语句的可疑值,即映射关系计算代码元素的可疑值,高可疑值意为含缺陷的元素思路基于不同假设的数学公式或机器学习来表示映射关系方法 基于不同假设的数学公式来表示映射关系基于频谱的故障定位(SBFL)基于突变的故障定位(MBFL)基于机器学习来表示映射关系基于机器学习的LRFL基于深度学习的DPFL未通过的用例A覆盖210行一种朴素的想
24、法未通过的用例B覆盖1014行缺陷在第10行l 一个共395个版本的软件,其中213个版本上,开发人员只需要检查第1个代码元素就能定位到缺陷l 平均检查8.27个代码元素,就能发现所有的缺陷针对Defects4J 上357个真实bug的应用结果效果数据要求:用例的覆盖信息用例的执行结果历史缺陷信息缺陷和代码的映射适用场景:具备详尽的缺陷报告目的:识别“最可能的”缺陷位置效果:减少缺陷修复的开销能不能进一步自动化定位缺陷?31过程视角的技术配置与优化a process perspective2022/12/193132目的:真实开发过程的“孪生”效果:整体观测和管控计划和配置02 持续集成的使能
25、技术|全流程通过过程仿真分析、管理和优化真实过程思路基于系统动力学、离散事件仿真等技术动态模拟真实过程方法基于仿真范式建模真实开发过程动态仿真模型仿真结果输出基于结果调整实施持续集成过程仿真数据要求:持续集成日志代码提交日志各使能技术相关数据适用场景:具备丰富的过程数据如何验证方案?3302 持续集成的使能技术|全流程整合现有各阶段的使能技术,定制出一条智能流水线思路一个支持智能持续集成流水线的DevOps平台开发目的:集成各支持技术的“智能”平台效果:集成多种智能学习技术可定制的流水线以模型为驱动的数据管理ArtDev平台如何实现方案?34案例分析PART 33503 案例分析|技术选型标准
26、类别选择标准集成结果预测集成优先级排序缺陷预测静态代码检查增量构建测试用例集优化不稳定测试预测缺陷定位Must该优化技术的改进效果有明确的验收指标可以衡量该优化技术能够解决系统长期稳定存在的瓶颈,即不会因为后续工具链升级而被解决的瓶颈该优化技术的实施难易程度在合理范围内,包括实施复杂度,学习成本等该优化技术所需要的数据能够获取,若目前没有,则要求能够在后续开发中收集该优化技术具有创新性,企业尚未使用或能够证明带来大幅性能提升各级流水线负责人认为该技术具有应用价值,能够接受并愿意考虑该技术的应用?该优化技术有成熟的案例或足够多数量的相关研究?Want能够缓解一级流水线的排队等待情况-能够实现复杂
27、系统的增量构建能力-能够减少日集成时间和资源消耗,从而提升日集成的频率-能够提高缺陷定位的效率,减少开发人员定位缺陷的时间-能够简化复杂系统在复杂场景下配置操作,将集成人员从繁杂配置中解放出来-优化技术3603 案例分析|技术解决方案一级流水线增加持续集成结果预测二级流水线增加测试用例优先级排序增加缺陷定位3703 案例分析|方案验证一级流水线:服务器资源消耗相对节省36.7%人力资源消耗相对节省78.5%二级流水线:服务器资源消耗相对节省28.6%人力资源消耗相对节省42.0%开销的节省将对集成频率的提高形成正反馈38总结导致不“持续”的痛点改进的需求数据的可用性约束部门及其他环境约束选择标
28、准系统性方案及其过程仿真简单叠加:1+13关键问题:多种技术的组合与适配每种技术都存在局限性仅采用单一技术难以真正实现“持续”收益不是简单的叠加研发过程中技术间会相互影响,形成复杂的反馈反模式技术特点作用和效果适用场景数据要求效能问题求解39Next o Business:vision,mission,domain,customero Architecture(Artefact):breakdown,principles,constraintso Organisation(People):intra-team vs.inter-team,communicationo Process(Practice):steps,order,streamlineo Technology(Tool):automation,standardisation40以持续集成为例,说明研发效能瓶颈的求解路径,及科研如何对研发效能产生使能影响以过程与技术的互动为例,说明研发效能多维度间相互的制约与促进关系Take AwayThanks!张贺南京大学软件研发效能实验室