CN113835742A - 持续集成方法及软件开发系统 - Google Patents

Abstract

本申请涉及人工智能技术领域，提供一种持续集成方法及软件开发系统。其中，持续集成方法包括：持续集成系统从变更管理系统获取变更信息并根据变更信息分配编译机；编译机根据变更信息进行代码编译，将编译成功的软件版本上传至版本服务器保存，并向持续集成系统发送其存放路径；自动化测试系统从持续集成系统获取待测试的软件版本的存放路径，将对应的软件版本部署到分配好的自动化测试设备上进行测试，并向持续集成系统发送测试结果；持续集成系统在测试通过时，通知变更管理系统记录测试结果并将变更的代码文件上库。该方法有利于及时发现和解决代码中存在的问题，且能够将问题代码拦截在上库之前，确保了上库的代码可以编译出有效的软件版本。

Description

持续集成方法及软件开发系统

技术领域

本发明涉及软件开发技术领域，具体而言，涉及一种持续集成方法及软件开发系统。

背景技术

持续集成(Continuous Integration,简称CI)是一种软件开发实践，即开发人员经常性集成他们编写的代码，每次集成都通过自动化的方式进行CI构建，一般来说每次CI构建都会借助工具完成代码编译、自动化测试等环节以验证软件版本的正确性，从而尽早地发现软件缺陷并修复，保证项目随时都有可用的、高质量的软件版本。

现在的企业通常按照项目级的软件版本做CI构建，每天夜间针对开发人员提交上库的代码开展一次CI构建，第二天发现问题后再由开发人员解决。这种方式存在的问题是：其一，不利于及时发现和解决代码中存在的问题；其二，如果问题代码已经上库，直到问题解决之前代码库中最新的代码很可能无法编译出有效的软件版本，对项目造成不利影响。

发明内容

本申请实施例的目的在于提供一种持续集成方法及软件开发系统，以改善上述技术问题。

为实现上述目的，本申请提供如下技术方案：

第一方面，本申请实施例提供一种持续集成方法，包括：持续集成系统从变更管理系统获取变更信息，根据获取到的变更信息分配编译机，并向分配好的编译机发送所述变更信息；所述编译机根据所述变更信息从代码库下载最新的代码，将变更的代码文件合并入下载的代码中，并对合并后的代码进行编译；其中，所述变更信息包括变更的代码文件；所述编译机将编译成功的软件版本上传至版本服务器保存，并向所述持续集成系统发送该软件版本在所述版本服务器上的存放路径；自动化测试系统从所述持续集成系统获取待测试的软件版本的存放路径，根据所述存放路径从所述版本服务器获取对应的软件版本，将该软件版本部署到分配好的自动化测试设备上进行测试，并向所述持续集成系统发送该软件版本对应的变更的测试结果；所述持续集成系统在变更的测试结果为测试通过时，通知所述变更管理系统记录变更的测试结果并将变更的代码文件上传至所述代码库。

首先，上述方法基于变更做CI构建，因此其构建的频度显著高于版本级CI(即基于项目级的软件版本做CI构建)，构建周期可以达到小时或分钟级，从而有利于及时发现和解决代码中存在的问题。其次，变更的代码文件要在编译成功以及测试通过后才会上库，从而显著提高了代码库中的代码质量，确保了上库的代码可以编译出有效的软件版本，从而在此基础上项目开发会更顺利，项目周期将进一步缩短，软件发布频率将进一步提高。此外，由于问题代码被拦截在上库之前，其影响范围有限，因此该方法还有利于缓解提交了问题代码的开发人员的工作压力。

在第一方面的一种实现方式中，所述变更信息还包括变更标识、变更对应的代码分支以及变更对应的产品；所述持续集成系统根据获取到的变更信息分配编译机，包括：所述持续集成系统根据变更对应的代码分支以及变更对应的产品分配编译机；所述编译机根据所述变更信息从代码库下载最新的代码，包括：所述编译机根据变更对应的代码分支以及变更对应的产品从代码库下载最新的代码。

变更标识用于唯一表示一个变更，在后续定位存在问题的变更时可根据该标识区分不同的变更。编译不同的产品、不同的代码分支可能需要不同的工具链，各编译机根据硬件配置不同以及操作系统的不同会安装不同的工具链，所安装的工具链也决定了编译机的编译能力或者说编译范围。从而在持续集成系统为变更分配编译机时，可以根据变更对应的代码分支以及变更对应的产品分配与之匹配的编译机。

在第一方面的一种实现方式中，所述持续集成系统从变更管理系统获取变更信息，包括：所述持续集成系统轮询待执行持续集成的项目清单，获取当前待执行项目，并从所述变更管理系统提取与所述当前待执行项目对应的变更信息，所述对应的变更信息为所述变更管理系统执行过滤操作后的变更信息；其中，所述过滤操作包括第一过滤操作和/或第二过滤操作，所述第一过滤操作是指，判断所述当前待执行项目对应的变更中是否存在有变更间依赖关系的变更，若存在，则判断存在变更间依赖关系的变更所依赖的变更的变更信息在所述变更管理系统中是否完整，若不完整，则过滤掉该存在有变更间依赖关系的变更的变更信息；所述第二过滤操作是指过滤掉所述当前待执行项目对应的变更信息中测试通过的变更的变更信息。

有一些变更是相互依赖的，对于相互依赖的变更需要一同进行编译，否则可能导致编译失败。然而，并不能保证相互依赖的变更一定会被开发人员一并提交到变更管理系统。所以，在变更管理系统上可以将变更间的依赖关系先记录下来，在对某个变更进行编译之前，先要确定其是否有依赖的变更，若没有，则可以进行编译，若有，则还需进一步判断其依赖的变更的变更信息在变更管理系统中是否完整，若完整，表明其依赖的变更已经被提交到了变更管理系统，该变更可以连同其依赖的变更一起编译，若不完整，则还需等待其依赖的变更被提交至变更管理系统，该变更暂时不可编译。通过第一过滤操作将当前因依赖问题而暂时无法编译的变更的变更信息过滤掉。

在变更管理系统中会记录每个变更在持续集成过程中的状态，对于已经测试通过的变更，可以不必参与下一个版本的编译，通过第二过滤操作将这些变更的变更信息过滤掉。

