CN112732565B - 一种软件持续集成的评估方法、计算机设备及介质 - Google Patents

一种软件持续集成的评估方法、计算机设备及介质 Download PDF

Info

Publication number
CN112732565B
CN112732565B CN202011635238.3A CN202011635238A CN112732565B CN 112732565 B CN112732565 B CN 112732565B CN 202011635238 A CN202011635238 A CN 202011635238A CN 112732565 B CN112732565 B CN 112732565B
Authority
CN
China
Prior art keywords
code
result
submission
integrated
simulation
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202011635238.3A
Other languages
English (en)
Other versions
CN112732565A (zh
Inventor
刘博涵
宋凯文
荣国平
张贺
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Transwarp Technology Shanghai Co Ltd
Original Assignee
Transwarp Technology Shanghai Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Transwarp Technology Shanghai Co Ltd filed Critical Transwarp Technology Shanghai Co Ltd
Priority to CN202011635238.3A priority Critical patent/CN112732565B/zh
Publication of CN112732565A publication Critical patent/CN112732565A/zh
Application granted granted Critical
Publication of CN112732565B publication Critical patent/CN112732565B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/362—Software debugging
    • G06F11/3624—Software debugging by performing operations on the source code, e.g. via a compiler
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/362—Software debugging
    • G06F11/366—Software debugging using diagnostics
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/20—Design optimisation, verification or simulation

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Evolutionary Computation (AREA)
  • Geometry (AREA)
  • Stored Programmes (AREA)

Abstract

本发明实施例公开一种软件持续集成的评估方法、计算机设备及介质。该方法包括检测到代码提交仿真事件时仿真代码提交操作，根据仿真信息判断本次代码提交是否能够跳过持续集成操作；对于不能跳过的第一代码提交，根据各预测模型的性能进行集成结果的预测，得到预测结果；对被预测为失败的第一代码提交和被判定为能够跳过的第二代码提交进行集成仿真，得到集成结果和集成时间，并对集成结果是失败的代码提交进行缺陷修复仿真，得到修复时间；根据集成时间和修复时间对持续集成过程进行评估得到评估结果。上述评估结果为持续集成的预测方案选用提供决策支持，可以提升软件持续集成效率。

Description

一种软件持续集成的评估方法、计算机设备及介质
技术领域
本发明实施例涉及软件开发技术，尤其涉及一种软件持续集成的评估方法、计算机设备及介质。
背景技术
在现代软件开发过程中，持续集成(Continuous integration，简称CI))是普遍且常用的软件开发工作模式。通过持续集成，开发者可以在对代码每做出一次小的修改后都能够进行一次集成，这种方式能够极大的减少一次性合并提交大量修改而导致的冲突，并且能够及早地发现代码中的缺陷并及时修复它。
但是在实际应用中，开发者往往需要等待集成结束后才能进行后续的开发工作。随着软件开发效率的提升，频繁的持续集成所导致的大量时间开销已经成为了当前软件开发过程中的效率瓶颈。相关技术中的一种提高持续集成效率的方式可以是采用机器学习技术，根据持续集成的历史信息和当前提交的代码的信息，对当前提交代码的持续集成结果进行预测，根据预测结果确定是否执行集成脚本。这种方式能够有效的减少集成脚本的执行次数，从而减少因持续集成而产生的时间开销。然而，采用此处方式对于错误的预测可能导致存在问题的代码被延迟集成，即问题被延迟发现，进而被延迟修复。延迟修复往往意味着开发人员需要重新熟悉相关代码，修复需要消耗更多的时间，不利于持续集成效率的提升。
发明内容
本发明实施例提供一种软件持续集成的评估方法、计算机设备及介质，可以提升持续集成效率。
第一方面，本发明实施例提供了一种软件持续集成的评估方法，包括：
检测到代码提交仿真事件时，仿真一次代码提交操作，根据所述代码提交操作的仿真信息判断本次代码提交是否能够跳过持续集成操作；
对于不能跳过的第一代码提交，根据结果预测阶段各预测模型的性能指标对所述第一代码提交的集成结果进行预测，得到预测结果；
若所述第一代码提交的预测结果表示代码提交失败，则对所述第一代码提交和本次代码提交之前被判定为能够跳过的第二代码提交进行集成仿真，得到集成结果和集成时间，并对所述集成结果是失败的代码提交进行缺陷修复仿真，得到修复时间；
根据所述集成时间和修复时间对具有不同预测模型的持续集成过程进行评估得到评估结果。
第二方面，本发明实施例还提供了一种用于执行软件持续集成的评估方法的计算机设备，该设备包括处理器和存储器，所述存储器用于存储指令，当所述指令执行时使得所述处理器执行以下操作：
检测到代码提交仿真事件时，仿真一次代码提交操作，根据所述代码提交操作的仿真信息判断本次代码提交是否能够跳过持续集成操作；
对于不能跳过的第一代码提交，根据结果预测阶段各预测模型的性能指标对所述第一代码提交的集成结果进行预测，得到预测结果；
若所述第一代码提交的预测结果表示代码提交失败，则对所述第一代码提交和本次代码提交之前被判定为能够跳过的第二代码提交进行集成仿真，得到集成结果和集成时间，并对所述集成结果是失败的代码提交进行缺陷修复仿真，得到修复时间；
根据所述集成时间和修复时间对具有不同预测模型的持续集成过程进行评估得到评估结果。
第三方面，本发明实施例还提供了一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行如本发明任意实施例所述的软件持续集成的评估方法。
本发明实施例提供一种软件持续集成的评估方法、计算机设备及介质，通过仿真代码提交操作，并判断本次代码提交操作对应的代码提交是否能够跳过持续集成操作，对于不能跳过的代码提交，根据结果预测阶段各预测模型的性能指标对其集成结果进行预测得到预测结果，若预测结果是失败，则对本次代码提交和本次代码提交之前被判定为能够跳过的代码提交进行集成仿真，得到集成结果和集成时间，并对集成结果是失败的代码提交进行缺陷修复仿真，得到修复时间，然后，基于集成时间和修改时间对具有不同预测模型的持续集成过程进行性能评估得到评估结果，开发者可以根据评估结果选用最优的预测模型应用于实际的持续集成，从而为持续集成的预测方案选用提供决策支持，解决错误的预测可能导致存在问题的代码被延迟修复而不利于持续集成效率提升的问题，可以最优化地提升软件持续集成效率。
附图说明
图1为本发明实施例提供的一种软件持续集成的评估方法的流程图；
图2a为本发明实施例提供的另一种软件持续集成的评估方法的流程图；
图2b为真实持续集成过程中代码提交是否被跳过的判断流程图；
图3a为本发明实施例提供的一种基于离散事件仿真DES的软件持续集成的评估方法的流程图；
图3b为本发明实施例提供的一种判定代码提交是否能够跳过持续集成的仿真流程图；
图3c为本发明实施例提供的一种执行代码提交预测操作的仿真流程图；
图3d为本发明实施例提供的一种执行集成仿真的仿真流程图；
图3e为本发明实施例提供的一种执行提交缺陷修复的仿真流程图；
图4为本发明实施例提供的一种软件持续集成的评估装置的结果框图；
图5为本发明实施例提供的一种用于执行软件持续集成的评估方法的计算机设备的结构示意图。
具体实施方式
下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本发明，而非对本发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本发明相关的部分而非全部结构。
在更加详细地讨论示例性实施例之前应当提到的是，一些示例性实施例被描述成作为流程图描绘的处理或方法。虽然流程图将各项操作(或步骤)描述成顺序的处理，但是其中的许多操作可以被并行地、并发地或者同时实施。此外，各项操作的顺序可以被重新安排。当其操作完成时所述处理可以被终止，但是还可以具有未包括在附图中的附加步骤。所述处理可以对应于方法、函数、规程、子例程、子程序等等。
为了便于理解，对本发明实施例中可能出现的技术术语进行解释。
本发明实施例中使用的术语“CI”是持续集成的英文缩写。持续集成是一种软件开发实践，它能够实现代码编译、测试在服务器上自动化运行。不但能够保证代码质量，也在很大概率上提升了开发的效率。
本发明实施例中使用的术语“正阳性”是指失败结果的召回率(本发明实施例将失败结果作为预测正例)，即在所有结果类型为失败的代码提交中，被正确地预测为失败的比率，也可称为查全率。
本发明实施例中使用的术语“假阴性”是指在所有结果类型为失败的代码提交中，被错误地预测为通过的比率。
本发明实施例中使用的术语“正阴性”是指通过结果的召回率，即在所有结果类型为通过的代码提交中，被正确地预测为通过的比率，也可称为查全率。
本发明实施例中使用的术语“假阳性”是指在所有结果类型为通过的代码提交中，被错误地预测为失败的比率。
本发明实施例中使用术语“混淆矩阵”是机器学习中预测模型的预测结果的情形分析表，用于确定预测模型的性能指标。其中，性能指标包括通过结果的召回率和失败结果的召回率等。
本发明实施例中使用的术语“待集成队列”，指的是被判定为可以跳过的代码提交组成的队列，它们等待与之后的不能被跳过的代码提交合并后一同被集成。
本发明实施例中使用的术语“集成队列”，指的是可以直接触发CI的代码提交组成的队列，提交在队列中等待可用的空闲服务器。
本发明实施例中使用的术语“提交集”，指的是当前可以直接触发CI的代码提交以及待集成队列中所有代码提交的集合。
本发明实施例中使用的术语“及时修复”指的是对当前触发集成的代码提交中的缺陷进行修复。
本发明实施例中使用的术语“延迟修复”，指的是对跳过的有缺陷的代码提交进行的修复，错误的预测可能导致存在问题的代码被延迟集成，即问题被延迟发现，进而被延迟修复。延迟修复往往意味着开发人员需要重新熟悉相关代码，即将比及时修复消耗更多的时间。
在发明人实现本发明的过程中发现，对于持续集成的结果预测阶段所采用的预测模型，仅从机器学习模型的性能角度评价模型，忽视了错误预测所导致的后果，不能直接评价不同模型对持续集成效率的提升效果。而不同机器学习模型在不同软件项目的不同开发阶段表现存在明显差异，仅从模型性能角度而不考虑持续集成及缺陷修复过程的角度来评价所采用的预测模型，难以有效地选择合适的预测模型以实现最优化地提升持续集成效率。
为了解决上述问题，本发明实施例提供一种软件持续集成的评估方法，该方法通过检测到代码提交仿真事件时，随机产生代码提交以仿真一次代码提交操作，根据代码提交操作的仿真信息判断本次代码提交是否能够跳过持续集成操作；对于不能跳过的代码提交，进入结果预测阶段，根据结果预测阶段中各预测模型的性能指标给出预测结果；将预测结果为失败的代码提交，连同本次代码提交之前被判定为能够跳过的代码提交组成提交集，对提交集中的各代码提交进行集成仿真，得到集成结果和集成时间；对集成结果为失败的代码提交进行缺陷修复得到修复时间，修复完成后，将已修复代码提交与无需修复的代码提交合并到主干以完成软件集成的仿真过程；根据集成时间和修复时间对具有不同预测模型的持续集成过程进行评估得到评估结果，以通过评估结果反映各预测模型对软件持续集成效率的影响情况。本发明实施例的技术方案，通过基于离散事件仿真技术，对带有预测模型的软件持续集成过程进行仿真，实现针对具有不同的预测模型的持续集成过程进行性能评估，开发者可以根据评估结果选用最优的预测模型应用在实际的持续集成中，从而为持续集成的预测方案选用提供决策支持，实现效率优化。
相较于仅采用准确率等机器学习模型评估指标对模型进行评价，本发明能够从持续集成及缺陷修复过程的角度，对带有预测模型的持续集成过程能够节省的时间进行仿真，直接比较不同预测模型对持续集成的效率提升效果，评价持续集成过程效率的优化程度。
图1为本发明实施例提供的一种软件持续集成的评估方法的流程图，本发明实施例的技术方案可适用于针对带有预测模型的CI过程进行仿真并进行性能评估的情况，该方法可以由软件持续集成的评估装置来执行，该装置可以由软件和/或硬件来实现，并可以集成在各种用于执行软件持续集成的评估方法的计算机设备中。如图1所示，该方法包括：
步骤110、检测到代码提交仿真事件时，仿真一次代码提交操作，根据所述代码提交操作的仿真信息判断本次代码提交是否能够跳过持续集成操作。
需要说明的是，代码提交仿真事件用于触发执行一次代码提交仿真的操作。触发代码提交仿真事件的条件可以有很多种，本发明实施例并不作具体限定。可以周期性的触发代码提交仿真事件。其中，触发周期可以基于历史代码提交日志中各项目的历史代码提交的分布信息确定。例如，确定与前一次代码提交仿真操作的时间间隔，在时间间隔满足提交间隔时，触发代码提交仿真事件，随机产生一次代码提交。该提交间隔可以根据软件项目的历史代码提交日志所呈现出的分布情况来进行设置。比如某个软件项目的历史代码提交日志中代码提交的提交时间间隔服从泊松分布，那么，在仿真过程中可以设置提交间隔服从泊松分布。
本实施例中，对代码提交操作的仿真包括产生代码提交，并规定该代码提交的提交类型和结果类型，以仿真一次真实的代码提交。仿真信息是所仿真的代码提交的属性信息。例如，仿真信息可以包括代码提交的提交类型和结果类型等信息。
其中，提交类型是指代码提交被远程服务器感知的方式。在真实的持续集成过程中，代码提交的提交类型主要分为推送和拉取请求(Pull Request，以下使用PR简称)两种。本实施例的仿真过程中，代码提交操作的仿真信息包括的提交类型也主要是上述两种类型，且为代码提交规定的提交类型的概率符合同一项目的真实的持续集成过程中历史推送提交比例以及PR提交比例。
需要说明的是，本发明实施例的仿真过程不考虑在本地的代码提交，因为远程服务器是无法感知到本地代码提交的。
结果类型是为每个代码提交规定的，执行集成后所返回的结果，它决定了一次代码提交是否为缺陷提交。在真实的持续集成过程中，代码提交的结果类型主要包括通过或失败。本实施例的仿真过程中，代码提交操作的仿真信息包括的结果类型也主要包括上述两种类型，且为代码提交规定的结果类型的概率符合同一项目的真实的持续集成过程中历史失败比例和历史成功比例。在仿真过程中设置结果类型的主要原因在于：一方面在真实的持续集成过程中，当一次代码提交到达远程服务器时，该代码提交的CI结果是已经确定的了。比如，一个带有缺陷的代码提交执行CI操作，其集成结果必定是失败。另一方面，由于在仿真过程中，对于不同结果类型的代码提交预先配置有不同的分支工作流，所以事先设定好代码提交的结果类型有利于将代码提交输入正确的分支工作流。
结果预测阶段是带有预测模型的CI过程中，通过预测模型对代码提交的集成结果进行预测的阶段。示例性地，在预测模型的选用方面，可以选用采用基于以下算法构建的预测模型：SVMSMOTE+Random Forest(SVMSMOTE+RF)，SMOTEENN+GaussianBayes(SMOTEENN+GNB)，Random Under Sample+CART(RUS+CART)，One Sided Selection+RandomForest(OSS+RF)，以及RUSBoost。其中的符号“+”表示采样方法和预测算法的组合，“+”左边为数据采样方法，“+”右边为预测算法。
一次代码提交能否跳过持续集成操作是指根据一个综合概率来决定代码提交是否应该被跳过。其中，综合概率基于当前代码提交所属项目的历史代码提交日志中对应类型代码提交被判定为跳过的比例确定。以PR类型的代码提交为例，可以根据当前代码提交所属项目的历史代码提交日志中被判定为跳过的PR类型提交的比例，设定当前代码提交能够跳过持续集成操作的比率。
示例性地，当与前一次代码提交的产生时间间隔满足提交间隔时，触发代码提交仿真事件，产生一次代码提交。根据历史代码提交日志中各项目的推送和拉取请求的提交比例，设定当前代码提交的提交类型。根据历史代码提交日志中各项目的集成失败和通过的结果比例，设定当前代码提交的结果类型。根据综合概率和所述代码提交操作的仿真信息中的提交类型，判断本次代码提交是否能够跳过持续集成操作。如果本次代码提交能够跳过持续集成操作，则将本次代码提交判定为第二代码提交。在下一次检测到代码提交仿真事件时，产生新的代码提交。如果新产生的代码提交不能跳过持续集成操作，则将新产生的代码提交判定为第一代码提交，对于第一代码提交，需要进入结果预测阶段。如果新产生的代码提交能够跳过持续集成操作，则将新产生的代码提交判定为第二代码提交。由此可知，第二代码提交的含义可以是能够跳过持续集成操作的一类代码提交。
可选地，对于被判定为跳过的第二代码提交，进入待集成队列，以等待与接下来的不能跳过的第一代码提交一起进入CI过程。对于被判定为不能跳过的第一代码提交，则进入CI的结果预测阶段。
步骤120、对于不能跳过的第一代码提交，根据结果预测阶段各预测模型的性能指标对所述第一代码提交的集成结果进行预测，得到预测结果。
需要说明的是，在仿真过程中，针对不同结果类型的代码提交仿真了不同的分支工作流，在不同的分支工作流中配置有不同的预测模型的性能指标，以对代码提交的集成结果进行预测。本发明实施例中，性能指标包括通过结果的召回率和失败结果的召回率等。
对带有预测模型的CI的结果预测阶段的仿真基于所使用的预测模型的性能实现，该性能可以通过预测模型的混淆矩阵表示。该混淆矩阵是根据预测模型的预训练得到的代表模型性能的训练结果。
在仿真过程中通过预测模型的性能所呈现的不同概率，可能将代码提交预测为失败或通过，预测结果是预测模型预测出的结果与对应代码提交的结果类型结合的结果。例如，预测模型预测出的结果包括失败或通过，代码提交的结果类型包括通过或失败，则将两者任意组合产生四种预测结果，包括正阳性、假阴性、正阴性和假阳性。其中，预测结果是正阳性或假阴性表示代码提交被预测为失败。预测结果是正阴性或假阳性表示代码提交被预测为通过。具体地，正阳性表示将结果类型是失败的第一代码提交的集成结果预测为失败。假阴性表示将结果类型是失败的第一代码提交的集成结果预测为通过。正阴性表示将结果类型是通过的第一代码提交的集成结果预测为通过。以及，假阳性表示将结果类型是通过的第一代码提交的集成结果预测为失败。
示例性地，对于不能跳过的第一代码提交，根据仿真信息中的结果类型确定第一代码提交对应的结果预测阶段的分支工作流。根据分支工作流中的各预测模型的性能指标对第一代码提交的集成结果进行预测，得到预测结果。具体地，对于判定为不能跳过的第一代码提交，仿真其CI结果预测阶段。由于在仿真过程中，针对不同结果类型的代码提交仿真了不同的分支工作流，在不同的分支工作流中规定了不同的执行流程，需要根据结果类型对第一代码提交进行区分，以将第一代码提交输入到正确的分支工作流。在将第一代码提交输入对应的分支工作流之后，根据各预测模型的混淆矩阵执行对应分支工作流，以对第一代码提交的集成结果进行预测得到预测结果。需要说明的是，代码提交被预测为通过或失败的概率符合基于混淆矩阵计算的通过结果的召回率或失败结果的召回率。
可选地，还可以预先设定预测比例参数，该预测比例参数用于指示在不能跳过的代码提交中进入结果预测阶段的代码提交的比例。对于不进入结果预测阶段的代码提交则可以直接触发CI。这样设置的好处在于，在使用预测功能的早期阶段，需要确保一定数量的代码提交能够直接触发CI，这样有助于提高预测功能的使用率。除此之外，对预测比例参数的调节能够进一步地控制仿真效果和质量之间的平衡。
相应地，在执行结果预测阶段的仿真功能之前，还可以基于上述预测比例参数确定需要进入结果预测阶段的第一代码提交。根据仿真信息中的结果类型确定进入结果预测阶段的第一代码提交对应的结果预测阶段的分支工作流，以执行集成结果预测操作。
需要说明的是，将被预测为失败的代码提交合并到集成队列，以直接触发CI。其它被预测为通过的代码提交与之前被判定为跳过的提交合并，进入待集成队列。
步骤130、若所述第一代码提交的预测结果表示代码提交失败，则对所述第一代码提交和本次代码提交之前被判定为能够跳过的第二代码提交进行集成仿真，得到集成结果和集成时间，并对所述集成结果是失败的代码提交进行缺陷修复仿真，得到修复时间。
其中，集成仿真是指对代码提交的集成操作进行仿真。对代码提交进行集成仿真可以得到集成结果和集成时间。例如，在对代码提交进行集成仿真的过程中，可以基于各代码提交的结果类型确定各次集成仿真的集成结果，不同结果类型的代码提交所耗费的集成时间也不相同。通过对项目数据的统计发现，结果类型为通过的提交会耗费更长的时间，因为集成脚本会被完全执行到结束；而结果类型为失败的提交则耗费较短的时间，因为集成脚本往往还没有执行完毕就因为缺陷而中断执行了。基于这一规律，在集成仿真过程中，可以基于相同项目的历史代码提交日志中相同类型的代码提交的CI过程所用的时间确定各代码提交的集成时间。
缺陷修复仿真是指对集成结果为失败的代码提交的缺陷进行修复的仿真。对代码提交进行缺陷修复仿真可以得到修复时间。例如，缺陷修复仿真包括及时修复仿真和延迟修复仿真。如果被判定为不能跳过的第一代码提交存在缺陷，则需要对其进行及时修复仿真。因为该第一代码提交是当前触发CI的代码提交，在其被提交后立即执行CI，若其存缺陷，则会在执行CI时被发现，所以其缺陷的定位和修复都是比较及时。如果被判定为跳过的第二代码提交存在缺陷，则需要对其进行延迟修复仿真。因为第二代码提交的缺陷不是在提交的时候被发现的，而是在与之后的代码提交合并后一同被集成时发现的，所以缺陷的定位和修复会被延迟。
需要说明的是，延迟修复相比于及时修复会耗费更多的时间成本，该时间成本可以分别基于不同项目的历史提交日志确定。在仿真过程中，可以根据不同情况基于历史提交日志设置及时修复仿真和延迟修复仿真的修复时间的比值。
需要说明的是，将判定为不能跳过的且被预测为失败的第一代码提交作为触发CI的代码提交。当前要触发CI的代码提交需要等待可用的服务器执行持续集成。如果存在可用的服务器执行代码集成，则认为存在空闲资源，否则认为不存空闲资源。如果不存在空闲资源，则当前要触发CI的代码提交在集成队列中等待可用空闲资源。
示例性地，当存在空闲资源时，判断待集成队列是否为空。如果待集成队列为空，则从集成队列中获取当前要触发CI的代码提交，对其进行集成仿真，得到集成结果和集成时间。如果待集成队列不为空，则获取当前待集成队列中的所有代码提交，从集成队列中获取当前要触发CI的代码提交，将当前要触发CI的代码提交与从待集成队列中获取的所有代码提交合并成提交集，合并之后会再一同进行集成仿真，得到各代码提交的集成时间和集成结果。
需要说明的是，在从当前待集成队列中获取所有代码提交之后，清空当前待集成队列。在集成仿真过程结束后，释放当前触发CI的代码提交或提交集所占用的服务器资源。将集成结果是通过的代码提交，作为不需要修复的代码提交。对于集成结果是失败的代码提交，需要进入缺陷修复阶段。
在CI过程结束后，每一次代码提交都会从提交集中分离出来。集成结果为失败的提交包括被判定为跳过的第二代码提交，或当前触发CI的第一代码提交。若集成结果是失败的代码提交是所述第一代码提交，则对第一代码提交进行及时修复仿真。若集成结果是失败的代码提交是第二代码提交，则对第二代码提交进行延迟修复仿真。
在完成缺陷修复仿真之后，将所有已被修复的和不需要修复的代码提交合并到主干中，结束仿真过程。
步骤140、根据所述集成时间和修复时间对具有不同预测模型的持续集成过程进行评估得到评估结果。
示例性地，根据集成时间和修复时间计算软件持续集成操作的时间成本；根据时间成本确定具有不同预测模型的持续集成过程的性能评估结果，显示性能评估结果。可选地，基于性能评估结果和对应的持续集成过程具有的预测模型形成模型推荐结果，显示模型推荐结果，以为开发人员选用持续集成的预测方案提供决策支持，实现软件持续集成过程效率的优化。
可选地，通过选用若干个流行的开源项目作为实际案例，研究该评估方法对于带有预测模型的持续集成过程的有效性。本实施例中的有效性是指通过对带有预测模型的持续集成过程进行仿真，计算出该过程所能节省的时间成本百分比，这里的时间成本是执行集成脚本和缺陷修复两者的时间总和。
本实施例的技术方案，通过对带有预测模型的软件持续集成过程进行仿真，能够对带有不同预测模型的持续集成过程进行性能评估得到评估结果，开发者可以根据评估结果选用最优的预测模型应用于实际的持续集成，从而为持续集成的预测方案选用提供决策支持，解决错误的预测可能导致存在问题的代码被延迟修复而不利于持续集成效率提升的问题，可以最优化地提升软件持续集成效率。
图2a为本发明实施例提供的另一种软件持续集成的评估方法的流程图。图2a是对图1提供的软件持续集成的评估方法进行细化得到的流程图。如图2a所示，该方法包括：
步骤201、随机产生新提交。
示例性地，在仿真过程中，当与前一次代码提交的产生时间间隔满足提交间隔时，产生一次代码提交，设定新产生的代码提交的提交类型和结果类型后，将代码提交输入工作流。其中，与前一次代码提交的产生时间间隔的含义可以是当前时刻与产生前一次代码提交的时刻之间的时间间隔。
步骤202、判断新提交是否被跳过，若是，则执行步骤203，否则执行步骤204。
需要说明的是，跳过的含义是指代码提交可以跳过持续集成操作。在真实的持续集成过程中，决定一次代码提交是否被跳过的依据是一个综合的概率，这个概率是由不同因素决定的。图2b为真实持续集成过程中代码提交是否被跳过的判断流程图。如图2b所示，该判断流程包括：步骤2021、获取新提交。步骤2022、判断新提交是否被推送或PR触发，若是被推送触发，则执行步骤2023，若是被PR触发，则执行步骤2024，若既不是被推送触发也不是被PR触发，则执行步骤20210。步骤2023、判断由推送触发的新提交的提交信息中是否包含“ci skip”或者“skip ci”的字段，若是，则执行步骤20210，否则执行步骤2025。步骤2024、判断由PR触发的新提交的提交信息中是否包含“ci skip”或者“skip ci”的字段，若是，则执行步骤20210，否则执行步骤2026。步骤2025、判断建立推送分支build pushedbranches开关是否开启，若是，则执行步骤2027，否则执行步骤20210。步骤2026、判断建立拉取请求分支build pushed pull requests开关是否开启，若是，则执行步骤2027，否则执行步骤20210。步骤2027、判断新提交所属的目标分支是否在CI的配置文件“.travis.yml”的白名单上，若是，则执行步骤2028，否则执行步骤20210。步骤2028、判断所述目标分支是否在“.travis.yml”的黑名单上，若是，则执行步骤20210，否则执行步骤2029。步骤2029、触发执行持续集成操作。步骤20210、跳过执行持续集成操作。需要说明的是，CI的配置文件“.travis.yml”文件包括黑名单和白名单。黑名单是指名单包含的分支上的代码提交都不能触发CI。因此，只有位于白名单且不在黑名单中的分支上的代码提交才会触发CI，其余的代码提交都会被跳过。
上述记载说明的是真实的持续集成过程中判断代码提交是否被跳过的情况，对于仿真过程中，判断一次代码提交是否能够跳过持续集成操作，可以根据仿真过程基于的项目的历史代码提交日志来进行设定。示例性地，可以根据特定项目中被判定为跳过的推送类型提交的比率，来设定基于该特定项目的仿真过程中跳过推送类型的代码提交的比率。相应地，可以根据特定项目中被判定为跳过的PR类型提交的比率，来设定基于该特定项目的仿真过程中跳过PR类型的代码提交的比率。然后，基于所设定的比例随机确定当前代码提交是否能够跳过持续集成操作，需要说明的是，在仿真过程中，所设定的代码提交能否被跳过的比率与对应项目的历史代码提交日志中同类型的被判定为跳过的代码提交的比率相接近。
步骤203、进入待集成队列。
示例性地，将能够跳过的第二代码提交缓存进待集成队列。
步骤204、进行集成结果的预测，判定预测结果是否为通过，若是，则执行步骤203，否则执行步骤205。
示例性地，根据结果预测阶段各预测模型的性能指标对第一代码提交的集成结果进行预测，得到预测结果。
步骤205、进入集成队列。
示例性地，对于不能够跳过持续集成操作的第一代码提交，将其缓存进集成队列。
可选地，对于不能够跳过持续集成操作的第一代码提交，如果当前没有空闲资源，则将其缓存进集成队列；如果当前存在空闲资源，则直接由该第一代码提交触发CI操作。
可选地，若第一代码提交的预测结果表示代码提交通过，则将第一代码提交缓存进所述待集成队列，此时将预测结果为代码提交通过的第一代码提交看成可以跳过持续集成操作的代码提交。若第一代码提交的预测结果表示代码提交失败且当前不存在空闲资源，则将第一代码提交缓存进所述集成队列。
步骤206、判断是否有空闲服务器可用，若是，则执行步骤207，否则执行步骤205。
需要说明的是，如果当前有用于持续集成的空闲服务器，则认为当前存在空闲资源。
步骤207、判断待集成队列是否为空，若是，则执行步骤209，否则执行步骤208。
需要说明的是，待集成队列中缓存有被判定为能够跳过的第二代码提交，以及在结果预测阶段被预测为通过的第一代码提交。在存在空闲资源且待集成队列不为空时，从待集成队列获取所有代码提交，并与从集成队列获取的当前第一代码(即可以触发CI操作的代码提交)提交合并成提交集，并清空待集成队列。在相邻下一次代码提交的仿真操作中，如果判定新的代码提交不能跳过持续集成操作，且在结果预测阶段该新的代码提交被预测为失败，则当前待集成队列为空，由还新的代码直接触发CI操作。
步骤208、待集成队列中的所有代码提交与集成队列中的新提交合并。
步骤209、执行持续集成操作的集成仿真。
示例性地，在存在空闲资源时，将待集成队列中的所有第二代码提交与集成队列中的当前第一代码提交合并为提交集，清空待集成队列。可选地，有些情况下，在待集成队列中不光缓存有第二代码提交，还缓存有预测结果为通过的第一代码提交，则在存在空闲资源时，将待集成队列中的所有第二代码提交以及第一代码提交，与集成队列中的当前第一代码提交合并为提交集，并清空待集成队列。通过空闲资源对提交集中的各代码提交进行集成仿真得到集成时间；根据各代码提交的结果类型确定各次集成仿真的集成结果。
步骤210、判断集成结果是否失败，若是，则执行步骤211，否则执行步骤215。
步骤211、判断是否是新提交存在缺陷，若是，则执行步骤212，否则执行步骤213。
步骤212、执行及时修复仿真，转至执行步骤214。
步骤213、执行延迟修复仿真。
步骤214、评估持续集成过程的性能得到评估结果。
示例性地，通过执行集成仿真得到集成时间，通过执行及时修复仿真或延迟修复仿真得到修复时间，根据集成时间和修复时间计算本次持续集成仿真操作的时间成本，以通过时间成本对具有不同预测模型的持续集成过程的性能进行评估，得到评估结果。开发者可以根据对具有不同预测模型的CI操作的评估结果来决定是否使用、或者使用哪种预测模型。通过评估采用不同预测模型的CI操作所耗费的时间成本，开发者可以选用耗时最少的预测模型进行持续集成预测。
步骤215、结束。
本发明实施例提供一种软件持续集成效率的细化地评估方法，通过待集成队列和集成队列分别缓存能够跳过的代码提交和不能够跳过的代码提交，并在有空闲资源时，结合待集成队列中的代码提交和集成队列中的代码提交进行持续集成操作的集成仿真，得到集成结果，对于集成结果是失败的代码提交，判断其是否是新提交，根据判断结果执行不同类型的缺陷修复仿真，得到本次持续集成仿真过程的时间成本，根据时间成本对具有不同预测模型的持续集成过程的性能进行评估，评估结果为持续集成的预测方案选用提供决策支持，实现软件持续集成过程效率的优化。
图3a为本发明实施例提供的一种基于离散事件仿真DES的软件持续集成的评估方法的流程图。本发明实施例是在上述实施例的基础上的进一步细化，使用ExtendSim建模软件工具提供的DES(Discrete-Event Simulation，离散事件仿真)模型，对Travis CI工具支持的CI过程进行仿真。持续集成结果的预测模型是来源于Github上的真实CI数据。TravisCI是目前最普遍被使用和研究的CI工具，其中的Travis Torrent数据集包含了1283个Github项目的集成日志，为大量的研究提供的丰富的数据支撑。
如图3a所示，本方法包括如下步骤：
步骤310、检测到代码提交仿真事件时，产生一次代码提交，为该代码提交规定提交类型和结果类型，并判断该代码提交是否能够跳过持续集成操作。
图3b为本发明实施例中的一种判断代码提交是否能够跳过持续集成操作的仿真流程图，该仿真流程图详细描述了步骤310的执行流程。该类仿真流程图是由仿真软件ExtendSim执行的结果，对应的图例及其含义可参考表1。
表1是一种仿真流程中涉及图例的含义表。
需要说明的是，在本实施例中出现的所有组件编号名称及其含义的对应关系可参考表2。
表2是一种组件编号名称和含义的对应关系表。
/>
如图3a所示，步骤310包括如下步骤：
步骤311、产生代码提交输入。
示例性地，当基于DES的仿真模型开始运行的时候，会以随机的时间间隔产生代码提交并输入到工作流当中。产生代码提交的组件可以被命名为B01，它是一个创建型的组件，主要作用是以随机时间间隔创建代码提交输入工作流。
可选的，基于对使用持续集成工具Travis CI的项目的历史代码提交日志进行分析，发现代码提交的集成并不符合任意一个特定的概率分布，但是其最接近的分布是泊松分布(Poisson distribution)，所以在这个仿真模型中，以泊松分布的概率分布作为时间间隔来创建代码提交输入。
步骤312、对被创建的代码提交进行设置类型操作。
在本实施例中，设置类型的组件可以被命名为B02，它可以为代码提交规定属性值。规定的类型包括提交类型和结果类型两种属性值。对这两种属性值的分配可以基于不同的项目数据计算出的概率来规定。具体地，如果项目的提交类型比例为1:2，在不同提交类型中的结果类型比例也不相同，可以根据这些比例计算出在仿真模型中对代码提交设定某个属性值的概率。
需要说明的是，提交类型的组件可以被命名为B03，它可以表示代码提交被感知的方式，可设定值为推送或PR。结果类型的组件可以被命名为B04，它可以表示集成被执行后产生的结果，可设定值为通过或失败。因为仿真模型针对不同结果类型的代码提交会仿真不同的工作流，对代码提交的结果类型的事先标注有利于促进代码提交进入正确工作流。
步骤313、在为代码提交设定好具体的属性值后，需要判断其是否能够跳过持续集成。
示例性地，在为代码提交设定好具体的提交类型和结果类型之后，组件05根据提交类型进行区分。因为判断是否跳过的条件随着提交类型而不同，所以在执行判断操作之前需要根据提交类型对代码提交进行区分。图3b为本发明实施例提供的一种判定代码提交是否能够跳过持续集成的仿真流程图。如图3b所示，提交输入组件B01产生的代码提交输入设置类型组件B02，并且通过提交类型组件B03产生并输入提交类型信息至设置类型组件B02，通过结果类型组件B04产生并输入结果类型信息至设置类型组件B02。设置类型组件B02分别基于提交类型信息和结果类型信息为代码提交规定属性值。根据代码提交的属性值中的提交类型对代码提交进行区分。被判定为跳过的代码提交(由组件B06和组件B07输出)被合并(由组件B09执行)到一起后进入待集成队列(对应组件B31)，等待与接下来可以触发CI的代码提交一同执行集成。而没有被判定为跳过的提交也将合并(由组件B08)并进入下一步的预测阶段。
可选的，以提交类型为PR的代码提交为例，跳过一次提交类型为PR的提交可以根据Travis Torrent数据集的一个特定项目中，没有触发CI的PR提交占所有PR提交的比例来设定。
步骤320、对于不能跳过的第一代码提交，根据结果预测阶段各预测模型的性能指标对所述第一代码提交的集成结果进行预测，得到预测结果。
示例性地，对于不能跳过的第一代码提交，执行集成结果预测操作。仿真模型通过预测组件根据不同预测模型的性能得出预测结果。具体地，步骤320包括如下步骤：
步骤321、对代码提交的预测。
需要说明的是，对具有预测模型的CI的持续集成结果的预测仿真是基于所使用的预测模型的性能实现的，即基于该预测模型的混淆矩阵。该混淆矩阵是根据预测模型的预训练得出的代表模型性能的训练结果。
步骤322、对于预测为失败的代码提交，会被合并到集成队列，以直接触发CI，其它被预测为通过的代码提交，会与之前判定为跳过的第二代码提交合并后进入待集成队列。
图3c为本发明实施例提供的一种执行代码提交预测操作的仿真流程图。如图3c所示，当一次代码提交进入结果预测阶段时，通过组件B11获取其结果类型，通过组件B12根据结果类型对代码提交进行区分，将结果类型为失败的代码提交和结果类型为通过的代码提交分别输入不同的预测组件，以执行不同的分支工作流。根据对应分支工作流和预测模型的性能所呈现的不同的概率，将代码提交预测为失败(通过组件B13执行)或通过(通过组件B14执行)。根据不同的结果类型产生四种预测结果，包括正阳性(即失败的召回率，Rf)，假阴性(即1-Rf)，正阴性(即通过的召回率，Rp)和假阳性(即1-Rp)。
可选地，在执行预测功能之前，可以通过组件B10设定预测比例参数。这个参数指的是进入结果预测阶段的提交的比例，其余的不进入结果预测阶段的代码提交会与被预测为失败的代码提交合并后直接触发CI。在使用预测功能的早期阶段，需要确保一定数量的代码提交能够直接触发CI，这样能够让开发者有足够的信心去使用预测功能。除此之外，对预测比例的调节也能够进一步地控制模型效率和质量之间的平衡。
如图3c所示，将被预测为失败的提交(由组件B15输出)与不进入结果预测阶段的代码提交合并到集成队列，集成队列中的代码提交可以直接触发CI。被预测为通过的代码提交(由组件B16输出)与之前被判定为跳过的地第二代码提交合并进入待集成队列。
步骤330、若所述第一代码提交的预测结果表示代码提交失败，则对所述第一代码提交和本次代码提交之前被判定为能够跳过的第二代码提交进行集成仿真，得到集成结果和集成时间。
示例性地，将预测为失败的代码提交与待集成队列中的全部代码提交合并为提交集，一同进入集成阶段，进行集成仿真得到集成结果和集成时间。具体地，步骤330包括如下步骤：
步骤331、若当前有空闲资源且待集成队列不为空，则获取待集成队列中的所有代码提交，与当前触发CI的代码提交合并为提交集，对提交集中的各代码提交执行CI流程的集成仿真，在执行完成后释放所占用的服务器资源。
步骤332、若当前有空闲资源且待集成队列为空，则当前触发CI的代码提交执行CI流程的集成仿真，在执行完成后释放所占用的服务器资源。
步骤333、在集成仿真结束后，对提交集中的代码提交进行分离，并且各代码提交的初始结果类型维持不变。
图3d为本发明实施例提供的一种执行集成仿真的仿真流程图。当前要触发CI的提交需要等待可用的服务器资源(对应组件B18)执行集成。如果当前没有可用的空闲服务器，那么该提交需要进入集成队列(对应组件B19)等待空闲资源。如果当前有可用的空闲服务器且代码提交不能跳过CI，则在执行CI的集成仿真之前，通过组件B20检测待集成队列(对应组件B31)是否为空。如果待集成队列为空，则直接由当前代码提交触发执行CI的集成仿真操作。通过组件B21获取结果类型，通过组件B22基于不同结果类型采用不同的延迟时间公式计算集成仿真的持续时间。上述持续时间包括通过延迟时间和失败延迟时间。通过组件B25缓存排队等待执行CI的代码提交。通过组件B26对当前代码提交执行CI集成仿真。在仿真结束后，当前提交所占用的服务器资源会被释放(对应组件B27)。通过组件B28根据集成仿真的接触结果，输入集成结果是失败的代码提交到组件B40，并将集成结果是通过的代码提交标记为无需修复(无需修复-1)。
对于被跳过的代码提交，通过组件B29获取结果类型，并通过组件B30基于结果类型对代码提交进行区分。对于结果类型是通过的代码提交，标记为无需修复(无需修复-2)；对于结果类型是失败的代码提交，进入待集成队列(对应组件B31)。
如果当前有可用的空闲服务器且待集成队列不为空，则将当前待集成队列中全部代码提交与当前需要触发集成的代码提交合并成提交集(对应组件B34)，合并后一同执行CI的集成仿真操作。上述过程中，提交集所包含的代码提交的数量由组件B32和组件B33计算确定，且组件B32和组件B33计算所使用的函数为预先设置的函数。组件B32中的函数的输出值与待集成队列中代码提交的数量相同。需要说明的是，当待集成队列为空时，组件B33中的函数的输出值为1。通过提交集缓存即将触发CI的代码提交，提交集可以由组件B19和组件B31构成。通过组件B35缓存等待执行CI的代码提交。通过组件B36对提交集执行CI集成仿真。在仿真结束后，提交集所占用的服务器资源会被释放(对应组件B37)。按照集成结果的类型将代码提交分离(对应组件B38)。对于集成结果为通过的提交，通过组件B39进行结果类型区分，如果代码提交的结果类型是通过，它的工作流至此就会结束(无需修复-3)。对于集成结果为失败的提交(待修复-2)，则需要进入下一步的缺陷修复阶段。此外，将通过组件B39判定的结果类型为失败的代码提交输入组件B40，以通过组件B40对组件B28和组件B39输入的代码提交进行合并，合并后的代码提交(待修复-1)需要进入下一步的缺陷修复阶段。
具体的，通过对Travis Torrent数据集的分析可以发现，不同结果类型的提交所耗费的集成时间也是不同的。通过对项目数据的观察统计，发现结果类型为通过的代码提交的通过延时时间(对应组件B23)会耗费更长的时间，因为集成脚本会被完全执行；而结果类型为失败的代码提交的失败延时时间(对应组件B24)则耗费较短的时间，因为集成脚本往往还没有执行完毕就因为缺陷而中断执行了。
需要说明的是，结果类型为失败的提交会花费更多的时间进行缺陷修复，所以最近的代码提交和被跳过的代码提交会进入不同的队列等待修复阶段(分别为待修复-1和待修复-2)。
需要说明的是，一个被判定为跳过的无缺陷的提交，即结果类型为通过，并不会影响最后的CI执行结果，也不会对后续的缺陷修复阶段产生影响。所以我们在这里使用了简化的模型设计，即结果类型为通过的被判定为跳过的提交不进入待集成队列(对应组件B31)，这就意味着产生的提交集一定包含存在缺陷的代码提交。
步骤340、对所述集成结果是失败的代码提交进行缺陷修复仿真，得到修复时间。
图3e为本发明实施例提供的一种执行提交缺陷修复的仿真流程图。如图3e所示，对于待修复-1对应的代码提交，通过组件B41基于提交类型对其进行区分，以对推送类型和PR类型的代码提交进行分别修复。通过组件B42对PR类型的代码提交进行修复仿真，实际上就是延时预设时间。通过组件B43对推送类型的代码提交进行修复仿真，实际上就是延时预设时间。修复仿真结束后，通过组件B44合并修复后的代码提交，将合并结果输出至组件B49。
对于待修复-2对应的代码提交，通过组件B45基于提交类型对其进行区分，以对推送类型和PR类型的代码提交进行分别修复。通过组件B46对PR类型的代码提交进行修复仿真，实际上就是延时预设时间。通过组件B47对推送类型的代码提交进行修复仿真，实际上就是延时预设时间。修复仿真结束后，通过组件B48合并修复后的代码提交，将合并结果输出至组件B49。通过组件B49合并图3c中的无需修复-1、无需修复-2、组件44输出的修复后的代码提交和组件B48输出的修复后的代码提交后退出(对应组件B50)。
具体地，根据提交类型来区分(分别对应组件B41，B45)待修复的代码提交，推送类型和PR类型的代码提交会分开修复。如果是被判定为跳过的代码提交(对应待修复-2)存在缺陷，则需要对其进行延迟修复，因为它的缺陷不是在提交的时候被发现的，而是在与之后的代码提交合并后一同被集成时发现的，所以缺陷的定位和修复会被延迟。如果是当前触发CI的代码提交(对应待修复-1)存在缺陷，则需要对其进行及时修复，因为该提交在提交后就立即执行CI并发现缺陷，所以其缺陷的定位和修复都是及时的。由此可知，虽然存在缺陷的代码提交需要经过相同的缺陷修复阶段，但是不同的提交类型和是否跳过却影响着缺陷修复的时间成本。
需要说明的是，延迟修复相较于及时修复会耗费更多的时间成本，这些时间成本由不同项目的现实情况决定。在仿真模型中，可以根据不同的情况设置延迟修复和及时修复的持续时间的比例。
在本实施例中，对于完成缺陷修复完成的代码提交和不需要被修复的代码提交，都被合并到主干(对应组件B49)，完成CI过程的仿真，退出工作流(对应组件B50)。
步骤350、根据所述集成时间和修复时间对具有不同预测模型的持续集成过程进行评估得到评估结果。
示例性地，集成时间可以由集成仿真的持续时间确定。修复时间可以通过及时修复的持续时间和延迟修复的持续时间确定。基于集成时间和修复时间可以计算基于不同预测模型的CI过程仿真所能节省的时间成本。
本发明实施例随机选择了3个流行的开源项目对上述评估方法进行验证，包括：Android，Cloudify,Graylog2-server。这3个项目都使用了持续集成工具Travis CI并且在Travis Torrent数据集中拥有大量丰富的历史提交日志记录。
本发明实施例选择了5个具有代表性的预测模型，分别为：SVMSMOTE+RandomForest(SVMSMOTE+RF)，SMOTEENN+GaussianBayes(SMOTEENN+GNB)，Random UnderSample+CART(RUS+CART)，One Sided Selection+Random Forest(OSS+RF)，以及RUSBoost。因而，本发明实施例中对15种(3个项目，每个项目有5个预测模型)案例进行了仿真，每种案例进行仿真100轮，在仿真过程中，对相对时间成本(Src)进行计算，计算的公式如下所示：
Src＝(O-N)/O
其中，O代表在没有预测模型的情况下持续集成过程所耗费的时间成本，N则代表带有特定预测模型的情况下持续集成过程所耗费的时间成本。具体的仿真结果见表3。
表3是不同项目下具有不同预测模型的CI过程仿真的仿真结果表。
/>
表3中的7列分别包括：项目的名称，对每个项目分别使用的5种预测模型，每种预测模型针对特定项目的正阳性设定值和假阴性设定值，有预测的情况下持续集成过程所耗费的时间，无预测的情况下持续集成过程所耗费的时间，以及最终的节省时间百分比(Src)。
从表3可以看出，5种预测模型对于三个项目持续集成的有效性都有明显的提升。本实施例中有效性是指通过仿真计算出CI过程所能节省的时间百分比(Src)。
总体来看，不带有预测模型的持续集成过程所耗费的时间成本要高于带有预测模型的持续集成过程所耗费的时间成本。不同的预测模型在特定的项目上对时间成本的改善效果也不尽相同。比如对于项目Android和Cloudify，预测模型OneSidedSelection+RandomForest的时间成本提升效果要优于其它模型的提升效果。而对于三个项目来说，预测模型RandomUnderSampler+CART对时间成本的提升效果要差于其它模型。
上述过程从实际案例的角度，验证了本发明实施例提供的评估方法可以通过仿真对带有或不带有预测模型，以及带有不同预测模型的CI过程进行性能评估，为持续集成的预测方案选用提供决策支持，最终实现软件持续集成过程效率的优化。
本发明实施例提供一种软件持续集成的评估方法，通过使用ExtendSim建模软件工具提供的DES模型，对Travis CI工具支持的CI过程进行仿真，能够针对带有或者不带有预测模型，以及带有不同预测模型的持续集成过程进行性能评估。开发者可以根据评估结果来决定是否使用、或者使用哪种预测模型。通过评估具有不同预测模型的持续集成过程所耗费的时间成本，开发者可以选用用时最少的预测模型进行持续集成预测。因而，该DES模型能够为持续集成的预测方案选用提供决策支持，最终实现软件持续集成效率的优化。
值得注意的是，上述软件持续集成的评估装置的实施例中，所包括的各个单元和模块只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本发明的保护范围。
图4为本发明实施例提供的一种软件持续集成的评估装置的结果框图，该装置可以执行上述各实施例中涉及的软件持续集成的评估方法。如图4所示，该装置包括：代码提交仿真模块410、预测模块420、集成仿真模块430和评估模块440。其中，
代码提交仿真模块410，用于检测到代码提交仿真事件时，仿真一次代码提交操作，根据所述代码提交操作的仿真信息判断本次代码提交是否能够跳过持续集成操作；
预测模块420，用于对于不能跳过的第一代码提交，根据结果预测阶段各预测模型的性能指标对所述第一代码提交的集成结果进行预测，得到预测结果；
集成仿真模块430，用于若所述第一代码提交的预测结果表示代码提交失败，则对所述第一代码提交和本次代码提交之前被判定为能够跳过的第二代码提交进行集成仿真，得到集成结果和集成时间，并对所述集成结果是失败的代码提交进行缺陷修复仿真，得到修复时间；
评估模块440，用于根据所述集成时间和修复时间对具有不同预测模型的持续集成过程进行评估得到评估结果。
本发明实施例提供一种软件持续集成的评估装置，通过对带有预测模型的软件持续集成过程进行仿真，能够对带有不同预测模型的持续集成过程进行性能评估得到评估结果，开发者可以根据评估结果选用最优的预测模型应用于实际的持续集成，从而为持续集成的预测方案选用提供决策支持，解决错误的预测可能导致存在问题的代码被延迟修复而不利于持续集成效率提升的问题，可以最优化地提升软件持续集成效率。
可选地，代码提交仿真模块410具体用于：
当与前一次代码提交的产生时间间隔满足提交间隔时，触发代码提交仿真事件，产生一次代码提交，其中，所述提交间隔基于历史代码提交日志中各项目的历史代码提交的分布信息确定；
根据所述历史代码提交日志中各项目的推送和拉取请求的提交比例，设定当前代码提交的提交类型；
根据所述历史代码提交日志中各项目的集成失败和通过的结果比例，设定当前代码提交的结果类型。
可选地，代码提交仿真模块410具体还用于：
根据综合概率和所述代码提交操作的仿真信息中的提交类型，判断本次代码提交是否能够跳过持续集成操作，其中，所述综合概率基于当前代码提交所属项目的历史代码提交日志中对应类型代码提交被判定为跳过的比例确定。
可选地，预测模块420包括：
类型区分子模块，用于对于不能跳过的第一代码提交，根据所述仿真信息中的结果类型确定所述第一代码提交对应的结果预测阶段的分支工作流；
预测子模块，用于根据所述分支工作流和各预测模型的性能指标对所述第一代码提交的集成结果进行预测，得到预测结果。
可选地，预测子模块具体用于：
基于各预测模型的混淆矩阵执行对应分支工作流，以对所述第一代码提交的集成结果进行预测得到预测结果，其中，所述预测结果包括将结果类型是失败的所述第一代码提交的集成结果预测为失败，将结果类型是失败的所述第一代码提交的集成结果预测为通过，将结果类型是通过的所述第一代码提交的集成结果预测为通过，或将结果类型是通过的所述第一代码提交的集成结果预测为失败。
可选地，该装置还包括：
第一缓存模块，用于在根据所述代码提交操作的仿真信息判断本次代码提交是否能够跳过持续集成操作之后，将能够跳过的第二代码提交缓存进待集成队列；
第二缓存模块，用于在根据结果预测阶段各预测模型的性能指标对所述第一代码提交的集成结果进行预测，得到预测结果之后，若所述第一代码提交的预测结果表示代码提交通过，则将所述第一代码提交缓存进所述待集成队列；若所述第一代码提交的预测结果表示代码提交失败且当前不存在空闲资源，则将所述第一代码提交缓存进集成队列。
可选地，集成仿真模块430具体用于：
在存在空闲资源时，将所述待集成队列中的所有代码提交与所述集成队列中的当前第一代码提交合并为提交集，清空所述待集成队列；
通过所述空闲资源对所述提交集中的各代码提交进行集成仿真得到集成时间；
根据各代码提交的结果类型确定各次集成仿真的集成结果。
可选地，集成仿真模块430具体还用于：
若所述集成结果是失败的代码提交是所述第一代码提交，则对所述第一代码提交进行及时修复仿真；
若所述集成结果是失败的代码提交是所述第二代码提交，则对所述第二代码提交进行延迟修复仿真。
可选地，评估模块440具体用于：
根据所述集成时间和修复时间计算软件持续集成操作的时间成本；
根据所述时间成本确定具有不同预测模型的持续集成过程的性能评估结果。
本发明实施例所提供的软件持续集成的评估装置可执行本发明任意实施例所提供的软件持续集成的评估方法，具备执行方法相应的功能模块和有益效果。
图5为本发明实施例提供的一种用于执行软件持续集成的评估方法的计算机设备的结构示意图，如图5所示，该计算机设备包括处理器50、存储器51、输入装置52和输出装置53；计算机设备中处理器50的数量可以是一个或多个，图5中以一个处理器50为例；计算机设备中的处理器50、存储器51、输入装置52和输出装置53可以通过总线或其他方式连接，图5中以通过总线连接为例。
存储器51作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块，如本发明实施例中的软件持续集成的评估方法对应的程序指令/模块(例如，代码提交仿真模块410、预测模块420、集成仿真模块430和评估模块440)。处理器50通过运行存储在存储器51中的软件程序、指令以及模块，从而执行计算机设备的各种功能应用以及数据处理，即实现上述的软件持续集成的评估方法。
存储器51可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据终端的使用所创建的数据等。此外，存储器51可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储器51可进一步包括相对于处理器50远程设置的存储器，这些远程存储器可以通过网络连接至计算机设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
输入装置52可用于接收输入的数字或字符信息，以及产生与计算机设备的用户设置以及功能控制有关的键信号输入。输出装置53可包括显示屏等显示设备。
本发明实施例还提供一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行一种软件持续集成的评估方法，该方法包括：
检测到代码提交仿真事件时，仿真一次代码提交操作，根据所述代码提交操作的仿真信息判断本次代码提交是否能够跳过持续集成操作；
对于不能跳过的第一代码提交，根据结果预测阶段各预测模型的性能指标对所述第一代码提交的集成结果进行预测，得到预测结果；
若所述第一代码提交的预测结果表示代码提交失败，则对所述第一代码提交和本次代码提交之前被判定为能够跳过的第二代码提交进行集成仿真，得到集成结果和集成时间，并对所述集成结果是失败的代码提交进行缺陷修复仿真，得到修复时间；
根据所述集成时间和修复时间对具有不同预测模型的持续集成过程进行评估得到评估结果。
当然,本发明实施例所提供的一种包含计算机可执行指令的存储介质,其计算机可执行指令不限于如上所述的方法操作,还可以执行本发明任意实施例所提供的软件持续集成的评估方法中的相关操作.
通过以上关于实施方式的描述，所属领域的技术人员可以清楚地了解到，本发明可借助软件及必需的通用硬件来实现，当然也可以通过硬件实现，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如计算机的软盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(RandomAccess Memory,RAM)、闪存(FLASH)、硬盘或光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。
注意，上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解，本发明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。

Claims (13)

1.一种软件持续集成的评估方法，其特征在于，包括：
检测到代码提交仿真事件时，仿真一次代码提交操作，根据综合概率和所述代码提交操作的仿真信息中的提交类型，判断本次代码提交是否能够跳过持续集成操作；其中， 所述综合概率基于当前代码提交所属项目的历史代码提交日志中对应类型代码提交被判定为跳过的比例确定；
将能够跳过的第二代码提交缓存进待集成队列;
对于不能跳过的第一代码提交，根据结果预测阶段各预测模型的性能指标对所述第一代码提交的集成结果进行预测，得到预测结果;若所述第一代码提交的预测结果表示代码提交通过，则将所述第一代码提交缓存进所述待集成队列；若所述第一代码提交的预测结果表示代码提交失败且当前不存在空闲资源，则将所述第一代码提交缓存进集成队列；
若所述第一代码提交的预测结果表示代码提交失败，则对所述第一代码提交和本次代码提交之前被判定为能够跳过的第二代码提交进行集成仿真，得到集成结果和集成时间，并对所述集成结果是失败的代码提交进行缺陷修复仿真，得到修复时间；其中，所述对所述集成结果是失败的代码提交进行缺陷修复仿真，得到修复时间，包括：若所述集成结果是失败的代码提交是所述第一代码提交，则对所述第一代码提交进行及时修复仿真；若所述集成结果是失败的代码提交是所述第二代码提交，则对所述第二代码提交进行延迟修复仿真；
根据所述集成时间和修复时间对具有不同预测模型的持续集成过程进行评估得到评估结果。
2.根据权利要求1所述的方法，其特征在于，所述检测到代码提交仿真事件时，仿真一次代码提交操作，包括：
当与前一次代码提交的产生时间间隔满足提交间隔时，触发代码提交仿真事件，产生一次代码提交，其中，所述提交间隔基于历史代码提交日志中各项目的历史代码提交的分布信息确定；
根据所述历史代码提交日志中各项目的推送和拉取请求的提交比例，设定当前代码提交的提交类型；
根据所述历史代码提交日志中各项目的集成失败和通过的结果比例，设定当前代码提交的结果类型。
3.根据权利要求1所述的方法，其特征在于，所述对于不能跳过的第一代码提交，根据结果预测阶段各预测模型的性能指标对所述第一代码提交的集成结果进行预测，得到预测结果，包括：
对于不能跳过的第一代码提交，根据所述仿真信息中的结果类型确定所述第一代码提交对应的结果预测阶段的分支工作流；
根据所述分支工作流和各预测模型的性能指标对所述第一代码提交的集成结果进行预测，得到预测结果。
4.根据权利要求3所述的方法，其特征在于，所述根据所述分支工作流和各预测模型的性能指标对所述第一代码提交的集成结果进行预测，得到预测结果，包括：
基于各预测模型的混淆矩阵执行对应分支工作流，以对所述第一代码提交的集成结果进行预测得到预测结果，其中，所述预测结果包括将结果类型是失败的所述第一代码提交的集成结果预测为失败，将结果类型是失败的所述第一代码提交的集成结果预测为通过，将结果类型是通过的所述第一代码提交的集成结果预测为通过，或将结果类型是通过的所述第一代码提交的集成结果预测为失败。
5.根据权利要求1所述的方法，其特征在于，所述对所述第一代码提交和本次代码提交之前被判定为能够跳过的第二代码提交进行集成仿真，包括：
在存在空闲资源时，将所述待集成队列中的所有代码提交与所述集成队列中的当前第一代码提交合并为提交集，清空所述待集成队列；
通过所述空闲资源对所述提交集中的各代码提交进行集成仿真得到集成时间；
根据各代码提交的结果类型确定各次集成仿真的集成结果。
6.根据权利要求1所述的方法，其特征在于，所述根据所述集成时间和修复时间对具有不同预测模型的持续集成过程进行评估得到评估结果，包括：
根据所述集成时间和修复时间计算软件持续集成操作的时间成本；
根据所述时间成本确定具有不同预测模型的持续集成过程的性能评估结果。
7.一种用于执行软件持续集成的评估方法的计算机设备，包括处理器和存储器，所述存储器用于存储指令，其特征在于，当所述指令执行时使得所述处理器执行以下操作：
检测到代码提交仿真事件时，仿真一次代码提交操作，根据综合概率和所述代码提交操作的仿真信息中的提交类型，判断本次代码提交是否能够跳过持续集成操作；其中， 所述综合概率基于当前代码提交所属项目的历史代码提交日志中对应类型代码提交被判定为跳过的比例确定；
将能够跳过的第二代码提交缓存进待集成队列;
对于不能跳过的第一代码提交，根据结果预测阶段各预测模型的性能指标对所述第一代码提交的集成结果进行预测，得到预测结果;若所述第一代码提交的预测结果表示代码提交通过，则将所述第一代码提交缓存进所述待集成队列；若所述第一代码提交的预测结果表示代码提交失败且当前不存在空闲资源，则将所述第一代码提交缓存进集成队列；
若所述第一代码提交的预测结果表示代码提交失败，则对所述第一代码提交和本次代码提交之前被判定为能够跳过的第二代码提交进行集成仿真，得到集成结果和集成时间，并对所述集成结果是失败的代码提交进行缺陷修复仿真，得到修复时间；其中，所述对所述集成结果是失败的代码提交进行缺陷修复仿真，得到修复时间，包括：若所述集成结果是失败的代码提交是所述第一代码提交，则对所述第一代码提交进行及时修复仿真；若所述集成结果是失败的代码提交是所述第二代码提交，则对所述第二代码提交进行延迟修复仿真；
根据所述集成时间和修复时间对具有不同预测模型的持续集成过程进行评估得到评估结果。
8.根据权利要求7所述的设备，其特征在于，所述处理器被设置为采用如下方式仿真一次代码提交操作：
当与前一次代码提交的产生时间间隔满足提交间隔时，触发代码提交仿真事件，产生一次代码提交，其中，所述提交间隔基于历史代码提交日志中各项目的历史代码提交的分布信息确定；
根据所述历史代码提交日志中各项目的推送和拉取请求的提交比例，设定当前代码提交的提交类型；
根据所述历史代码提交日志中各项目的集成失败和通过的结果比例，设定当前代码提交的结果类型。
9.根据权利要求7所述的设备，其特征在于，所述处理器被设置为采用如下方式对不能跳过的第一代码提交的集成结果进行预测：
对于不能跳过的第一代码提交，根据所述仿真信息中的结果类型确定所述第一代码提交对应的结果预测阶段的分支工作流；
根据所述分支工作流和各预测模型的性能指标对所述第一代码提交的集成结果进行预测，得到预测结果。
10.根据权利要求9所述的设备，其特征在于，所述处理器还被设置为采用如下方式对不能跳过的第一代码提交的集成结果进行预测：
基于各预测模型的混淆矩阵执行对应分支工作流，以对所述第一代码提交的集成结果进行预测得到预测结果，其中，所述预测结果包括将结果类型是失败的所述第一代码提交的集成结果预测为失败，将结果类型是失败的所述第一代码提交的集成结果预测为通过，将结果类型是通过的所述第一代码提交的集成结果预测为通过，或将结果类型是通过的所述第一代码提交的集成结果预测为失败。
11.根据权利要求7所述的设备，其特征在于，所述处理器被设置为采用如下方式进行集成仿真：
在存在空闲资源时，将所述待集成队列中的所有代码提交与所述集成队列中的当前第一代码提交合并为提交集，清空所述待集成队列；
通过所述空闲资源对所述提交集中的各代码提交进行集成仿真得到集成时间；
根据各代码提交的结果类型确定各次集成仿真的集成结果。
12.根据权利要求7所述的设备，其特征在于，所述处理器被设置为采用如下方式对各所述预测模型的性能进行评估：
根据所述集成时间和修复时间计算软件持续集成操作的时间成本；
根据所述时间成本确定具有不同预测模型的持续集成过程的性能评估结果。
13.一种包含计算机可执行指令的存储介质，其特征在于，所述计算机可执行指令在由计算机处理器执行时用于执行如权利要求1-6中任一所述的软件持续集成的评估方法。
CN202011635238.3A 2020-12-31 2020-12-31 一种软件持续集成的评估方法、计算机设备及介质 Active CN112732565B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011635238.3A CN112732565B (zh) 2020-12-31 2020-12-31 一种软件持续集成的评估方法、计算机设备及介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011635238.3A CN112732565B (zh) 2020-12-31 2020-12-31 一种软件持续集成的评估方法、计算机设备及介质