在第一方面的一种实现方式中，在所述编译机对合并后的代码进行编译之后，所述方法还包括：所述编译机向所述持续集成系统发送编译结果；所述持续集成系统在所述编译结果为编译失败时，根据所述编译结果中有关导致编译失败的代码文件的信息确定编译失败的变更，并将有关编译失败的变更的信息通知所述变更管理系统，所述变更管理系统将有关编译失败的变更的信息通知用户；或者，所述持续集成系统向所述变更管理系统发送所述编译结果，所述变更管理系统在所述编译结果为编译失败时，根据所述编译结果中有关导致编译失败的代码文件的信息确定编译失败的变更，并将有关编译失败的变更的信息通知用户。

编译工具在编译时可以定位到出错的代码文件，而根据变更的代码文件又可以定位到文件所属的变更。理想情况下，可以开发人员每提交一个变更就做一次编译，但多数企业并没有足够的编译资源达成这样的目标，然而，由于在上述实现方式中可以通过编译结果精确定位变更，所以在持续集成系统获取的变更信息中完全可以包含多个变更的变更信息，并不需要针对每个变更单独做编译，使得对编译资源的要求得以大幅降低，在编译资源有限的情况下开展变更级CI也成为可能。

在第一方面的一种实现方式中，所述方法还包括：所述持续集成系统在变更的测试结果为测试未通过时，将测试未通过的变更的信息通知所述变更管理系统。

在自动化测试失败时，类似于编译失败，也可以通过测试结果精确定位变更，并不需要对每个变更单独做自动化测试，使得对测试资源的要求得以大幅降低，在测试资源有限的情况下开展变更级CI也成为可能。

第二方面，本申请实施例提供一种持续集成方法，包括：持续集成系统从变更管理系统获取变更信息，根据获取到的变更信息分配编译机，并向分配好的编译机发送所述变更信息；所述编译机根据所述变更信息从代码库下载最新的代码，将变更的代码文件合并入下载的代码中，对合并后的代码进行编译，并向所述持续集成系统发送编译结果；其中，所述变更信息包括变更的代码文件；所述持续集成系统在所述编译结果为编译成功时，通知所述变更管理系统将变更的代码文件上传至所述代码库；所述编译机将编译成功的软件版本上传至版本服务器保存，并向所述持续集成系统发送该软件版本在所述版本服务器上的存放路径；自动化测试系统从所述持续集成系统获取待测试的软件版本的存放路径，根据所述存放路径从所述版本服务器获取对应的软件版本，并将该软件版本部署到分配好的自动化测试设备上进行测试。

首先，上述方法基于变更做CI构建，因此其构建的频度显著高于版本级CI(即基于项目级的软件版本做CI构建)，从而有利于及时发现和解决代码中存在的问题。其次，变更的代码文件要在编译成功后才会上库，从而显著提高了代码库中的代码质量，确保了上库的代码可以编译出有效的软件版本。此外，由于问题代码被拦截在上库之前，其影响范围有限，因此该方法还有利于缓解提交了问题代码的开发人员的工作压力。

第二方面提供的持续集成方法和第一方面提供的持续集成方法比较类似，其区别主要在于若编译成功，则变更的代码文件会直接上库，在后期再进行测试。例如，在当前自动化测试资源不足时则可按照此方法操作，实践发现，编译成功的代码存在严重问题的概率不大，提前上库并不会对项目产生大的负面影响。

第三方面，本申请实施例提供一种软件开发系统，包括：代码库、变更管理系统、持续集成系统、编译机、版本服务器以及自动化测试系统；其中，所述持续集成系统用于从所述变更管理系统获取包括变更的代码文件在内的变更信息，根据获取到的变更信息分配所述编译机，并向分配好的所述编译机发送所述变更信息，以及用于接收所述自动化测试系统发送的变更的测试结果，并在变更的测试结果为测试通过时，通知所述变更管理系统记录变更的测试结果并将变更的代码文件上传至所述代码库；所述编译机用于根据所述变更信息从所述代码库下载最新的代码，将变更的代码文件合并入下载的代码中，并对合并后的代码进行编译，以及用于将编译成功的软件版本上传至所述版本服务器保存，并向所述持续集成系统发送该软件版本在所述版本服务器上的存放路径；所述自动化测试系统用于从所述持续集成系统获取待测试的软件版本的存放路径，根据所述存放路径从所述版本服务器获取对应的软件版本，将该软件版本部署到分配好的所述自动化测试设备上进行测试，并向所述持续集成系统发送该软件版本对应的变更的测试结果。

在第三方面的一种实现方式中，所述变更信息还包括变更标识、变更对应的代码分支以及变更对应的产品；所述持续集成系统用于根据获取到的变更信息分配所述编译机，包括：所述持续集成系统用于根据变更对应的代码分支以及变更对应的产品分配所述编译机；所述编译机用于根据所述变更信息从代码库下载最新的代码，包括：所述编译机用于根据变更对应的代码分支以及变更对应的产品从代码库下载最新的代码。

在第三方面的一种实现方式中，所述持续集成系统用于从变更管理系统获取包括变更的代码文件在内的变更信息，包括：所述持续集成系统用于轮询待执行持续集成的项目清单，获取当前待执行项目，并从所述变更管理系统提取与所述当前待执行项目对应的变更信息，所述对应的变更信息为所述变更管理系统执行过滤操作后的变更信息；其中，所述过滤操作包括第一过滤操作和/或第二过滤操作，所述第一过滤操作是指，判断所述当前待执行项目对应的变更中是否存在有变更间依赖关系的变更，若存在，则判断存在变更间依赖关系的变更所依赖的变更的变更信息在所述变更管理系统中是否完整，若不完整，则过滤掉该存在有变更间依赖关系的变更的变更信息；所述第二过滤操作是指过滤掉所述当前待执行项目对应的变更信息中测试通过的变更的变更信息的操作。

第四方面，本申请实施例提供一种软件开发系统，包括：代码库、变更管理系统、持续集成系统、编译机、版本服务器以及自动化测试系统；其中，所述持续集成系统用于从所述变更管理系统获取包括变更的代码文件在内的变更信息，根据获取到的变更信息分配所述编译机，并向分配好的所述编译机发送所述变更信息，以及用于接收所述编译机发送的编译结果，并在所述编译结果为编译成功时，通知所述变更管理系统将变更的代码文件上传至所述代码库；所述编译机用于根据所述变更信息从所述代码库下载最新的代码，将变更的代码文件合并入下载的代码中，对合并后的代码进行编译，并向所述持续集成系统发送所述编译结果，以及用于将编译成功的软件版本上传至所述版本服务器保存，并向所述持续集成系统发送该软件版本在所述版本服务器上的存放路径；所述自动化测试系统用于从所述持续集成系统获取待测试的软件版本的存放路径，根据所述存放路径从所述版本服务器获取对应的软件版本，并将该软件版本部署到分配好的所述自动化测试设备上进行测试。

第五方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被处理器读取并运行时，执行第一方面或第一方面的任意一种可能的实现方式提供的方法。

第六方面，本申请实施例提供一种电子设备，包括：存储器以及处理器，所述存储器中存储有计算机程序指令，所述计算机程序指令被所述处理器读取并运行时，执行第一方面或第一方面的任意一种可能的实现方式提供的方法。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本申请实施例提供的持续集成方法的流程图；

图2示出了测试与编译的异步工作原理图；

图3示出了本申请实施例提供的电子设备的示意图。

具体实施方式

现在的企业通常按照项目级的软件版本做CI构建，这种持续集成方式可简称为版本级CI。版本级CI每天针对开发人员提交上库的代码开展一次CI构建，时间一般安排在晚上，第二天发现问题后再由开发人员解决。

发明人经长期研究发现，版本级CI存在的问题主要有：其一，构建周期太长，不利于及时发现和解决代码中存在的问题；其二，如果问题代码已经上库，直到问题解决之代码库中最新的代码很可能无法编译出有效的软件版本，对项目造成不利影响；其三，由于所有开发人员都从代码库中下载代码，如果代码库中的代码问题迟迟不能解决，会在较大范围内造成影响，提交问题代码的开发人员将承受整个项目带来的巨大压力，长此以往，不利于企业人员稳定。

针对上述问题，本申请提出一种变更级CI的解决方案，所谓变更级CI即按照变更级的软件版本做CI构建，方案的具体细节将在后文阐述。需要指出，版本级CI中存在的上述缺陷，是发明人在经过实践并仔细研究后得出的结果，因此上述问题的发现过程以及下文中变更级CI的方案内容，都应视为发明人在发明过程中对本发明做出的贡献。

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

图1示出了本申请实施例提供的持续集成方法的流程图，该方法可由一软件开发系统执行，参照图1，该软件开发系统包括：代码库、变更管理系统、持续集成系统、编译机、版本服务器以及自动化测试系统。各组件功能概述如下(后文还会结合方法步骤进一步阐述)：

代码库：用于存储项目代码：

变更管理系统：用于管理开发人员提交的变更；

持续集成系统：用于控制整个CI构建的流程；

编译机：用于代码编译；

版本服务器：用于存放编译成功的软件版本；

自动化测试系统：用于控制软件版本的自动化测试流程。

另外，图1中还示出了用于部署软件版本并进行自动化测试的自动化测试设备。

该软件开发系统可以部署在一台或多台图3示出的电子设备200上，关于电子设备200的结构，具体可参考关于图3的阐述。应当理解，该软件开发系统还可以包括图1中未示出的组件。参照图1，持续集成方法包括：

步骤S100：持续集成系统从变更管理系统获取变更信息。

开发人员修改项目的代码文件后，将变更的代码文件提交到变更管理系统，变更管理系统先将变更的代码文件缓存起来，在后续步骤中可能会将其提交到代码库，缓存变更的代码文件可能采取多种方式：例如，缓存修改后的文件；又例如，只缓存修改前后的差异内容，等等。变更管理系统可以采用SVN、Git等实现。

持续集成系统不断地从变更管理系统获取变更信息，变更信息至少包括变更的代码文件，还可以包括变更标识、变更对应的代码分支以及变更对应的产品等信息。其中，变更标识用于唯一表示一个变更，在后续步骤中定位存在问题的变更时可根据该标识区分不同的变更，至于变更对应的代码分支以及变更对应的产品等信息两项信息的用途稍后再介绍。变更信息可能对应一个或多个变更。

持续集成系统获取变更信息的方式既可以是主动获取也可能是被动接收。例如，持续集成系统可以定期(如30分钟、1小时等)从变更管理系统获取变更信息；又例如，变更管理系统在开发人员每提交了10个变更后向持续集成系统发送一次这10个变更的变更信息，等等。

在一些实现方式中，开发人员事先在持续集成系统上配置好需要进行持续集成的项目，形成一个项目清单，持续集成系统定期轮询待执行持续集成的项目清单，获取当前待执行持续集成的项目，然后从变更管理系统提取与当前待执行项目对应的变更信息，后文会给出变更信息可能的提取方式，这里暂不具体介绍。

变更管理系统向持续集成系统发送变更信息后，还可以在系统上标记出哪些变更正在执行CI构建，以便用户通过变更管理系统可以实时掌握变更的处理状态。例如，在一些实现方式中，代码需要人工审批才能上库，若人工发现代码正在执行自动化的CI构建，则可暂缓审批流程。

步骤S101：持续集成系统根据获取到的变更信息分配编译机，并向分配好的编译机发送变更信息。

编译机泛指具有编译能力的设备，在本申请的方案中负责编译持续集成系统获取到的变更信息中包含的变更的代码文件，编译机既可以是物理机也可以是虚拟机，编译机可由持续集成系统负责管理。编译不同的产品、不同的代码分支可能需要不同的工具链，各编译机根据硬件配置不同以及操作系统的不同会安装不同的工具链，所安装的工具链也决定了编译机的编译能力或者说编译范围。从而若变更信息中包含变更对应的代码分支以及变更对应的产品时，持续集成系统可以根据这两项信息为变更分配与之匹配的编译机。

当然，分配编译机也可以采用一些其他规则，例如，若同一款产品的所有代码分支都可以采用相同配置的编译机进行编译，则分配编译机时也可以只考虑变更对应的产品这一项信息。

步骤S102：编译机根据变更信息从代码库下载最新的代码。

例如，若变更信息中包含变更对应的代码分支以及变更对应的产品时，编译机可以根据这两项信息从代码库下载最新的代码到编译机本地。当然，若变更对应的产品是默认的，也不排除仅根据变更对应的代码分支进行代码下载。

步骤S103：编译机将变更的代码文件合并入下载的代码中，并对合并后的代码进行编译。

步骤S104：编译机向持续集成系统发送编译结果。

步骤S105：持续集成系统处理编译结果。

步骤S106：变更管理系统将变更的代码文件上传至代码库。

以上四个步骤合并在一起进行阐述，编译机自动对合并后的代码进行编译，例如，可以预先配置好编译脚本并自动执行。编译结果包括两种，一种表示编译成功，一种表示编译失败。

持续集成系统接收到编译结果后，若发现编译结果为编译成功，可以通知变更管理系统将变更的代码文件上库，在之后的某个时刻再对编译好的、包含该变更的软件版本进行测试。例如，若当前自动化测试资源不足，可以提前将未测试的代码上库，并且经发明人长期实践发现，编译成功的代码存在严重问题的概率不大，提前上库并不会对项目产生大的负面影响。

当然，还存在另一种选择，持续集成系统接收到编译结果后，若发现编译结果为编译成功，不执行步骤S106，而是继续执行后续的测试步骤，代码上库可能要等到测试完成之后(步骤S117)。

对于编译失败的情况，编译工具在编译时可以定位到出错的代码文件，从而在编译结果中也可以包含有关导致编译失败的代码文件的信息。进而持续集成系统在接收到表示编译失败的编译结果后，根据该信息可以定位到出错文件所属的变更。

进一步的，持续集成系统可以将有关编译失败的变更的信息(例如，变更标识)通知变更管理系统，由变更管理系统进一步通知提交该变更的开发人员解决。当然，也不排除持续集成系统直接将有关编译失败的变更的信息通知开发人员，促使开发人员解决问题，或者，也可以既通知开发人员又通知变更管理系统。系统(指变更管理系统或持续集成系统)通知开发人员的方式有多种，例如发邮件、短信、聊天消息等，若系统明确要通知哪个开发人员，可以发送针对性消息，若系统不明确要通知哪个开发人员，也可以采取群发策略，提交了问题代码的开发人员也会注意到。以上作为被通知对象的开发人员，也可以替换为其他用户，如项目相关者。

在一些可选方案中，持续集成系统接收到编译结果后，也可以直接将编译结果发送给变更管理系统(图1未示出该步骤)，由于变更管理系统上也保存有变更信息，所以变更管理系统根据编译结果中有关导致编译失败的代码文件的信息同样可以定位到出错文件所属的变更，并将有关编译失败的变更的信息通知提交该变更的开发人员解决。

对于变更级CI，在编译资源充足的情况下，可以开发人员每提交一个变更就做一次编译(即持续集成系统每次获取的变更信息只包含一个变更)，但多数企业可能并没有足够的编译资源达成这样的目标。正如上面指出的，在一些实现方式中，由于持续集成系统或变更管理系统可以通过编译结果精确定位问题变更，因此在持续集成系统获取的变更信息中完全可以包含多个变更的变更信息，从而可以将这些变更进行批量编译，而不需要针对每个变更单独做编译，使得在CI构建的过程中对编译资源的要求得以大幅降低，进而使得在编译资源有限的情况下开展变更级CI也成为可能。

步骤S107：编译机将编译成功的软件版本上传至版本服务器保存。

编译机可以在编译成功后才将编译产生的软件版本上传，但也不排除在一些实现方式中，编译机在编译的同时就进行软件版本的上传，若后期发现编译失败扫描失败，则可以舍弃已经部分上传软件版本或者将其标记为无效版本。

步骤S108：编译机将向持续集成系统发送编译成功的软件版本在版本服务器上的存放路径。

步骤S109：自动化测试系统从持续集成系统获取待测试的软件版本的存放路径。

自动化测试系统获取存放路径的方式既可以是主动获取也可能是被动接收。例如，自动化测试系统可以定期(如1小时、2小时等)从持续集成系统获取待测试的软件版本的存放路径，即采用轮询的方式；又例如，持续集成系统可以在每获得一个新的软件版本的存放路径后就向自动化测试系统主动推送该存放路径，告知自动化测试系统版本服务器上存在一个可用于测试的软件版本，等等。步骤S109中待测试的软件版本和步骤S108中编译成功的软件版本可能是一一对应的，即每个编译成功的软件版本都会被自动化测试系统获取用于测试，此时编译和测试是同步的；但在不同的实现方式中，编译成功的软件版本也可能只有部分被自动化测试系统获取用于测试，此时编译和测试是异步的，关于编译和测试的同异步关系的问题，在后文再进行阐述。

步骤S110：自动化测试系统为待测试的软件版本分配自动化测试设备。

在一些实现方式中，可以采取简单的分配策略，例如直接分配空闲的自动化测试设备。在另一些实现方式中，则可以根据待测试的软件版本对应的变更分配自动化测试设备，其可能的做法如下：

首先，自动化测试系统从持续集成系统获取待测试的软件版本对应的变更信息，由于整个编译过程都处于持续集成系统的控制之下，所以编译成功的软件版本与变更信息的对应关系可由持续集成系统记录。注意，自动化测试系统获取的变更信息中可以不包含变更的代码文件，但应包含对变更的代码文件的描述，如文件名、路径等，以便在后续步骤中使用。

然后，自动化测试系统根据变更信息确定变更的代码文件所属的产品模块，此处的产品模块可以指软件产品的功能模块，如登陆模块、查询模块、界面展现模块等，产品模块与代码文件的对应关系可以由一个单独的系统(下文简称系统A)进行维护(例如，系统A可以记录每个产品模块对应的代码路径)，系统A也可以作为本申请实施例提供的软件开发系统的组件。从而，自动化测试系统基于变更信息中变更的代码文件查询系统A就可以得到对应的产品模块，可以理解的，在某些可选方案中，变更信息中的其他信息项也可以作为查询变更的代码文件对应的产品模块的依据。

再然后，自动化测试系统根据变更的代码文件所属的产品模块查找用于测试产品模块的自动化测试脚本，自动化测试脚本与产品模块的对应关系可以是预先配置好的，例如，也可由系统A负责维护。每个产品模块需要一个或多个自动化测试脚本进行测试。

最后，自动化测试系统根据要执行的自动化测试脚本计算所需的测试资源，并根据计算出的测试资源分配用于执行自动化测试脚本的自动化测试设备。

在一次测试中，一个或多个产品模块对应的自动化测试脚本并不一定会全部执行，也可能只需要执行其中的一部分，视测试需求而定。例如，若只测试产品模块的基础功能，则只需执行那些与基础功能相关的自动化测试脚本。

自动化测试脚本中会对脚本的执行条件进行一定的约束，其中可以包括执行该脚本所需的测试资源，从而自动化测试系统可以根据要执行的自动化测试脚本计算所需的测试资源，进而根据计算出的测试资源进行自动化测试设备的分配。

步骤S111：自动化测试系统根据待测试的软件版本的存放路径从版本服务器获取对应的软件版本。

步骤S111和步骤S110在执行上没有严格的先后顺序，或者也可以并行执行，只要确保在对软件版本进行实际测试之前获取到该软件版本即可。

步骤S112：自动化测试系统将待测试的软件版本部署到自动化测试设备上。

步骤S113：自动化测试设备对软件版本进行测试。

在自动化测试系统中，根据要执行的自动化测试脚本可以生成测试任务，即一个测试任务可以包含一个或多个自动化测试脚本。测试任务被分配到自动化测试设备上执行，以实现自动化测试。

步骤S114：自动化测试系统向持续集成系统发送软件版本对应的变更的测试结果。

步骤S115：持续集成系统处理变更的测试结果。

步骤S116：变更管理系统记录变更的测试结果。

步骤S117：变更管理系统将变更的代码文件上传至代码库。

以上四个步骤合并在一起进行阐述，自动化测试系统从自动化测试设备处收集测试结果，测试结果有不同的实现方式：一种是针对一个软件版本给出一个总的测试结果(通过或未通过)，一种是针对被测试的软件版本对应的每个变更给出一个测试结果(通过或未通过)，下面主要介绍后者。

如前文所述，自动化测试基于自动化测试脚本执行，测试失败可以定位到导致失败的自动化测试脚本，而自动化测试脚本与产品模块具有对应关系，从而自动化测试系统根据导致失败的自动化测试脚本可以定位到相应的产品模块，而产品模块与变更的代码文件又有对应关系，从而可以进一步定位到导致测试失败的变更。当然，也不排除某个产品模块中本次包含了多个变更，则可以暂时将这些变更都认为是导致测试失败的变更，等待后续人工进一步分析，由于变更级CI每次CI构建的间隔时间较短，所以一个产品模块中包含多个变更的情况较少出现，从而可以认为定位到了导致测试失败的产品模块也就基本定位到了导致测试失败的变更。除了导致测试失败的变更，剩余的就是测试通过的变更，从而，自动化测试系统基本上可以精确给出每个变更的测试结果。需要指出，即使整个软件版本未通过测试，并不代表其中的每个变更都未通过测试，因为很多产品模块在功能上是相互独立的，这些模块中的变更是否能通过测试互不影响。

持续集成系统接收到变更的测试结果后，可以先将测试结果记录下来，若发现变更的测试结果为测试通过，可以通知变更管理系统将变更的代码文件上库，测试通过的变更之后很可能就不会再重复编译了。若发现测试结果为测试未通过，则可将测试未通过的变更的信息(例如，变更标识)通知变更管理系统，再由变更管理系统通知开发人员解决问题(当然，也不排除持续集成系统直接通过开发人员的实现方式)。此处的开发人员也可以替换为其他用户，如项目相关者。测试未通过的变更之后(指解决该变更存在的问题后)应当被重新编译。

类似于编译的情况，由于持续集成系统可以通过测试结果精确定位问题变更，因此在持续集成系统获取的变更信息中完全可以包含多个变更，可以将这些变更一起进行编译，并对编译产生的软件版本进行测试，而不需要针对每个变更单独编译软件版本并测试，使得在CI构建的过程中对测试资源的要求也得到降低，进而使得在测试资源有限的情况下开展变更级CI也成为可能。

综上所述，首先，本申请实施例提供的持续集成方法基于变更做CI构建，因此其构建的频度可以显著高于版本级CI，构建周期可以达到小时或分钟级，从而有利于及时发现和解决代码中存在的问题。其次，变更的代码文件要在编译成功以及测试通过后才会上库(当然，在一些情况下也可以编译成功后就上库)，从而显著提高了代码库中的代码质量，确保了上库的代码可以编译出有效的软件版本，从而在此基础上项目开发会更顺利，项目周期将进一步缩短，软件发布频率将进一步提高。此外，由于问题代码被拦截在上库之前，其影响范围有限，因此该方法还有利于缓解提交了问题代码的开发人员的工作压力，长期看来还有助于为开发人员创造更好的工作环境，减小开发人员流动的概率。

下面举一个具体的例子说明上面的图1中的步骤，在该例子中，变更的代码文件要在测试完成后才会上库。另外，需要注意的是下面的步骤并不与图1中的步骤严格一一对应，但总体上描述的流程是相同的(只涉及代码无异常的流程)。

步骤(1)多名开发人员在变更管理系统上提交了10个变更，变更标识为1-10，变更对应的代码分支为BranchA，变更对应的产品为ProductA。持续集成系统从变更管理系统获取待验证的变更1-10的变更信息。

步骤(2)持续集成系统根据代码分支BranchA和产品ProductA为变更1-10分配用于执行编译的编译机compilerA。

步骤(3)持续集成系统将变更1-10的变更信息发送给编译机compilerA。

步骤(4)编译机compilerA启动进程PA根据代码分支BranchA和产品ProductA，从代码库下载最新的代码，并将变更1-10的变更代码文件合入刚下载的代码中。

步骤(5)编译机compilerA对合并后的代码进行编译，若编译未出现问题，将成功编译出的自动化测试所需的版本A存放到版本服务器上。

步骤(6)编译机compilerA将版本A的存放路径反馈给持续集成系统保存。

步骤(7)自动化测试系统的测试进程PB为常驻进程，每隔一定间隔轮询持续集成系统，当其检测到存在未测试的新版本A时，从持续集成系统获取版本A的存放路径以及变更1-10的变更信息。

步骤(8)自动化测试系统根据变更信息中对变更的代码文件的描述查询到变更1-10所属的产品模块M1、M2，并获取用于测试产品模块M1、M2的自动化测试脚本。

步骤(9)自动化系统根据要执行的自动化测试脚本计算所需的测试资源，并根据计算出的测试资源分配用于执行这些自动化测试脚本的自动化测试设备。

步骤(10)自动化测试系统根据版本A的存放路径从版本服务器上获取版本A，并将版本A部署到自动化测试设备上。

步骤(11)自动化测试系统根据要执行的自动化测试脚本，生成自动化测试任务，并在自动化测试设备上执行测试任务。

步骤(12)自动化测试结束，自动化测试系统将变更1-10的测试结果反馈给持续集成系统，若变更1-10的测试结果均为测试通过，则持续集成系统通知变更管理系统变更1-10验证通过(指编译、自动化测试均通过)，变更管理系统将变更1-10的变更代码文件提交上库，完成对变更1-10的集成。

下面再说明一下本申请实施例提供的持续集成方法中变更信息获取的问题(步骤S100)。

在一些实现方式中，持续集成系统向变更管理系统请求当前待执行持续集成的项目的变更信息，变更管理系统接收到请求后，可以首先确定出当前待执行项目对应的全部变更的变更信息，然后变更管理系统执行预定义的过滤操作将部分本次不需要编译的变更信息过滤掉，并将剩余的变更信息返回给持续集成系统执行后续的编译流程，下面介绍两类可能采取的过滤操作。

第一过滤操作：

变更管理系统判断当前待执行项目对应的变更中是否存在有变更间依赖关系的变更，若存在，则进一步判断存在变更间依赖关系的变更所依赖的变更的变更信息在变更管理系统中是否完整，若不完整，则过滤掉该存在有变更间依赖关系的变更的变更信息。

有一些变更是相互依赖的，对于相互依赖的变更需要一同进行编译，否则可能导致编译失败。然而，并不能保证相互依赖的变更一定会被开发人员一并提交到变更管理系统，但变更管理系统可以先响应用户的变更关联操作，将变更之间的变更间依赖关系先保存下来(例如，作为变更信息中的一个字段)。后续在对某个变更(以下称变更A)进行编译之前，变更管理系统先要确定变更A是否有依赖的变更，若没有依赖的变更，则可以进行编译，正常向持续集成系统返回变更A的变更信息，若有依赖的变更(以下称变更B)，则还需进一步判断变更B的变更信息在变更管理系统中是否完整，若完整，表明变更B已经被提交到了变更管理系统(在变更B提交之前，变更管理系统中虽然记录有变更A、B的依赖关系，但并没有记录变更B完整的变更信息)，变更A可以连同其依赖的变更B一起编译，若不完整，则还需等待变更B被提交至变更管理系统，变更A暂时不可编译，从而可以通过第一过滤操作将当前因依赖问题而暂时无法编译的变更A的变更信息过滤掉。

在变更管理系统中会记录每个变更在持续集成过程中的状态，对于已经测试通过的变更，可以不必参与下一个版本的编译，通过第二过滤操作将这些变更的变更信息过滤掉。对于未测试通过的变更，包括尚未编译过的变更、编译过但还没测试过的变更、编译过但没编译成功的变更、测试过但没测试通过的变更，都可以包含在要保留的变更信息中，使得开发人员提交的全部变更最终都得到集成。当然，对于编译过但没编译成功的变更以及测试过但没测试通过的变更，若开发人员还没有解决其中存在的问题，可以暂缓编译，或者说暂时将其过滤掉。

在不同的实现方式中，第一过滤操作和第二过滤操作可以择一执行，也可以两个都都执行，当然也不排除变更管理系统可以采取其他的过滤操作。

接下来再介绍一下编译和测试的同异步关系的问题：

只考虑在测试成功后才会将代码上库的情况，一次CI构建大体上可以分为编译和测试两个阶段，这两个阶段以图1中的步骤S109为分界点，该步骤之前可以认为是编译阶段，该步骤之后可以认为是测试阶段。变更管理系统中至少会执行第二过滤操作，用于控制每次编译的变更。

在编译阶段，持续集成系统按照一定的频率从变更管理系统获取新的变更信息，由于编译机的分配和编译都处于持续集成系统的控制之下，所以可以认为编译机编译软件版本的频率(简称编译频率)和持续集成系统的工作频率是相同的。在测试阶段，自动化测试系统按照一定的频率从持续集成系统获取待测试的软件版本在版本服务器上的存放路径，紧接着从该存放路径处获取对应的软件版本进行自动化测试，从而可以认为自动化测试系统测试软件版本的频率(简称测试频率)和其获取存放路径的频率是相同的。至于编译频率和测试频率，则既可能相同，也可能不同。

若测试频率和编译频率相同，即测试与编译同步，也就是说每个编译成功的软件版本都会同步地被自动化测试系统取走用于测试，不会出现某个编译好的软件版本未被取走测试的情况。此时若变更的编译和测试均无异常，变更管理系统每次都会将之前从未编译过的新变更信息返回给持续集成系统用于编译新的软件版本。

若测试频率低于编译频率，即测试与编译异步，也就是说并非每个编译成功的软件版本都会同步地被自动化测试系统取走用于测试，在同一段时间内，编译产生的软件版本的数量将多于被取走测试的软件版本的数量。在实践中，测试与编译异步的情况可能占大多数，因为测试过程，特别是黑盒测试耗时较长，使得测试资源相对于编译资源更为紧张。

此时若变更的编译和测试均无异常，变更管理系统每次除了将之前从未编译过的新变更信息返回给持续集成系统以外，还需要将那些通过了编译但还没测试过的变更的变更信息返回给持续集成系统。由于第二过滤操作只过滤测试通过的变更的变更信息，所以只要在变更管理系统中实现第二过滤操作，即可满足上述要求，换句话来说，实现了第二过滤操作的变更管理系统可以很好地支持测试与编译异步的场景。之所以需要这样实现的原因在于，基于持续集成系统之前获取到的变更信息所编译的若干个软件版本还未被自动化测试系统取走用于测试，所以必须将这些之前获取到的变更信息也包含到本次要编译的软件版本中，以确保每个变更都会被测试。

可以认为不存在测试频率高于编译频率的情况，因为测试最终还是要依赖于编译好的软件版本，如果编译未完成，自动化测试系统只能选择等待而无法提前进行测试。

进一步的，在测试与编译异步时，按照上面的做法，由于最新编译的软件版本中一定会包含之前所有编译好的、但尚未被自动化测试系统测试的软件版本中所包含的变更的集合，所以自动化测试系统一旦测试了该最新编译成功的软件版本，就相当于将之前因为测试频率较低而未能进行测试的中间版本也一并进行了测试，并没有逐个获取并测试这些中间版本的必要。因此在一些实现方式中，执行步骤S109时，自动化测试系统只需从持续集成系统获取最新编译成功的软件版本的存放路径用于测试即可，此举有利于跳过一些中间版本的测试，从而可以节约大量的自动化测试资源，使得很多企业在测试资源有限的条件下也可以正常开展变更级的CI构建。

当然，在测试资源充足时，将测试频率调整至与编译频率相同，对每个编译成功的软件版本都进行测试也未尝不可。

下面再举一个具体的例子说明测试与编译异步的情况下进行CI构建的流程，并结合图2进行说明，该例子中的一些设置延续自阐述图1之后所举的例子(如PA、PB进程的定义)。

步骤(1)至(6)和步骤(7)至(12)为异步关系，假设自动化测试资源较少，版本A测试时间长达70分钟，而步骤(1)至(6)完成一次编译大约需要20分钟，如图2所示，PA进程(对应横向第二个长箭头)针对开发人员提交上来的变更1-10进行编译，编译出有效版本A。PB进程(对应横向第三个长箭头)检测到存在需要进行自动化测试的新版本A，于是将A版本取走，开展自动化测试。

PA进程继续按照自己的工作频率进行第二次编译，针对开发人员刚刚提交上来的变更11-15，编译出了有效版本B。此时版本A的自动化测试仍然未结束，PA进程继续按照自己的工作频率进行第三次编译，此时发现又有开发人员新提交了变更16-22，这个版本将变更11-22一起编译，预期编译出版本C，但实际编译中因变更20涉及的代码文件存在错误导致版本C编译失败，持续集成系统通知变更管理系统变更20验证不通过，变更管理系统进而通知开发人员处理变更20的代码错误，并将变更20暂时排除在要集成的变更之外。

接着PA进程按照自己的工作频率开始第四次编译，本次开发人员又新提交了变更23-29，则本次将编译变更11-29，但在第四次编译中不包含问题变更20(因变更20目前还在由开发人员解决问题)，编译出有效版本D。

再过几分钟版本A的自动化测试结束了，自动化测试系统去持续集成系统查询，发现已经编译好了三个版本(B、C、D)，其中最近一个有效版本为D，于是从持续集成系统获取版本D的存放路径以及对应的包含的变更11-29(不含变更20)的变更信息，以便开展针对版本D的自动化测试工作。

这样，在变更级CI的构建过程中，通过将构建过程分阶段执行(编译阶段和测试阶段)、两阶段之间采用异步协同的方式有效节约了测试资源。各企业可以根据自己的服务器资源状况设置合理的PA进程的编译周期以及PB进程的测试周期。再结合前文提到的批量验证(指编译或测试)变更、精准定位问题所属的变更的措施，进一步节约了编译和自动化测试资源，使得变更级CI能够有效开展起来，将问题代码拦截在代码上库之前。

图3示出了本申请实施例提供的电子设备200的一种可能的结构。参照图3，电子设备200包括：处理器210、存储器220以及通信接口230，这些组件通过通信总线240和/或其他形式的连接机构(未示出)互连并相互通讯。

其中，存储器220包括一个或多个(图中仅示出一个)，其可以是，但不限于，随机存取存储器(Random Access Memory，简称RAM)，只读存储器(Read Only Memory，简称ROM)，可编程只读存储器(Programmable Read-Only Memory，简称PROM)，可擦除可编程只读存储器(Erasable Programmable Read-Only Memory，简称EPROM)，电可擦除可编程只读存储器(Electric Erasable Programmable Read-Only Memory，简称EEPROM)等。处理器210以及其他可能的组件可对存储器220进行访问，读和/或写其中的数据。

处理器210包括一个或多个(图中仅示出一个)，其可以是一种集成电路芯片，具有信号的处理能力。上述的处理器410可以是通用处理器，包括中央处理器(CentralProcessing Unit，简称CPU)、微控制单元(Micro Controller Unit，简称MCU)、网络处理器(Network Processor，简称NP)或者其他常规处理器；还可以是专用处理器，包括数字信号处理器(Digital Signal Processor,简称DSP)、专用集成电路(Application SpecificIntegrated Circuits，简称ASIC)、现场可编程门阵列(Field Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

通信接口230包括一个或多个(图中仅示出一个)，可以用于和其他设备进行直接或间接地通信，以便进行数据的交互。通信接口230可以包括进行有线和/或无线通信的接口。

在存储器220中可以存储一个或多个计算机程序指令，处理器210可以读取并运行这些计算机程序指令，以实现本申请实施例提供的持续集成方法以及其他期望的功能。

可以理解，图3所示的结构仅为示意，电子设备200还可以包括比图3中所示更多或者更少的组件，或者具有与图3所示不同的配置。图3中所示的各组件可以采用硬件、软件或其组合实现。电子设备200可能是实体设备，例如PC机、笔记本电脑、平板电脑、手机、服务器、嵌入式设备等，也可能是虚拟设备，例如虚拟机、虚拟化容器等。并且，电子设备200也不限于单台设备，也可以是多台设备的组合或者大量设备构成的集群。例如，若本申请实施例提供的持续集成方法由图1示出的软件开发系统执行，则该系统可部署在多台电子设备200上(不同的组件可以部署在不同的设备上)，每台电子设备200负责执行图1中方法的部分步骤。

本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被计算机的处理器读取并运行时，执行本申请实施例提供的持续集成方法。例如，计算机可读存储介质可以实现为图3中电子设备200中的存储器220。

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种持续集成方法，其特征在于，包括：

持续集成系统从变更管理系统获取变更信息，根据获取到的变更信息分配编译机，并向分配好的编译机发送所述变更信息；

所述编译机根据所述变更信息从代码库下载最新的代码，将变更的代码文件合并入下载的代码中，并对合并后的代码进行编译；其中，所述变更信息包括变更的代码文件；

所述编译机将编译成功的软件版本上传至版本服务器保存，并向所述持续集成系统发送该软件版本在所述版本服务器上的存放路径；

自动化测试系统从所述持续集成系统获取待测试的软件版本的存放路径，根据所述存放路径从所述版本服务器获取对应的软件版本，将该软件版本部署到分配好的自动化测试设备上进行测试，并向所述持续集成系统发送该软件版本对应的变更的测试结果；

所述持续集成系统在变更的测试结果为测试通过时，通知所述变更管理系统记录变更的测试结果并将变更的代码文件上传至所述代码库。

2.根据权利要求1所述的持续集成方法，其特征在于，所述变更信息还包括变更标识、变更对应的代码分支以及变更对应的产品；

所述持续集成系统根据获取到的变更信息分配编译机，包括：

所述持续集成系统根据变更对应的代码分支以及变更对应的产品分配编译机；

所述编译机根据所述变更信息从代码库下载最新的代码，包括：

所述编译机根据变更对应的代码分支以及变更对应的产品从代码库下载最新的代码。

3.根据权利要求1所述的持续集成方法，其特征在于，所述持续集成系统从变更管理系统获取变更信息，包括：

所述持续集成系统轮询待执行持续集成的项目清单，获取当前待执行项目，并从所述变更管理系统提取与所述当前待执行项目对应的变更信息，所述对应的变更信息为所述变更管理系统执行过滤操作后的变更信息；

其中，所述过滤操作包括第一过滤操作和/或第二过滤操作，所述第一过滤操作是指，判断所述当前待执行项目对应的变更中是否存在有变更间依赖关系的变更，若存在，则判断存在变更间依赖关系的变更所依赖的变更的变更信息在所述变更管理系统中是否完整，若不完整，则过滤掉该存在有变更间依赖关系的变更的变更信息；

所述第二过滤操作是指过滤掉所述当前待执行项目对应的变更信息中测试通过的变更的变更信息。

4.根据权利要求1所述的持续集成方法，其特征在于，在所述编译机对合并后的代码进行编译之后，所述方法还包括：

所述编译机向所述持续集成系统发送编译结果；

所述持续集成系统在所述编译结果为编译失败时，根据所述编译结果中有关导致编译失败的代码文件的信息确定编译失败的变更，并将有关编译失败的变更的信息通知所述变更管理系统，所述变更管理系统将有关编译失败的变更的信息通知用户；或者，

所述持续集成系统向所述变更管理系统发送所述编译结果，所述变更管理系统在所述编译结果为编译失败时，根据所述编译结果中有关导致编译失败的代码文件的信息确定编译失败的变更，并将有关编译失败的变更的信息通知用户。

5.根据权利要求1-4中任一项所述的持续集成方法，其特征在于，所述方法还包括：

所述持续集成系统在变更的测试结果为测试未通过时，将测试未通过的变更的信息通知所述变更管理系统。

6.一种持续集成方法，其特征在于，包括：

持续集成系统从变更管理系统获取变更信息，根据获取到的变更信息分配编译机，并向分配好的编译机发送所述变更信息；

所述编译机根据所述变更信息从代码库下载最新的代码，将变更的代码文件合并入下载的代码中，对合并后的代码进行编译，并向所述持续集成系统发送编译结果；其中，所述变更信息包括变更的代码文件；

所述持续集成系统在所述编译结果为编译成功时，通知所述变更管理系统将变更的代码文件上传至所述代码库；

所述编译机将编译成功的软件版本上传至版本服务器保存，并向所述持续集成系统发送该软件版本在所述版本服务器上的存放路径；

自动化测试系统从所述持续集成系统获取待测试的软件版本的存放路径，根据所述存放路径从所述版本服务器获取对应的软件版本，并将该软件版本部署到分配好的自动化测试设备上进行测试。

7.一种软件开发系统，其特征在于，包括：代码库、变更管理系统、持续集成系统、编译机、版本服务器以及自动化测试系统；

其中，所述持续集成系统用于从所述变更管理系统获取包括变更的代码文件在内的变更信息，根据获取到的变更信息分配所述编译机，并向分配好的所述编译机发送所述变更信息，以及用于接收所述自动化测试系统发送的变更的测试结果，并在变更的测试结果为测试通过时，通知所述变更管理系统记录变更的测试结果并将变更的代码文件上传至所述代码库；

所述编译机用于根据所述变更信息从所述代码库下载最新的代码，将变更的代码文件合并入下载的代码中，并对合并后的代码进行编译，以及用于将编译成功的软件版本上传至所述版本服务器保存，并向所述持续集成系统发送该软件版本在所述版本服务器上的存放路径；

所述自动化测试系统用于从所述持续集成系统获取待测试的软件版本的存放路径，根据所述存放路径从所述版本服务器获取对应的软件版本，将该软件版本部署到分配好的所述自动化测试设备上进行测试，并向所述持续集成系统发送该软件版本对应的变更的测试结果。

8.根据权利要求7所述的软件开发系统，其特征在于，所述变更信息还包括变更标识、变更对应的代码分支以及变更对应的产品；

所述持续集成系统用于根据获取到的变更信息分配所述编译机，包括：所述持续集成系统用于根据变更对应的代码分支以及变更对应的产品分配所述编译机；

所述编译机用于根据所述变更信息从代码库下载最新的代码，包括：所述编译机用于根据变更对应的代码分支以及变更对应的产品从代码库下载最新的代码。

9.根据权利要求7所述的软件开发系统，其特征在于，所述持续集成系统用于从变更管理系统获取包括变更的代码文件在内的变更信息，包括：

所述持续集成系统用于轮询待执行持续集成的项目清单，获取当前待执行项目，并从所述变更管理系统提取与所述当前待执行项目对应的变更信息，所述对应的变更信息为所述变更管理系统执行过滤操作后的变更信息；

其中，所述过滤操作包括第一过滤操作和/或第二过滤操作，所述第一过滤操作是指，判断所述当前待执行项目对应的变更中是否存在有变更间依赖关系的变更，若存在，则判断存在变更间依赖关系的变更所依赖的变更的变更信息在所述变更管理系统中是否完整，若不完整，则过滤掉该存在有变更间依赖关系的变更的变更信息；

所述第二过滤操作是指过滤掉所述当前待执行项目对应的变更信息中测试通过的变更的变更信息。

10.一种软件开发系统，其特征在于，包括：代码库、变更管理系统、持续集成系统、编译机、版本服务器以及自动化测试系统；

其中，所述持续集成系统用于从所述变更管理系统获取包括变更的代码文件在内的变更信息，根据获取到的变更信息分配所述编译机，并向分配好的所述编译机发送所述变更信息，以及用于接收所述编译机发送的编译结果，并在所述编译结果为编译成功时，通知所述变更管理系统将变更的代码文件上传至所述代码库；

所述编译机用于根据所述变更信息从所述代码库下载最新的代码，将变更的代码文件合并入下载的代码中，对合并后的代码进行编译，并向所述持续集成系统发送所述编译结果，以及用于将编译成功的软件版本上传至所述版本服务器保存，并向所述持续集成系统发送该软件版本在所述版本服务器上的存放路径；

所述自动化测试系统用于从所述持续集成系统获取待测试的软件版本的存放路径，根据所述存放路径从所述版本服务器获取对应的软件版本，并将该软件版本部署到分配好的所述自动化测试设备上进行测试。

Images