Publications (2)

Publication Number Publication Date
CN112732565A CN112732565A (zh) 2021-04-30
CN112732565B true CN112732565B (zh) 2023-07-18

Family

ID=75608819

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011635238.3A Active CN112732565B (zh) 2020-12-31 2020-12-31 一种软件持续集成的评估方法、计算机设备及介质

Country Status (1)

Country Link
CN (1) CN112732565B (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113312617B (zh) * 2021-05-24 2023-11-03 南京大学 一种面向代码安全的提交优先级排序方法和系统
CN113792187B (zh) * 2021-09-30 2024-05-14 中国人民解放军国防科技大学 群智软件开发贡献质量评估方法、装置、设备及介质
CN113792189B (zh) * 2021-09-30 2024-05-14 中国人民解放军国防科技大学 群智软件开发贡献效率评估方法、装置、设备及介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106933736A (zh) * 2015-12-31 2017-07-07 中移(苏州)软件技术有限公司 一种项目持续集成的方法和系统
CN109240929A (zh) * 2018-09-18 2019-01-18 百度在线网络技术（北京）有限公司 软件质量预测方法、装置、终端和计算机可读存储介质
CN111367798A (zh) * 2020-02-28 2020-07-03 南京大学 一种持续集成及部署结果的优化预测方法
CN111427802A (zh) * 2020-06-09 2020-07-17 南京大学 利用集成学习进行测试用例优先级排序的测试方法和系统
CN111488136A (zh) * 2020-04-07 2020-08-04 携程旅游网络技术（上海）有限公司 持续集成和持续交付方法、系统、设备及存储介质
CN111585277A (zh) * 2020-05-19 2020-08-25 三峡大学 一种基于混合集成模型的电力系统动态安全评估方法

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9710364B2 (en) * 2015-09-04 2017-07-18 Micron Technology Licensing, Llc Method of detecting false test alarms using test step failure analysis

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106933736A (zh) * 2015-12-31 2017-07-07 中移(苏州)软件技术有限公司 一种项目持续集成的方法和系统
CN109240929A (zh) * 2018-09-18 2019-01-18 百度在线网络技术（北京）有限公司 软件质量预测方法、装置、终端和计算机可读存储介质
CN111367798A (zh) * 2020-02-28 2020-07-03 南京大学 一种持续集成及部署结果的优化预测方法
CN111488136A (zh) * 2020-04-07 2020-08-04 携程旅游网络技术（上海）有限公司 持续集成和持续交付方法、系统、设备及存储介质
CN111585277A (zh) * 2020-05-19 2020-08-25 三峡大学 一种基于混合集成模型的电力系统动态安全评估方法
CN111427802A (zh) * 2020-06-09 2020-07-17 南京大学 利用集成学习进行测试用例优先级排序的测试方法和系统

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
A cost-efficient approach to building in continuous integration;Xianhao Jin et al.;Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering;全文 *
Change-aware build prediction model for stall avoidance in continuous integration;Foyzul Hassan et al.;Proceedings of the 11th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement;全文 *
基于神经网络的过程自调节持续集成工具设计与实现;郭雪;《中国优秀硕士学位论文全文数据库信息科技辑》(第07期);全文 *
面向开源软件质量的社交技术一致性度量研究;张伟强;《中国优秀硕士学位论文全文数据库信息科技辑》(第11期);全文 *

Also Published As

Publication number Publication date
CN112732565A (zh) 2021-04-30

Similar Documents

Publication Publication Date Title
CN112732565B (zh) 一种软件持续集成的评估方法、计算机设备及介质
US10839314B2 (en) Automated system for development and deployment of heterogeneous predictive models
EP3282363A1 (en) Development and production data based application evolution
CN113157422A (zh) 基于深度强化学习的云数据中心集群资源调度方法及装置
CN111310998B (zh) 关键路径的生成方法、装置、电子设备和介质
CN112799782B (zh) 模型生成系统、方法、电子设备及存储介质
WO2014061229A1 (ja) 情報システム構築支援装置、情報システム構築支援方法および情報システム構築支援プログラム
JP2023086678A (ja) 深層学習フレームワークに基づいて深層学習モデルを生成して適用する方法及び装置
CN113095508A (zh) 回归模型构建优化方法、设备、介质及计算机程序产品
CN113792146A (zh) 基于人工智能的文本分类方法、装置、电子设备及介质
CN105279065A (zh) 在云测试平台中统计测试结果的方法及装置
US10332035B1 (en) Systems and methods for accelerating model training in machine learning
US20230008683A1 (en) Migration of vnfs to vims
US20230004870A1 (en) Machine learning model determination system and machine learning model determination method
CN115328772A (zh) 激励组合与模块相关性的学习方法与测试脚本产生方法
CN106209493B (zh) 一种对互联网服务系统进行流量跟踪的系统与方法
US20210271925A1 (en) Contact Center Call Volume Prediction
US9497253B2 (en) Authorization review system
CA3119490A1 (en) Contact center call volume prediction
KR20230037661A (ko) 컨테이너화된 애플리케이션의 배치를 최적화하기 위한 시스템, 방법 및 서버
CN111861012A (zh) 一种测试任务执行时间预测方法及最优执行节点选择方法
CN111679924A (zh) 构件化软件系统可靠性仿真方法、装置及电子设备
Kim et al. RETRACTED ARTICLE: Simulator considering modeling and performance evaluation for high-performance computing of collaborative-based mobile cloud infrastructure
US10268958B1 (en) Recommended launch configuration
Коваль et al. Data collection for analytical activities using adaptive micro-service architecture

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant