CN117724725A - 持续集成的自动化调度方法、装置、系统和存储介质 - Google Patents

Abstract

本申请涉及应用开发领域，提供了一种持续集成的自动化调度方法、装置、系统和存储介质，所述自动化调度方法包括：接收输入至第一服务器中的自动化调度指令，其中，第一服务器用于提供编写源码的工作环境；响应于自动化调度指令，根据预先配置的服务器启停机制，控制至少一个第二服务器中的每个第二服务器的启停状态，以从至少一个第二服务器中确定目标服务器；利用目标服务器，根据自动化调度指令对源码执行持续集成任务，其中，第二服务器用于为持续集成任务提供计算资源，持续集成任务至少包括编译任务。该方法能够减少开发所使用的第一服务器的资源消耗，降低卡顿风险，提升第一服务器的响应速度，提升开发效率。

Description

持续集成的自动化调度方法、装置、系统和存储介质

技术领域

本申请总体说来涉及应用开发领域，更具体地讲，涉及一种持续集成的自动化调度方法、装置、系统和存储介质。

背景技术

在利用持续集成开发EDA（Electronic Design Automation，电子设计自动化）工具时，需要利用云端服务器来提供开发工作环境，开发人员可在本地办公设备上通过VNC（Virtual Network Console，虚拟网络控制台）与云端服务器进行开发工作交互。

通常情况下，多个开发人员会共用一个云端服务器。由于持续集成过程中，开发人员需要频繁地执行持续集成任务，例如编译、测试、打包等，这些任务会大量占用开发工作所使用的云端服务器的资源，降低云端服务器的响应速度，对于共享同一台云端服务器的其他开发人员的开发工作造成负面影响。

发明内容

本申请提供一种持续集成的自动化调度方法和持续集成的自动化调度装置，用于至少解决持续集成过程中共享的开发服务器响应速度慢的问题。

根据本申请的一方面，提供一种持续集成的自动化调度方法，所述自动化调度方法应用于集成电路电子设计自动化软件开发，所述自动化调度方法包括：接收输入至第一服务器中的自动化调度指令，其中，所述第一服务器用于提供编写源码的工作环境；响应于所述自动化调度指令，根据预先配置的服务器启停机制，控制至少一个第二服务器中的每个第二服务器的启停状态，以从所述至少一个第二服务器中确定目标服务器；利用所述目标服务器，根据所述自动化调度指令对所述源码执行持续集成任务，其中，所述第二服务器用于为所述持续集成任务提供计算资源，所述持续集成任务至少包括编译任务。

根据本申请的另一方面，提供一种持续集成的自动化调度装置，所述持续集成的自动化调度装置包括：接收单元，被配置为接收输入至第一服务器中的自动化调度指令，其中，所述第一服务器用于提供编写源码的工作环境；确定单元，被配置为响应于所述自动化调度指令，根据预先配置的服务器启停机制，控制至少一个第二服务器中的每个第二服务器的启停状态，以从所述至少一个第二服务器中确定目标服务器；执行单元，被配置为利用所述目标服务器，根据所述自动化调度指令对所述源码执行持续集成任务，其中，所述第二服务器用于为所述持续集成任务提供计算资源，所述持续集成任务至少包括编译任务。

根据本申请的另一方面，提供一种计算机可读存储介质，当所述计算机可读存储介质中的指令被至少一个处理器运行时，促使所述至少一个处理器执行如上所述的持续集成的自动化调度方法。

根据本申请的另一方面，提供一种计算机设备，包括：至少一个处理器；至少一个存储计算机可执行指令的存储器，其中，所述计算机可执行指令在被所述至少一个处理器运行时，促使所述至少一个处理器执行如上所述的持续集成的自动化调度方法。

根据本申请的另一方面，提供一种计算机程序产品，包括计算机指令，当所述计算机指令被至少一个处理器运行时，促使所述至少一个处理器执行如上所述的持续集成的自动化调度方法。

根据本申请的另一方面，提供一种持续集成的自动化调度系统，所述自动化调度系统包括第一服务器和至少一个第二服务器，所述第一服务器包括如上所述的计算机设备。

根据本申请示例性实施例的持续集成的自动化调度方法、装置、系统和存储介质，通过配置自动化调度指令，将持续集成任务从开发所使用的第一服务器中抽离出来，自动化地调度第二服务器来单独执行相应任务，能够减少开发所使用的第一服务器的资源消耗，降低卡顿风险，提升第一服务器的响应速度。同时，抽离出来的往往是编译、测试、打包这类重复任务，可简化开发人员的手动操作，减少频繁重复任务对开发人员时间的占用，提升开发效率。

将在接下来的描述中部分阐述本申请总体构思另外的方面和/或优点，还有一部分通过描述将是清楚的，或者可以经过本申请总体构思的实施而得知。

附图说明

通过结合附图，从实施例的下面描述中，本申请这些和/或其它方面及优点将会变得清楚，并且更易于理解，其中：

图1是示出根据本申请示例性实施例的持续集成的自动化调度方法的流程图；

图2是示出根据本申请示例性实施例的任务调度总体流程的流程图；

图3是示出根据本申请示例性实施例的多人协作完成持续集成工作的架构示意图；

图4是示出根据本申请示例性实施例的不同持续集成任务的执行顺序示意图；

图5是示出根据本申请一个具体实施例的控制第二服务器的启停状态的总体流程的流程图；

图6是示出根据本申请示例性实施例的持续集成的自动化调度装置的框图；

图7是示出根据本申请示例性实施例的计算机设备的框图。

具体实施方式

提供参照附图的以下描述以帮助对由权利要求及其等同物限定的本发明的实施例的全面理解。包括各种特定细节以帮助理解，但这些细节仅被视为是示例性的。因此，本领域的普通技术人员将认识到在不脱离本发明的范围和精神的情况下，可对描述于此的实施例进行各种改变和修改。此外，为了清楚和简洁，省略对公知的功能和结构的描述。

在此需要说明的是，在本申请中出现的“若干项之中的至少一项”均表示包含“该若干项中的任意一项”、“该若干项中的任意多项的组合”、“该若干项的全体”这三类并列的情况。例如“包括A和B之中的至少一个”即包括如下三种并列的情况：（1）包括A；（2）包括B；（3）包括A和B。又例如“执行步骤一和步骤二之中的至少一个”，即表示如下三种并列的情况：（1）执行步骤一；（2）执行步骤二；（3）执行步骤一和步骤二。

EDA全称是Electronic Design Automation，也就是电子设计自动化，是指利用计算机辅助设计（Computer-Aided Design，CAD）软件，来完成超大规模集成电路（Very LargeScale Integration，VLSI）芯片的功能设计、综合、验证、物理设计（包括布局、布线、版图、设计规则检查等）等流程的设计方式。集成电路设计人员需要使用EDA工具设计几十万到数十亿晶体管的复杂集成电路，以减少设计偏差、提高流片成功率及节省流片费用。

C++（c plus plus，cpp）是一种计算机高级程序设计语言，可运行于多种平台上，如Windows、MAC操作系统以及UNIX的各种版本。相较于其他语言，C++语言更加灵活，可以在最高的抽象级别上运行，还可以在硅级低级别上运行，支持访问低级别硬件功能，从而最大限度地提高速度并最大程度地降低内存需求，具有高效的计算性能和直接控制硬件的能力，因此适用于EDA工具等大型工业软件的代码开发验证。

持续集成（Continuous integration，CI）是EDA工具开发流程中重要的组成部分，通过频繁地（例如一天多次）将代码集成到主干，有利于加快开发进度；通过持续自动化测试，可以快速发现和定位错误，节约时间；此外还易于定位项目进度，使项目更加透明。

为了实现EDA工具开发的持续集成，通常需要研发、测试等各团队之间进行多人协作，并且主要的开发工作需要在云端服务器完成。云端服务器是指服务于EDA开发项目（project）的云设备，例如AWS（Amazon Web Services，亚马逊云服务）设备，其通常内置Linux操作系统，是为开发人员提供开发工作环境的服务器，开发人员在本地办公设备上通过VNC与服务器进行开发工作交互。

例如，当所有开发工作均需要在AWS的VNC上完成时，因相对于运行命令行产生的资源消耗而言，运行桌面系统产生的资源消耗会大很多，同时考虑到每月的公有云消费，所以通常多人（例如3个人）同时使用一台8Core 32GB的AWS服务器。

这样的情况主要存在以下三个问题。

（1）持续集成的EDA工具开发场景要求开发人员频繁地执行C++代码的编译、测试、覆盖率统计、打包等操作，导致一些高频率的重复性工作占用开发人员大量的时间和精力，影响开发效率。

（2）多人同时使用一台资源有限的云端服务器，容易导致资源抢占的问题，尤其是当一名开发人员执行的操作（例如编译）需要重度使用资源时，会导致其当前使用的服务器变得很卡顿且容易死机，对使用同一台服务器的其他开发人员的工作有负面影响。

（3）C++编译存在资源消耗多、速度慢、影响范围大的特点，随着C++项目的持续扩大，团队整体的编译效率越来越低。

根据本申请示例性实施例的持续集成的自动化调度方法、装置、系统和存储介质，通过配置自动化调度指令，将持续集成任务从开发所使用的第一服务器中抽离出来，自动化地调度第二服务器来单独执行相应任务，能够减少开发所使用的第一服务器的资源消耗，降低卡顿风险，提升第一服务器的响应速度。同时，抽离出来的往往是编译、测试、打包这类重复任务，可简化开发人员的手动操作，减少频繁重复任务对开发人员时间的占用，提升开发效率。

下面参照图1至图7详细描述根据本申请示例性实施例的持续集成的自动化调度方法、装置、系统。

图1是示出根据本申请示例性实施例的持续集成的自动化调度方法的流程图。根据本申请示例性实施例的持续集成的自动化调度方法可以在具有足够运算能力的计算机设备中实现，具体可以是在第一服务器中实现，为此，可将实现该方法所需的计算机程序/计算机指令整合为专门的自动化调度工具（以下称为enmake工具），并将enmake工具安装到第一服务器上，以使第一服务器实现该方法。

参照图1，在步骤S101中，接收输入至第一服务器中的自动化调度指令。

其中，第一服务器用于提供编写源码的工作环境。自动化调度指令用于调度第一服务器以外的其他服务器来执行持续集成任务。参考前文可知，作为示例，开发人员可在本地办公设备上通过VNC向第一服务器发送自动化调度指令。

在步骤S102中，响应于自动化调度指令，根据预先配置的服务器启停机制，控制至少一个第二服务器中的每个第二服务器的启停状态，以从至少一个第二服务器中确定目标服务器。

自动化调度指令例如可称为enmake指令，并具体由安装在第一服务器上的enmake工具来响应。

在步骤S103中，利用目标服务器，根据自动化调度指令对源码执行持续集成任务。

第二服务器用于为持续集成任务提供计算资源，应理解，目标服务器是全部第二服务器中被确定用于执行当前持续集成任务的一个第二服务器，因此属于相对概念，对于某个持续集成任务而言作为目标服务器的第二服务器，对于其他持续集成任务而言可能是目标服务器，也可能不是目标服务器。

持续集成任务至少包括编译任务，编译就是把用高级语言编写的代码（即此处的源码）变成计算机可以识别的二进制文件。

作为示例，enmake工具可使用Jenkins API（Application ProgrammingInterface，应用程序编程接口）来调度任务运行。Jenkins是一个持续集成管理工具，可以跨平台运行，提供持续集成和持续交付服务，用于监控持续重复的工作，能够自动化EDA工具开发流程中的构建、测试和部署等工作，但仅具备基本的调度服务器执行任务的功能，具体如何调度需根据实际场景做进一步扩充。enmake工具控制每个第二服务器的启停状态之后，由Jenkins从启动的第二服务器中确定目标服务器。

cmake（cross platform make）是一个跨平台构建（编译）工具，支持用简单的语句来描述所有平台的编译过程，可用作执行编译任务的底层工具。cmake的所有语句都写在CMakeLists.txt文件中，使用cmake工具的基本操作流程如下：

其中，directory为CMakeLists.txt所在目录；语句①用于配置编译选项，一般不需要配置（除非出现错误），直接执行语句②即可；语句②用于根据CMakeLists.txt生成Makefile文件；语句③用于执行Makefile文件，编译相关代码，生成可执行文件。

enmake工具使用Jenkins API来调度任务运行时，首先会获取当前源码目录下的cmake传参，如果本次运行没有cmake传参，则会读取当前开发项目下的“.old_cmake_params”文件获取历史cmake参数，但如果传递了新的cmake参数，则会用新的cmake参数替换旧的cmake参数，如果既没有新的传参也没有历史参数，则会报错。

这里需说明的是，关于目录，在Linux操作系统中，所有的文件和目录都被组织成以一个根节点“/”开始的树状结构，目录就相当于Windows或MAC中的文件夹，目录中存放的既可以是文件，也可以是其他的子目录。

关于开发项目，是指开发EDA工具的项目。开发项目、工作、任务的层级由上至下为：project（开发项目）→job（工作）→task（任务），即一个project可能包括多个job，一个job指某些task的集合，从而一个job通常包括多个task，一个task指一个持续集成任务，不同task对应不同的构建阶段，例如编译、打包等。这属于程序开发的基本架构。

基于以上示例性内容，利用enmake工具进行任务调度的总体流程可如图2所示。

在步骤S201中，接收自动化调度指令。

开发人员通过VNC连接云端的第一服务器，在服务器的终端工具（例如Terminal）输入自动化调度指令（可记为enmake指令），以发起本次持续集成任务（task）。

在步骤S202中，确定正在运行的任务数量。

安装于第一服务器上的enmake工具响应于enmake指令，确定当前job下正在运行的task数量。enmake工具例如可通过API询问Jenkins当前有多少个正在运行的task，Jenkins返回正在运行的task数量。

多个开发人员（例如图3中的A、B、C）可分别通过自动化调度工具针对同一个工作（job）发起各自的任务（task），例如图3中分别与A、B、C对应的任务A、任务B、任务C，以实现高效的多人协作。

在步骤S203中，确定运行本次任务的目标服务器。

enmake工具根据当前job下正在运行的task数量，在预先指定服务于当前job的云端服务器中（具体是第二服务器中），确定用于运行本次task的目标服务器。步骤S202和步骤S203共同对应于图1中的步骤S102。

对于步骤S203，具体来说，一个project下可能部署有多台云端服务器，每台云端服务器也称作节点（node），开发人员通过VNC与一台服务器进行开发工作交互，该服务器即为第一服务器，而将资源负荷较重的任务（例如编译）调度至其他服务器（即目标服务器）上运行，相当于将这些资源负荷较重的任务从开发人员的工作环境中抽离出来。

在为project部署的多台云端服务器中，包括一台主服务器（master服务器）和至少一台从属服务器（slave服务器，作为第二服务器）。其中，master服务器主要负责任务的调度，不负责运行任务，其上部署有Jenkins主程序；slave服务器则只负责运行任务。当然，还包括至少一个用于提供工作环境的第一服务器。

安装在master服务器上的Jenkins通过SSH（Secure Shell，安全外壳协议）将“remoting.jar”文件拷贝到相应的slave服务器，然后slave服务器会依托这个文件运行一个java进程，通过这个进程和master服务器进行通信，执行相应task。

在步骤S204中，执行自动化调度参数映射，以触发任务流程。

enmake工具确定本次task的自动化调度参数（可记为enmake参数），并将enmake参数映射给Jenkins，以使Jenkins根据enmake参数在目标服务器上触发与task相关的pipeline。enmake参数主要包括cmake参数、节点名称、源码路径、测例路径（测例又称为测试用例或Test Case，简称case，是针对某项特定软件产品而编制的一组内容输入、运行条件和期望结果的集合，以便核查软件的某个功能需求是否达到预期目标）、是否打包等。

关于cmake参数的获取，若enmake指令中指定了新的cmake参数，则获取新指定的cmake参数，并将新指定的cmake参数缓存至当前工作目录下的一个隐藏文件（例如“.old_cmake_params”文件）中；若enmake指令中没有指定新的cmake参数，则读取当前工作目录下的“.old_cmake_params”文件，获取文件中的历史cmake参数；若既没有指定新的cmake参数，也无法获取历史cmake参数，则会报错。

关于enmake参数的映射，enmake工具将获取的cmake参数赋值给一个变量，然后和其他参数（节点名称、源码路径、测例路径、是否打包等）变量汇总成一个字典，再将这个字典传递给Jenkins。Jenkins对接收的字典进行解析来获取对应的各个变量的值，然后将这些变量传递给pipeline去执行。

pipeline是一套Jenkins官方提供的插件，可以用来在Jenkins中实现和集成持续交付的流水线。自动化执行任务的pipeline脚本内容通常由开发人员编辑并保存在本地git仓库目录下的jenkinsfile文件中，以供Jenkins调用。pipeline都是固定的一些执行步骤，即不同task的pipeline总体流程都是一样的，只是不同task的pipeline根据各自的enmake参数执行各自的任务，可能会在某个（或某几个）步骤的具体执行上有所差异，例如，cmake参数主要负责代码的编译行为，而编译只是pipeline中的其中一个步骤，cmake参数只会影响该步骤的具体执行。

下面对本申请示例性实施例的持续集成的自动化调度方法做进一步介绍。

关于自动化调度指令，从指令形式上来说，可选地，自动化调度指令包括完整指令、部分缺省指令和完全缺省指令。完整指令包括头指令、相对应的任务键指令和任务值指令，头指令用于表示当前指令的属性是自动化调度指令，任务键指令用于表示持续集成任务的类型，任务值指令用于表示相应持续集成任务的执行参数，完整指令用于表示按照任务值指令表示的执行参数执行相对应的任务键指令表示的类型的持续集成任务；部分缺省指令包括头指令、相对应的任务键指令和缺省任务值指令，缺省任务值指令用于表示相应持续集成任务的执行参数为默认参数，部分缺省指令用于表示按照默认参数执行相对应的任务键指令表示的类型的持续集成任务；完全缺省指令包括头指令，完全缺省指令用于表示针对默认源码目录使用默认参数执行编译任务。应理解，除了完全缺省指令的内容是完全明确的以外，完整指令和部分缺省指令都涉及具体的任务键指令，因此即使是针对同一源码（通常属于同一job），在执行不同的持续集成任务时，自动化调度指令的形式也可能有所不同。例如，针对任务X，若自动化调度指令中包括任务值指令，则属于完整指令；针对任务Y，若自动化调度指令中包括缺省任务值指令，则属于部分缺省指令。

作为示例，为便于编写指令，对于针对同一源码的多个持续集成任务（通常是同一job的多个task），可合并成一个自动化调度指令，共用头指令，后续部分则按需编写；当然也可以拆分为多个自动化调度指令，每个自动化调度指令对应于一个持续集成任务。这都是本申请的实现方式，落入本申请的保护范围之内。对于前者，可按照构建阶段的顺序逐个执行自动化调度指令中的各项持续集成任务，对于后者，可以在接收到某项持续集成任务的自动化调度指令后再执行相应任务，但同一job中首次执行持续集成任务时须执行编译任务，后续任务则可直接使用编译结果，无需再次执行编译任务（当然也可设置为再次执行编译任务，这同样是本申请的实现方式），这意味着可以待编译任务执行结束后间隔一段时间再执行其他持续集成任务。

根据自动化指令中信息量的多少，结合默认参数，本申请示例性实施例配置了三种不同形式的自动化调度指令。三种形式的自动化调度指令中都包括的头指令能够明确指示当前指令的属性，保障了指令的可靠传递。持续集成任务中最基础的任务是编译任务。通过配置完全缺省指令，能够用尽量小的信息量表示最基础的任务，即按照默认参数对默认源码目录执行编译任务，有助于简化指令的编写，并有助于提高信息传递效率。通过配置内容完善的完整指令，指令中相对应的任务键指令和任务值指令能够为特定的持续集成任务类型提供明确的执行参数，有助于实现全面的信息传递。通过配置部分缺省指令，能够为基础任务以外的其他持续集成任务配置默认参数，从而按需配置任务键指令，并相对于完整指令而言简化任务值指令的编写，从而适当简化指令编写。通过配置以上三种形式的自动化调度指令，能够在指令形式的数量和指令的编写内容量之间找到平衡，既保障指令形式的数量足够少，便于开发人员记忆，又保障指令形式足够多，能够采用合适的指令形式来减少单个指令的编写内容量，从而综合提升了自动化调度指令的编写效率和信息传递效率。

从任务类型上来说，可选地，任务键指令包括以下至少一个：源码指令、编译指令、测试指令、覆盖率统计指令、打包指令，其中，源码指令对应的任务值指令包括源码目录的路径名称，编译指令对应的任务值指令包括编译参数（例如上文介绍的cmake参数），测试指令对应的任务值指令包括测例的路径名称，覆盖率统计指令对应的任务值指令包括保存目录或保存文件的路径名称，打包指令对应的任务值指令包括是否打包。通过针对源码的确定、编译任务、测试任务、覆盖率统计任务、打包任务配置相应的任务键指令和任务值指令，能够对不同类型的持续集成任务配置执行所需的参数，保障了各类持续集成任务的可靠执行。应理解，由于源码是持续集成任务的集成对象，所以在执行持续集成任务前必然还需要确定源码，因此可将指示源码的源码指令也作为一个任务键指令，并将确定源码视为一个前期准备任务。对于其他任务，具体地，测试是在源码编译完成后，通过运行测例来了解源码能否正确运行，进而了解当前对代码的更改是否有问题，并及时检查出问题在哪里，同时，为了节约时间，还可以只运行单个测例或一组测例。覆盖率是度量测试完整性的一个手段，是测试有效性的一个度量，通过运行测试用例，工具记录统计软件各行代码被执行的情况，用于可靠性、稳定性以及性能的评测。覆盖率统计可以通过诸如语句覆盖率、分支覆盖率、条件覆盖率、路径覆盖率、数据流覆盖率等指标进行评估，在不同场景下所使用的具体指标往往有所不同。其中，语句覆盖率用于衡量代码中被执行过的语句所占比例，分支覆盖率用于衡量if、switch等代码中每个分支被执行过的次数，条件覆盖率用于衡量每个if语句中每个条件语句被执行过的次数，路径覆盖率用于衡量所有代码路径是否都被执行过，数据流覆盖率用于衡量程序中所有数据定义和引用之间的依赖关系是否都经过了测试。覆盖率统计需要在运行完测例后执行，会将覆盖率结果写入每个开发人员对应的目录，方便开发人员通过浏览器进行查看。打包是将编译结果文件（即二进制文件）和支持其运行所需的文件合并成一个文件，从而对外只需传输一个文件。

其中，从各类任务的执行上来说，针对确定源码的任务，可选地，步骤S103包括：利用目标服务器，在自动化调度指令中包括源码指令和源码目录的路径名称的情况下，根据源码目录的路径名称确定当前源码；在自动化调度指令中不包括源码指令和源码目录的路径名称的情况下，确定当前目录下的源码作为当前源码。通过配置源码指令和相应任务值指令（即源码目录的路径名称），能够供开发人员按需选择源码目录，保障了任务执行的需要。此外，由于自动化调度指令需要在某个目录下输入，而开发人员通常是在完成一部分代码编写后随即启动自动化调度工具，以执行持续集成任务，因此通常会在当前项目的根目录下输入自动化调度指令，而编译任务所针对的源码目录刚好须为项目的根目录（因为需要将项目中已编写的主干代码和新编写的代码一起作为源码来编译，而不能仅编译部分代码），因此当前目录（当前输入自动化调度指令的目录）大概率就是所需的源码目录。通过将当前目录作为默认源码目录，能够令默认源码目录的设置合理，提高开发人员对默认源码目录的使用率，减少开发人员输入源码目录的路径名称的操作，从而能够有效地简化指令编写，并有效提升自动化调度指令的编写效率和信息传递效率。可以理解，若开发人员是在其他目录下输入自动化调度指令，则可以通过输入源码指令和源码目录的路径名称来进行指定源码目录。作为示例，为保障源码的可靠确定，还可以配置提示信息，在识别到当前目录不是当前项目的根目录时输出提示信息，以提示开发人员指定源码目录。此外，考虑到确定源码的任务属于必须执行的基础任务，通过将自动化调度指令配置为不包括源码指令和源码目录的路径名称的情况下采用上述默认源码目录，则不必写入源码指令，能够进一步简化指令编写。

针对编译任务，可选地，步骤S103包括：利用目标服务器，在自动化调度指令中包括编译指令和编译参数的情况下，提取编译参数作为当前编译参数，在自动化调度指令中不包括编译指令和编译参数的情况下，若获取到当前目录下的历史编译参数，则将历史编译参数作为当前编译参数，并根据当前编译参数对当前源码执行编译任务，得到编译结果文件，若未获取到当前目录下的历史编译参数，则输出报警信息。在配置编译指令和编译参数，以便开发人员明确输入编译参数的基础上，考虑到不同project所需的编译参数可能有所不同，不便于统一配置固定的编译参数，而同一project的不同job的编译参数则可能相同，尤其是相接近的两次job，通过将当前目录下的历史编译参数作为编译任务的默认参数，能够保障该默认参数大概率就是开发人员计划使用的编译参数，实现了编译任务的默认参数的合理设置，与上文中默认源码目录的设置类似，可有效地简化指令编写，并有效提升自动化调度指令的编写效率和信息传递效率。同时，考虑到和确定源码的任务一样，编译任务也属于必须执行的基础任务，通过将自动化调度指令配置为不包括编译指令和编译参数的情况下采用默认参数来执行编译任务，则不必写入编译指令，能够进一步简化指令编写。此外，通过配置报警信息，能够在无法获取到历史编译参数时及时提醒开发人员修改指令，输入编码参数，从而保障了编译任务的可靠执行。

针对测试任务、覆盖率统计任务和打包任务，可选地，步骤S103包括：利用目标服务器，在自动化调度指令中不包括测试指令、覆盖率统计指令和打包指令中的任意一个的情况下，不执行相应类型的任务；利用目标服务器，在自动化调度指令中包括测试指令的情况下，若自动化调度指令还包括默认测例指令，则将默认测例指令对应的默认测例作为当前测例，若自动化调度指令还包括测例的路径名称，则根据测例的路径名称确定当前测例，并使用当前测例对源码的编译结果文件执行测试任务。针对非基础任务，通过配置为在不包括相应任务键指令时不执行相应类型的任务，能够减少不必要的指令输入。具体针对测试任务，通过配置默认测例指令作为测试指令对应的缺省任务值指令，能够实现当前测例的默认选用，有助于简化测试任务相关的指令编写。同时配置前述的测例的路径名称作为任务值指令，可供开发人员按需修改测例，满足了不同的测试需求，保障了测试任务的可靠执行。

关于自动化调度指令，总体来说，仍以上文中关于enmake工具的示例为例，完全缺省的enmake指令可写为“ enmake ”，相当于enmake指令中必需的部分，即头指令，仅用于针对当前目录使用历史cmake参数进行编译。

针对测试任务的部分缺省enmake指令可写为“ enmake -T all ”，其中“-T”为测试指令，“all”为默认测例指令，各个指令用空格隔开，该指令表示针对当前目录使用历史cmake参数进行编译，并运行默认的所有测例。

一个完整的enmake指令示例为“ enmake -S "/home/XXX/project" -C "-DCMAKE_BUILD_TYPE=Debug -DBUILD_UPF=ON" -T "reg/upf" -F "reg/upf" -I "ture"”，该指令将同一job的不同task合并于一个enmake指令。

其中，“ -S "/home/XXX/project" ”用于指定源码目录，“-S”为源码指令，“ "/home/XXX/project" ”为源码目录的路径名称。若enmake指令中没有源码指令，当然也没有相应的源码目录的路径名称，即不指定源码目录，则默认将当前目录作为源码目录，将当前目录下的源码作为当前源码。

“ -C "-DCMAKE_BUILD_TYPE=Debug -DBUILD_UPF=ON" ”用于指定cmake参数，并将指定的cmake参数缓存到当前目录的一个隐藏文件中，以与代码文件相区分，便于查看和管理代码文件，并降低cmake参数被误删的风险。其中，“-C”为编译指令，“ "-DCMAKE_BUILD_TYPE=Debug -DBUILD_UPF=ON" ”为指定的cmake参数。若enmake指令中没有编译指令，当然也没有相应的cmake参数，即不指定cmake参数，则默认自动读取当前目录的隐藏文件中的历史cmake参数。

“ -T "reg/upf" ”用于指定测例的参数，通常指定目录或文件，“-T”为测试指令，“ "reg/upf" ”为测例的路径名称。若enmake指令中没有测试指令，当然也没有相应的测例路径名称，即不指定测例，就默认不进行测试，例如可适用于仅对少量代码进行修改的情况，此时无需测试。测试指令有两种用法，一种是“ -T all ”，用于指定当前目录下的所有测例；另一种是“ -T "…" ”，用于指定多个路径下的多个测例，各个路径名称之间以空格分隔，并用双引号（""）引用；若其中任一路径名称是错误的，则会报错。

“ -F "reg/upf" ”用于指定覆盖率统计的参数，通常指定目录或文件，“-F”为覆盖率统计指令，“ "reg/upf" ”为保存目录或保存文件的路径名称。如果涉及多个测例，则以空格分隔，并用双引号（""）引用。若enmake指令中没有覆盖率统计指令，当然也没有相应的保存目录或保存文件的路径名称，即不指定覆盖率统计的参数，就默认不统计覆盖率。覆盖率统计通常没有默认的保存路径。

“ -I "ture" ”用于指定编译（或测试）后是否打包，“-I”为打包指令，“ "ture" ”是对应的任务值指令，表示打包，也可以用“ "false" ”表示不打包。若无打包指令，当然也无相应的任务值指令，即不指定是否打包，则默认不打包。

综上，enmake指令中的“-S”、“-C”、“-T”、“-F”、“-I”作为任务键指令（key），双引号"…"部分作为任务值指令（value），若在enmake指令中加了key，而没有相应双引号部分的value，例如“ enmake -S -C -T ”，则会报错，从而实现enmake指令的统一管理。其中，如图4所示，各个类型的持续集成任务在时间上存在先后依赖关系，确定源码任务（如前所述，源码是持续集成的对象，可以视为一个前期准备任务，所以严格来说不属于持续集成任务，故图4中予以省略）和编译任务是基础的任务，必然执行，在图4中用实线表示。通过不输入“-S”或“-C”，可以指定默认的源码目录或默认的cmake参数。测试任务、覆盖率统计任务、打包任务是附加任务，可以选择是否执行，在图4中用虚线表示，并且存在如图4所示的先后依赖关系。通过不输入“-T”、“-F”或“-I”，可以表示不执行相应任务。对于打包任务，不输入“-I”相当于默认不执行打包；对于测试任务，通过输入“ -T all ”可以指定默认测例。

关于数据的存储，可选地，源码目录为共享目录；和/或，本申请示例性实施例的持续集成的自动化调度方法还包括：将源码的编译结果文件保存至编译结果目录，编译结果目录为共享目录。一个项目的代码开发往往需要多个开发人员合作进行，通过将存储源码的源码目录和存储编译结果文件的编译结果目录中的至少一个配置为共享目录，能够实现代码和/或编译结果文件的统一存储和管理，使得项目中不同的开发人员能够同步获取到当前最新的代码和/或编译结果文件，保障了项目开发的可靠性。相应地，在为项目部署的多台云端服务器中还包括存储源码和/或编译结果文件的存储服务器，并且源码和编译结果文件可以存储在同一存储服务器或不同的存储服务器上。

可选地，目标服务器使用编译器缓存，其中，编译器缓存为共享缓存。相关技术中存在使用编译器缓存来辅助编译，并将编译器缓存放到目标服务器上的布置方式，这样的方式虽然能够加快目标服务器的编译速度，但是需要在目标服务器上为编译器缓存指定目录，而由于云端服务器上的目录经常发生变化，所以即使当前确定的目标服务器上曾经指定过编译器缓存目录，也可能因为目录失效而需要重新指定，并且编译器缓存本身常常会由于时效性不高（例如原有缓存数据是几天前的）而失去缓存效果，导致拖慢编译进度。通过将编译器缓存配置为共享缓存，能够为当前项目整体的编译构建提供统一的编译器缓存，节约了每次指定编译器缓存目录所花费的时间，提高了编译器缓存的时效性，每次获取的编译器缓存都是最近一次编译时缓存的数据，进一步加快了编译速度。相应地，在为项目部署的多台云端服务器中还包括实现共享的编译器缓存的存储服务器，该存储服务器需具备足够大的资源，从而能够将编译器缓存集中落盘在资源足够大的存储服务器上。

作为示例，ccache（compiler cache）是一个编译器缓存，该工具会高速缓存编译生成的信息，并在编译的特定部分使用高速缓存的信息，比如头文件，从而节省通常使用C++解析这些信息所需要的时间。如果某头文件中包含对其他头文件的引用，ccache会用那个文件的编译结果来取代include声明，此时ccache不是真正去读取、理解并解释该头文件的内容，而只是将最终的编译结果拷贝到文件中，使得这部分内容可以立即被编译。ccache是以空间换取速度，非常适合经常make clean（或删除out目录）后重新编译的情况。

NFS（Network File System）即网络文件系统，它允许网络中的计算机之间通过TCP/IP网络共享资源。将NFS主机分享的目录，挂载到本地客户端当中，本地NFS的客户端应用可以读写位于远端NFS服务器上的文件，在客户端看起来，就像访问本地文件一样。

ccache缓存（例如，200G）为加速C++编译进度起到了很大的作用，通过将ccache缓存切换到NFS上，为整体的编译构建提供统一的ccache缓存，进一步加快了编译的速度。具体地，可将NFS挂载到每个新启动的服务器，这样每次编译都是拥有ccache缓存的，如果第一次编译或测试没通过，第二次编译的时候将节约大概14分钟的编译时间，大大加快代码合并的速度，同时对enmake工具来说也会非常适用，因为编译时大多数情况只改了小部分代码，在全局ccache的支持下，从原来的16分钟，缩短为全程只需要1分钟就能完成一次编译，同时也加快了代码开发验证的速度，提供了工作效率。

关于测试任务，可选地，任务键指令包括大测例测试指令，大测例测试指令用于表示所需内存容量超过预设内存容量的测试任务，对应着对内存容量要求较高的测试任务。相应地，本申请示例性实施例的持续集成的自动化调度方法还包括：根据大测例测试指令，从至少一个第三服务器中确定测试服务器，其中，第三服务器的内存容量大于第二服务器的内存容量以及预设内存容量；利用测试服务器，根据大测例测试指令对源码的编译结果文件执行测试任务。前面介绍的测试属于普通测试，实践中还存在大测例测试，大测例测试需要很多内存和计算资源，可能在目标服务器资源不够时导致目标服务器直接宕机，影响测试进度。通过针对特殊的大测例测试任务，另外确定内存容量足够大的第三服务器来执行测试任务，一方面能够有效满足测试需求，充分降低任务执行过程中出现内存不够、服务器不可用的风险，提高了持续集成任务的执行可靠性；另一方面，大测例测试可能会对环境产生破坏性影响，通过从常规使用的第二服务器之外的第三服务器中确定测试服务器，能够降低对其他服务器上的任务执行的影响。

可选地，根据本申请示例性实施例的持续集成的自动化调度方法还包括：将测试服务器作为目标服务器。通过在自动化调度指令中包括大测例测试指令时，将针对大测例测试任务确定的测试服务器作为执行当前持续集成任务的目标服务器，能够在还涉及其他类型的任务时，将整个持续集成任务全部交由一个服务器（即测试服务器）来执行，使得执行不同任务时相关数据不必在多个不同服务器之间反复传输，能够充分降低因数据传输引起的延迟和数据误传风险，提高了持续集成任务的执行可靠性。应理解，此时就不再从第二服务器中确定目标服务器。

可选地，步骤S103包括：接收输入至第一服务器中的测试参数和/或测试命令；向测试服务器发送测试参数和/或测试命令，以使测试服务器根据大测例测试指令以及测试参数和/或测试命令对源码的编译结果文件执行测试任务。测试任务通常是自动化执行的，以确保新提交的代码更改不会破坏现有的功能。而大测例测试往往是为了验证软件在处理大量数据或高负载情况下的性能和稳定性，因而相较于普通测试，常存在一些特殊的需求，例如数据集准备（可能需要特定的大型数据集来进行测试，这些数据集可能需要特别的准备和配置）、安全性考虑（如果测试数据包含敏感信息，需要确保在测试过程中保护这些数据的安全）、特定的配置（某些测试可能需要不同于常规的特殊配置，比如数据库的特定设置或者应用服务器的特定参数）、手动干预（在某些情况下，可能需要人工干预来模拟某些操作或响应测试过程中产生的问题）。通过将本申请示例性实施例的方法配置为可接收开发人员输入至第一服务器的测试参数和测试命令中的至少一个，并据此控制测试服务器的大测例测试任务的执行，能够在存在特殊需求时直接进入对应的测试服务器，实现测试服务器的手动控制，从而手动运行对应的大测例，保障了大测例测试任务的顺利执行。

可选地，根据本申请示例性实施例的持续集成的自动化调度方法还包括：在满足预设结束条件的情况下，释放测试服务器的资源，以停止执行测试任务。大测例测试任务需要占用较多的资源，通过配置预设结束条件以触发自动释放测试服务器的资源，能够及时解除大量的资源占用，使得测试服务器能够继续流畅地执行其他任务，保障了全系统的高效运行。作为示例，可记录测试服务器的运行日志，以便在满足结束条件时迅速、及时地释放资源。

关于大测例测试任务，仍以上文中关于enmake工具的示例为例，可为大测例测试任务预先部署资源充足的专用节点（即至少一个第三服务器），结合enmake指令，将大测例调度到一个专用节点（即测试服务器）上运行，实现大测例测试。

在enmake指令中，可通过加入大测例测试指令“-b”，指定本次task需要使用的专用节点，具体可以有两种用法。一种例如是“enmake -b –shell”，这种方式是启动测试服务器，enmake工具直接通过SSH与测试服务器进行通信（即enmake工具直接通过SSH进入测试服务器），此时可执行例如环境配置、手动运行测例等特殊需求任务。此时为了合理分配资源，可由Jenkins记录相应的操作，并可使用指令“enmake -b --shell --t 24|48”来限制本次调度测试服务器的时间为24小时或48小时（从Jenkins的记录中确定已调用时间），到时自动释放资源，以降低手动控制时开发人员忘记释放资源产生的资源浪费，定时释放的策略既能减少因判断测试是否结束而产生的计算量，降低计算负荷，又能在测试结束后尽量及时释放资源。另一种例如是“ enmake -b -T "/.../upf-debug -s /.../reg/upf/big-case.tcl" ”，这种方式是正常通过enmake指令调度测试服务器运行大测例，并将结果写入对应开发人员的目录下，不通过SSH到测试服务器上，即不采用手动控制。

关于打包任务，可选地，步骤S103包括：利用目标服务器，在自动化调度指令指示持续集成任务包括打包任务的情况下，对源码的编译结果文件和运行库文件执行打包任务，得到打包文件，其中，运行库文件用于提供运行源码的编译结果文件所需的函数和类；利用目标服务器，在自动化调度指令指示持续集成任务不包括打包任务的情况下，直接保存源码的编译结果文件，其中，运行库文件被加入环境变量中。

编译结果文件就是对源码进行语言转换得到的二进制文件，运行库文件例如是编译结果文件对应的lib64库（64位程序的运行库）。通过将二者打包合并为一个二进制文件（即打包文件），可跨服务器和系统予以执行，具有良好的平台可移植性和多系统共享的功能。另外，通过配置将运行库文件加入环境变量的操作，能够在保障代码运行所需信息的完整性的同时，减少文件数量，此时由于仅需保存编译结果文件这一个文件，无需再执行打包操作，可减少无效的处理步骤，减少算力资源消耗，缩短自动化调度的执行时间，提升任务执行效率，加快代码开发进度。相应地，通过对自动化调度指令的参数进行设计来控制执行或关闭打包操作，可保障前述策略的落地实现。

接下来对步骤S102，即如何控制每个第二服务器的启停状态，进行介绍。

可选地，预先配置的服务器启停机制的目标是使处于启动状态的第二服务器的数量在满足执行任务需要的前提下尽可能少。通过设定上述目标，并据此配置服务器启停机制，能够在满足执行任务需要的情况下，减少启动的第二服务器的数量，从而减少启动服务器带来的支出，有助于控制服务器使用成本，并可节约资源，提高了服务器的使用效率。应理解，此时处于启动状态的第二服务器的数量尽可能少，意味着其中仅有一台第二服务器仍有资源剩余，其他启动的第二服务器的资源可视为占满（严格来说，受到硬件设备的性能限制，其他启动的第二服务器可能还存在少量内存，但不足以支撑一个持续集成任务的执行，可以视为资源被占满），因此在控制每个第二服务器的启停状态之后，处于启动状态且仍有资源剩余的第二服务器就被确定为目标服务器。作为示例，主服务器可能并不便于直接检测第二服务器是否处于启动状态，鉴于第二服务器启动后会自动连接Jenkins，相当于执行上线操作，而关停前也会先断开与Jenkins的连接，相当于执行下线操作，因此，判断第二服务器是否启动，具体可以是判断其是否在线。

作为示例，在未接收到自动化调度指令时，也可利用该服务器启停机制来控制第二服务器的启停状态，例如但不限于周期性地控制第二服务器的启停状态，以便及时关停不需要的第二服务器，有助于进一步控制成本。

作为示例，对于大测例测试任务，若第三服务器的数量为至少两个，则也可以采用该服务器启停机制来控制每个第三服务器的启停状态，进而确定测试服务器。

可选地，步骤S102中响应于自动化调度指令，根据预先配置的服务器启停机制，控制至少一个第二服务器中的每个第二服务器的启停状态的操作包括：响应于自动化调度指令，获取至少一个第二服务器中的每个第二服务器的状态参数，其中，状态参数用于表示相应服务器是否启动以及是否空闲，空闲表示未运行任务；根据至少一个第二服务器的状态参数，确定至少一个第二服务器中处于启动状态的服务器的数量，记为在线节点数量；在在线节点数量小于预设节点数量的情况下，启动至少一个未处于启动状态的第二服务器，以使在线节点数量等于预设节点数量；在在线节点数量大于预设节点数量、且至少一个第二服务器中存在处于启动且空闲状态的服务器的情况下，关停至少一个处于启动且空闲状态的第二服务器，以使在线节点数量等于预设节点数量。通过配置符合启停机制目标的节点数量作为预设节点数量，即预设节点数量是在满足执行任务需要的前提下尽可能少的第二服务器启动数量，并结合各个第二服务器的状态参数确定实际的在线节点数量，能通过将在线节点数量与预设节点数量进行对比，了解启动的第二服务器是否数量合适，进而据此控制每个第二服务器的启停状态，以将在线节点数量调整至与预设节点数量一致，实现了各个第二服务器的启停状态调整。应理解，在在线节点数量等于预设节点数量的情况下，保持第二服务器的启停状态不变。

还应理解，每个第二服务器的资源通常可以支撑多个持续集成任务的执行，并且在产生新任务时，会优先分配给已经启动并且有资源剩余的第二服务器，因此不同的持续集成任务往往是按照时间顺序集中添加到一个第二服务器。在这个第二服务器资源占满后，若产生新的任务，则会出现预设节点数量增加，造成在线节点数量小于预设节点数量的情况，此时即可新启动一个第二服务器，并以此类推，逐渐增加第二服务器的启动数量。由此可见，同一第二服务器上执行的往往是时间上较为接近的多个任务。而一旦其中一个任务执行完毕（通常来说越早开始的任务也相对越早结束，但并不绝对），就能够腾出资源，供新的任务执行。因此，一方面来说，在任务不集中，即不同任务之间的时间间隔适宜的情况下，总体的任务数量能够维持相对平衡，旧任务的结束能够为新任务腾出资源，使得已经启动的若干第二服务器能够满足任务需要，即在线节点数量和预设节点数量都基本保持不变且相等。但在任务较集中时，新的任务频繁产生，此前的任务又尚未执行完毕，就可能需要启动新的第二服务器。另一方面来说，若任务集中的热潮褪去，执行较早任务的第二服务器上的多个任务可能全部执行完毕，此时又没有新任务产生，这个第二服务器就可能处于启动且空闲的状态，并且由于任务数量大幅减少，预设节点数量也可能相应减少，导致在线节点数量大于预设节点数量，此时就可以关停处于启动且空闲状态的第二服务器，以使在线节点数量等于预设节点数量。

此外，由于同一第二服务器上执行的往往是时间上较为接近的多个任务，所以结束的任务也往往集中于同一第二服务器，使得控制完启停状态后，处于启动状态的第二服务器中往往仅有一个还存在资源剩余，也就可以将该第二服务器确定为目标服务器。

针对上述操作，可选地，预设节点数量是在线节点最小量和需求节点数量中的最大值，在线节点最小量是对处于启动状态的第二服务器的最小要求数量，反映了对在线节点数量的最低保留要求，需求节点数量是执行任务所需的第二服务器的数量。通过将预设节点数量配置为二者中的最大值，能够保障这两方面的需求都得到满足，也就是既保留了足够多的第二服务器来满足系统要求，又能够满足执行任务的需求，保障了相应的服务器启停机制的可靠性。

可选地，需求节点数量通过以下步骤得到：获取持续集成任务所归属的持续集成工作下正在执行的任务数量，记为当前任务数量；获取第二服务器能够同时运行的任务数量的上限值，记为最大任务数量；根据当前任务数量与最大任务数量的比值，确定需求节点数量。通过获取当前持续集成工作下正在执行的任务数量，可以了解总体任务量，其与每个第二服务器所能执行的最大任务数量的比值就表示理论上来说需要的第二服务器数量，从而实现需求节点数量的动态更新确认。应理解，若该比值为整数，可直接作为需求节点数量；若该比值为小数，则对该比值使用进一法，得到需求节点数量。还应理解，上述实施例介绍的需求节点数量、预设节点数量以及根据预设节点数量对第二服务器进行启停状态控制的策略，属于原则性的说明，实际执行时可以完全一致地确定相应的各项取值、判断和启停状态控制，也可以在不违背该原则的情况下，对各项取值的具体确定、相应的判断标准和启停状态控制方式进行适当调整，例如对需求节点数量可以不采用进一法，而采用其他方法来确定，又如可以不确定预设节点数量，转而分别针对在线节点最小量和需求节点数量分别进行判断，这些适当调整后的方式同样属于本申请的实现方式，落入本申请的保护范围之内。后文中将结合图5，以一个具体实施例来介绍其中一个调整后的实现方式。

针对上述操作的具体执行，可选地，在在线节点数量小于预设节点数量的情况下，启动至少一个未处于启动状态的第二服务器，以使在线节点数量等于预设节点数量的操作包括：遍历每个未处于启动状态的第二服务器，在在线节点数量小于预设节点数量的情况下，启动当前的第二服务器，以使在线节点数量等于预设节点数量。按照人脑的思维，该操作可能会执行为在在线节点数量小于预设节点数量的情况下，确定预设节点数量与在线节点数量的差值，然后从未处于启动状态的第二服务器中确定差值数量的第二服务器，予以启动。但对于计算机而言，这样的操作涉及差值计算、特定状态的服务器统计、服务器选择，可能会消耗较多的计算资源和内存。通过采用遍历的形式来针对每个未处于启动状态的第二服务器进行判断和控制，就可以直接遍历每个第二服务器，然后判断该第二服务器是否处于启动状态，若否，则进一步判断在线节点数量是否小于预设节点数量，若是，则启动当前第二服务器，这样的规则仅需针对每个第二服务器进行较为简单的计算，有助于提升方案的执行效率，降低内存消耗。作为示例，可以在获取第二服务器的状态参数时提前统一分析每个第二服务器的启停状态，在遍历每个第二服务器并进行判断时直接使用分析结果，也可以在遍历每个第二服务器并进行判断时再分析当前服务器的启停状态，本申请对此不作限制。应理解，在遍历的过程中，随着新的第二服务器的启动，在线节点数量会增加。作为示例，可以每启动一个第二服务器，就将在线节点数量加1，而不必重新统计每个第二服务器的状态参数来确定在线节点数量。

类似地，可选地，在在线节点数量大于预设节点数量、且至少一个第二服务器中存在处于启动且空闲状态的服务器的情况下，关停至少一个处于启动且空闲状态的第二服务器，以使在线节点数量等于预设节点数量的操作包括：遍历每个处于启动且空闲状态的第二服务器，在在线节点数量大于预设节点数量的情况下，关停当前的第二服务器，以使在线节点数量等于预设节点数量。与启动新的第二服务器的情况类似，通过采用遍历的形式来针对每个处于启动且空闲状态的第二服务器进行判断和控制，就可以直接遍历每个第二服务器，然后判断该第二服务器是否处于启动且空闲状态，若是，则进一步判断在线节点数量是否大于预设节点数量，若是，则关停当前第二服务器，从而仅需针对每个第二服务器进行较为简单的计算，有助于提升方案的执行效率，降低内存消耗。作为示例，可以在获取第二服务器的状态参数时提前统一分析每个第二服务器的启停状态和空闲状态，在遍历每个第二服务器并进行判断时直接使用分析结果，也可以在遍历每个第二服务器并进行判断时再分析当前服务器的启停状态和空闲状态，本申请对此不作限制。应理解，在遍历的过程中，随着第二服务器的关停，在线节点数量会减少。作为示例，可以每关停一个第二服务器，就将在线节点数量减1，而不必重新统计每个第二服务器的状态参数来确定在线节点数量。

以上两部分操作可以结合起来，实现对每个第二服务器的统一遍历。

作为示例，在确定目标服务器前，enmake工具需要先分别确定服务于当前job的每台slave服务器的状态参数，然后根据当前job下正在运行的task数量（即当前任务数量）、每台slave服务器的状态参数和最大任务数量，确定每台slave服务器是否需要启动或关停，由Jenkins最终确定用于运行本次task的目标服务器。其中，每台slave服务器的最大任务数量是指该服务器能够同时并发运行的任务数量，其数值可根据该slave服务器的核心配置而定，同理，也可以反过来根据具体的任务需要来配置slave服务器的核和内存。例如，在slave服务器的配置为36Core 72GB的情况下，可将最大任务数量设置为5，其中，为每个任务预分配7Core，共计预分配35Core，剩余1Core则用于支持系统运行。应理解，从硬件的角度来说，master服务器由于只负责调度，所以不需要配置多核，也不需要很大的内存。

slave服务器的状态参数包括idle、online、nodeOnlineNum。idle用于指示slave服务器是否空闲，若赋值true，则表示该slave服务器空闲，没有正在运行的任务；若赋值false，则表示该服务器上有正在运行的任务。online用于指示slave服务器是否与Jenkins连接，若赋值true，则表示Jenkins已连接该slave服务器；若赋值false，则表示Jenkins未连接该slave服务器。具体地，当slave服务器启动后，就会与Jenkins建立连接，关停slave服务器前，将先断开连接，故online可用于指示slave服务器是否启动。nodeOnlineNum为在线节点数，用于指示当前job与Jenkins连接的slave服务器的数量。

接下来结合图5，为本申请中控制第二服务器的启停状态的总体流程，介绍一个具体实施例。在该具体实施例中，将针对在线节点最小量和需求节点数量分别进行判断，并且对于不同状态的服务器（即在线且空闲的服务器，以及不在线的服务器），采用不同的具体公式来实现针对需求节点数量的判断。

参照图5，在步骤S501中，自动化调度工具获取当前工作的数据接口。

在步骤S502中，获取当前工作的任务列表中最后一个任务的编号（例如ID号），然后向下遍历，判断任务列表中的每个任务是否还在运行，并统计正在运行的任务数量，得到当前任务数量runningNum。

在步骤S503中，获取与当前工作相关的服务器数据，判断各个服务器（具体是第二服务器）是否在线（即是否和Jenkins建立连接）、是否空闲，并统计在线节点数量nodeOnlineNum，得到状态参数。

在步骤S504中，以遍历全部第二服务器为目标，从全部第二服务器中确定一个作为当前服务器。

在步骤S505中，根据状态参数，判断当前服务器是否在线，若是，则转到步骤S506，若否，则转到步骤S511。

在步骤S506中，根据状态参数，判断当前服务器是否空闲，若是，则转到步骤S507，若否，则转到步骤S504。

在步骤S507中，判断在线节点数量是否超出任务需求，具体是判断是否满足float64(runningNum)/5<= nodeOnlineNum-1（这里的5为上文中示例的最大任务数量，其取值可根据实际情况进行调整），若是，则表示在线节点数量nodeOnlineNum超出了任务需求，转到步骤S508，若否，则表示在线节点数量nodeOnlineNum未超出任务需求，需要在当前服务器运行新的任务，不能将当前服务器关停，转到步骤S509。

在步骤S508中，判断在线节点数量是否高于最低保留要求，具体是判断是否满足nodeOnlineNum>float64(nodeList.Groups[group].Retain)（即在线节点最小量），若是，则表示在线节点数量高于最低保留要求，也就是同时满足了任务需求和最低保留要求，转到步骤S510，若否，则表示不满足或刚好满足最低保留要求，转到步骤S509。

应理解，考虑到最初启动时就会优先保证满足最低保留要求，所以判断结果为否时，这里的关系其实是等于，往往不会出现小于的情况。此时若关停当前服务器，就会造成不满足最低保留要求，因而不能将当前服务器关停。

在步骤S509中，对当前服务器的启停状态不做调整。

在步骤S510中，关停当前服务器。

在步骤S511中，判断在线节点数量是否满足任务需求，具体是判断是否满足float64(runningNum)/5<= nodeOnlineNum（5仍然表示最大任务数量），若是，则表示在线节点数量满足任务需求，无需启动新服务器，转到步骤S509，若否，则表示在线节点数量无法满足任务需求，转到步骤S512。

应理解，考虑到项目最初启动服务器时通常就会优先启动满足最低保留要求数量的第二服务器，所以最低保留要求对于启动新服务器不产生影响，这里可以省略对是否满足最低保留要求的判断。而该要求对于关停服务器会产生影响，也就是关停过多的服务器可能造成无法满足最低保留要求，所以在关停服务器前需要判断关停当前服务器后能否满足最低保留要求，因而需要执行步骤S508。

在步骤S512中，启动当前服务器。

步骤S509、S510、S512执行结束后均返回步骤S504以确定新的当前服务器，从而实现对全部第二服务器的遍历。应理解，若步骤S504已完成遍历，确定没有新的第二服务器，则整个流程结束。

此外，需说明的是，对于还涉及大测例测试、且采用确定目标服务器的方法来确定测试服务器的实施例，可采用控制第二服务器的启停状态的流程来控制第三服务器的启停状态，并且针对第二服务器和第三服务器分别配置各自的在线节点最小量和最大任务数量，并分别统计各自的当前任务数量和在线节点数量。同时，为了对第二服务器和第三服务器加以区分，可以在启动各个服务器时为其赋予标识（label），实现服务器分组，以明确该服务器所适用的任务，Jenkins再按照当前任务适合的label来圈定服务器范围，从圈定的服务器中查找有资源剩余的服务器作为目标服务器或测试服务器。应理解，每个服务器的最大任务数量是根据其资源确定的，但同一label的服务器（即同一组服务器）的最大任务数量是固定的。关于服务器的内存，作为示例，第一个label对应于第二服务器，用于执行编译、普通测试、覆盖率统计、打包等任务，例如可使用内存72GB的服务器，第二个label对应于第三服务器，用于执行大测例测试任务，例如可使用内存256GB的服务器。

除图1和图2所示的各项步骤外，可选地，根据本申请示例性实施例的持续集成的自动化调度方法还包括：抓取调度日志和执行日志，其中，调度日志用于记录对目标服务器的调度，执行日志用于记录对持续集成任务的执行，执行日志保存在源码目录下，源码目录是保存源码的目录。通过抓取调度日志，能够了解为执行持续集成任务而调度目标服务器的情况；通过抓取执行日志，则能够详细了解任务的执行进度和具体执行过程。对调度日志和执行日志均予以抓取，能够保证日志的完整性，实现任务执行信息的全面获取。

作为示例，调度日志是Jenkins记录的日志，也可称为Jenkins日志，主要是执行pipeline的日志。调度日志的日志信息主要包括服务器信息和阶段（stage）信息，节点信息用于指示与本次task相关的pipeline运行于哪个服务器，阶段信息用于指示与本次task相关的pipeline运行于哪个阶段，例如Checkout SCM（Source Control Management，源码控制管理）阶段，该阶段是用来下载git仓库代码。

执行日志是目标服务器运行本次任务的日志，存储于当前project源码目录下的build_log文件（主要是编译和运行测例的日志）中，在enmake工具对当前build_log文件开启“监视器”后，会对build_log文件中的日志信息进行抓取操作。

可选地，抓取调度日志的操作包括：在确定到达预设触发时间的情况下，判断调度日志的内容是否更新，若是，则抓取调度日志，若否，则将预设触发时间延后预设时长。调度日志记载了Jenkins对目标服务器的调度，在执行任务的过程中内容不会更新。通过配置预设触发时间，并在到期时先判断调度日志的内容是否更新，再在有更新时才进行抓取，无更新时延后，能够避免抓取操作持续被触发，从而减小Jenkins的负载，降低高负载风险，并可节约资源，提高性能。作为示例，可对调度日志的抓取操作进行延时处理，也就是在最近一次抓取到调度日志后（第一次到达预设触发时间后），不立即执行新的抓取操作，而是先判断调度日志的内容是否更新，若判定调度日志没有更新日志信息，则将抓取操作的延时增加2秒（即预设时长为2秒），2秒后第二次到达预设触发时间，重复执行判断。如此继续执行，只要调度日志没有更新，延时就会一直累加，直至调度日志中更新了日志信息，则重置延时，并立即执行抓取操作来获取新的日志信息。

综上所述，本申请归属EDA行业，应用于EDA工具开发，属于C++代码构建、测试、打包等全流程加速的应用范围，能够提升EDA工具代码开发验证的速度，提高部门整体的工作效率。

本申请的架构方案以开源服务为架构基础，将C++代码编译、测试、覆盖率统计、打包等功能从开发人员当前的工作环境中抽离出来，并且整合到自主研发的自动化调度工具enmake（一个可执行的二进制文件，相当于一个自动化的脚本）中，以提升EDA工具代码开发验证的整体效率。

具体而言，本申请中的所有开发工作均需要在AWS的VNC上完成，因运行桌面系统资源消耗相对命令行大很多，且考虑到每月的公有云支出，所以三个人同时使用一台8Core32GB的服务器，这就导致了资源抢占的问题，同时当一名开发人员执行编译操作的时候，会导致服务器变得很卡顿，对其他两个开发人员的工作有负面影响。通过将所有开发人员的编译从他们的工作环境中抽离出来（即利用另外的服务器来执行编译操作），使用enmake+Jenkins调度的方式去运行这个任务，同时将code（即源码目录）和result（即编译后得到的可执行的二进制文件）整合到一个共享文件系统，方便当前源码获取和结果的返回。

此外，还将运行测例和统计覆盖率也单独抽离出来，整合进入enmake工具，减少了因运行测例导致的内存溢出、将服务器系统资源彻底占满而导致的无法使用的问题。为了减少重启服务器的故障率，同时，为了加快编译进度，还将ccache缓存整合到每次编译中，使得执行编译的服务器在编译过程中使用共享的ccache缓存，自身只存储编译过程中产生的少量中间文件，很大程度上加快了编译的速度，整体上解决了C++编译资源消耗多、速度慢、影响范围大的问题。

总体来说，将开发环境与编译、测试等资源重度使用情形分离，使得持续集成更加集成，更加规范化，并可降低开发使用的服务器的负载，降低内存溢出、因资源不够出现的卡顿、VNC响应变慢等问题出现的概率。经测试，本申请的方案能够加快开发构建和测试的过程，从原有的18分钟，降低为3分钟。

图6是示出根据本申请示例性实施例的持续集成的自动化调度装置的框图。

参照图6，持续集成的自动化调度装置600包括接收单元601、确定单元602、执行单元603。

接收单元601被配置为接收输入至第一服务器中的自动化调度指令。其中，第一服务器用于提供编写源码的工作环境。

确定单元602被配置为响应于自动化调度指令，根据预先配置的服务器启停机制，控制至少一个第二服务器中的每个第二服务器的启停状态，以从至少一个第二服务器中确定目标服务器。

执行单元603被配置为利用目标服务器，根据自动化调度指令对源码执行持续集成任务，其中，第二服务器用于为持续集成任务提供计算资源，持续集成任务至少包括编译任务。

可选地，自动化调度指令包括完整指令、部分缺省指令和完全缺省指令，其中，完整指令包括头指令、相对应的任务键指令和任务值指令，头指令用于表示当前指令的属性是自动化调度指令，任务键指令用于表示持续集成任务的类型，任务值指令用于表示相应持续集成任务的执行参数，完整指令用于表示按照任务值指令表示的执行参数执行相对应的任务键指令表示的类型的持续集成任务；部分缺省指令包括头指令、相对应的任务键指令和缺省任务值指令，缺省任务值指令用于表示相应持续集成任务的执行参数为默认参数，部分缺省指令用于表示按照默认参数执行相对应的任务键指令表示的类型的持续集成任务；完全缺省指令包括头指令，完全缺省指令用于表示针对默认源码目录使用默认参数执行编译任务。

可选地，任务键指令包括以下至少一个：源码指令、编译指令、测试指令、覆盖率统计指令、打包指令，其中，源码指令对应的任务值指令包括源码目录的路径名称，编译指令对应的任务值指令包括编译参数，测试指令对应的任务值指令包括测例的路径名称，覆盖率统计指令对应的任务值指令包括保存目录或保存文件的路径名称，打包指令对应的任务值指令包括是否打包。

可选地，执行单元603还被配置为：利用目标服务器，在自动化调度指令中包括源码指令和源码目录的路径名称的情况下，根据源码目录的路径名称确定当前源码，在自动化调度指令中不包括源码指令和源码目录的路径名称的情况下，确定当前目录下的源码作为当前源码；利用目标服务器，在自动化调度指令中包括编译指令和编译参数的情况下，提取编译参数作为当前编译参数，在自动化调度指令中不包括编译指令和编译参数的情况下，若获取到当前目录下的历史编译参数，则将历史编译参数作为当前编译参数，并根据当前编译参数对当前源码执行编译任务，得到编译结果文件，若未获取到当前目录下的历史编译参数，则输出报警信息。

可选地，执行单元603还被配置为：利用目标服务器，在自动化调度指令中不包括测试指令、覆盖率统计指令和打包指令中的任意一个的情况下，不执行相应类型的任务；利用目标服务器，在自动化调度指令中包括测试指令的情况下，若自动化调度指令还包括默认测例指令，则将默认测例指令对应的默认测例作为当前测例，若自动化调度指令还包括测例的路径名称，则根据测例的路径名称确定当前测例，并使用当前测例对源码的编译结果文件执行测试任务。

可选地，源码目录为共享目录；和/或持续集成的自动化调度装置600还包括保存单元（图中未示出），被配置为将源码的编译结果文件保存至编译结果目录，编译结果目录为共享目录。

可选地，目标服务器使用编译器缓存，其中，编译器缓存为共享缓存。

可选地，任务键指令包括大测例测试指令，大测例测试指令用于表示所需内存容量超过预设内存容量的测试任务，持续集成的自动化调度装置600还包括测试单元（图中未示出），被配置为：根据大测例测试指令，从至少一个第三服务器中确定测试服务器，其中，第三服务器的内存容量大于第二服务器的内存容量以及预设内存容量；利用测试服务器，根据大测例测试指令对源码的编译结果文件执行测试任务。

可选地，确定单元602还被配置为将测试服务器作为目标服务器。

可选地，测试单元还被配置为：接收输入至第一服务器中的测试参数和/或测试命令；向测试服务器发送测试参数和/或测试命令，以使测试服务器根据大测例测试指令以及测试参数和/或测试命令对源码的编译结果文件执行测试任务。

可选地，持续集成的自动化调度装置600还包括释放单元（图中未示出），被配置为在满足预设结束条件的情况下，释放测试服务器的资源，以停止执行测试任务。

可选地，执行单元603还被配置为：利用目标服务器，在自动化调度指令指示持续集成任务包括打包任务的情况下，对源码的编译结果文件和运行库文件执行打包任务，得到打包文件，其中，运行库文件用于提供运行源码的编译结果文件所需的函数和类；利用目标服务器，在自动化调度指令指示持续集成任务不包括打包任务的情况下，直接保存源码的编译结果文件，其中，运行库文件被加入环境变量中。

可选地，预先配置的服务器启停机制的目标是使处于启动状态的第二服务器的数量在满足执行任务需要的前提下尽可能少。

可选地，确定单元602还被配置为：响应于自动化调度指令，获取至少一个第二服务器中的每个第二服务器的状态参数，其中，状态参数用于表示相应服务器是否启动以及是否空闲，空闲表示未运行任务；根据至少一个第二服务器的状态参数，确定至少一个第二服务器中处于启动状态的服务器的数量，记为在线节点数量；在在线节点数量小于预设节点数量的情况下，启动至少一个未处于启动状态的第二服务器，以使在线节点数量等于预设节点数量；在在线节点数量大于预设节点数量、且至少一个第二服务器中存在处于启动且空闲状态的服务器的情况下，关停至少一个处于启动且空闲状态的第二服务器，以使在线节点数量等于预设节点数量。

可选地，预设节点数量是在线节点最小量和需求节点数量中的最大值，在线节点最小量是对处于启动状态的第二服务器的最小要求数量，需求节点数量是执行任务所需的第二服务器的数量。

可选地，需求节点数量通过以下步骤得到：获取持续集成任务所归属的持续集成工作下正在执行的任务数量，记为当前任务数量；获取第二服务器能够同时运行的任务数量的上限值，记为最大任务数量；根据当前任务数量与最大任务数量的比值，确定需求节点数量。

可选地，确定单元602还被配置为：遍历每个未处于启动状态的第二服务器，在在线节点数量小于预设节点数量的情况下，启动当前的第二服务器，以使在线节点数量等于预设节点数量；和/或在在线节点数量大于预设节点数量、且至少一个第二服务器中存在处于启动且空闲状态的服务器的情况下，关停至少一个处于启动且空闲状态的第二服务器，以使在线节点数量等于预设节点数量，包括：遍历每个处于启动且空闲状态的第二服务器，在在线节点数量大于预设节点数量的情况下，关停当前的第二服务器，以使在线节点数量等于预设节点数量。

可选地，持续集成的自动化调度装置600还包括抓取单元（图中未示出），被配置为抓取调度日志和执行日志，其中，调度日志用于记录对目标服务器的调度，执行日志用于记录对持续集成任务的执行，执行日志保存在源码目录下，源码目录是保存源码的目录。

可选地，抓取单元还被配置为在确定到达预设触发时间的情况下，判断调度日志的内容是否更新，若是，则抓取调度日志，若否，则将预设触发时间延后预设时长。

关于上述实施例中的装置，其中各个单元执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

图7是示出根据本申请示例性实施例的计算机设备的框图。如图7所示，计算机设备700包括至少一个处理器701和至少一个存储计算机可执行指令的存储器702。这里，计算机可执行指令在被处理器701运行时，促使处理器701执行如上述示例性实施例所述的自动化调度方法。

作为示例，计算机设备700并非必须是单个的设备，还可以是任何能够单独或联合执行上述指令（或指令集）的装置或电路的集合体。计算机设备700还可以是集成控制系统或系统管理器的一部分，或者可被配置为与本地或远程（例如，经由无线传输）以接口互联的服务器。

在计算机设备700中，处理器701可包括中央处理器（CPU）、图形处理器（GPU）、可编程逻辑装置、专用处理器系统、微控制器或微处理器。作为示例而非限制，处理器701还可包括模拟处理器、数字处理器、微处理器、多核处理器、处理器阵列、网络处理器等。

处理器701可运行存储在存储器702中的指令或代码，其中，存储器702还可以存储数据。指令和数据还可经由网络接口装置而通过网络被发送和接收，其中，网络接口装置可采用任何已知的传输协议。

存储器702可与处理器701集成为一体，例如，将RAM或闪存布置在集成电路微处理器等之内。此外，存储器702可包括独立的装置，诸如，外部盘驱动、存储阵列或任何数据库系统可使用的其他存储装置。存储器702和处理器701可在操作上进行耦合，或者可例如通过I/O端口、网络连接等互相通信，使得处理器701能够读取存储在存储器702中的文件。

此外，计算机设备700还可以包括视频显示器（诸如，液晶显示器）和用户交互接口（诸如，键盘、鼠标、触摸输入装置等）。计算机设备700的所有组件可经由总线和/或网络而彼此连接。

在示例性实施例中，还可提供一种计算机可读存储介质，当计算机可读存储介质中的指令被处理器执行时，使得处理器能够执行如上述示例性实施例所述的自动化调度方法。计算机可读存储介质例如可以是包括指令的存储器，可选地，计算机可读存储介质可以是：只读存储器（ROM）、随机存取存储器（RAM）、随机存取可编程只读存储器（PROM）、电可擦除可编程只读存储器（EEPROM）、动态随机存取存储器（DRAM）、静态随机存取存储器（SRAM）、闪存、非易失性存储器、CD-ROM、CD-R、CD+R、CD-RW、CD+RW、DVD-ROM、DVD-R、DVD+R、DVD-RW、DVD+RW、DVD-RAM、BD-ROM、BD-R、BD-R LTH、BD-RE、蓝光或光盘存储器、硬盘驱动器（HDD）、固态硬盘（SSD）、卡式存储器（诸如，多媒体卡、安全数字（SD）卡或极速数字（XD）卡）、磁带、软盘、磁光数据存储装置、光学数据存储装置、硬盘、固态盘以及任何其他装置，所述任何其他装置被配置为以非暂时性方式存储计算机程序以及任何相关联的数据、数据文件和数据结构并将所述计算机程序以及任何相关联的数据、数据文件和数据结构提供给处理器或计算机使得处理器或计算机能执行所述计算机程序。上述计算机可读存储介质中的计算机程序可在诸如客户端、主机、代理装置、服务器等计算机设备中部署的环境中运行，此外，在一个示例中，计算机程序以及任何相关联的数据、数据文件和数据结构分布在联网的计算机系统上，使得计算机程序以及任何相关联的数据、数据文件和数据结构通过一个或多个处理器或计算机以分布式方式存储、访问和执行。

在示例性实施例中，还可提供一种计算机程序产品，包括计算机指令，当计算机指令被处理器运行时，促使处理器执行如上述示例性实施例所述的自动化调度方法。

在示例性实施例中，还可提供一种持续集成的自动化调度系统，自动化调度系统包括第一服务器和至少一个第二服务器，第一服务器包括如上述示例性实施例所述的计算机设备。

可选地，自动化调度系统还包括主服务器，用于实现持续集成任务的任务调度，主服务器与第一服务器以及至少一个第二服务器之间建立有通信连接，能够从至少一个第二服务器中确定目标服务器，并调度目标服务器，使得目标服务器执行持续集成任务。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其他实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由权利要求指出。

此外，还需要说明的是，尽管上面参照具体附图描述了各步骤的若干示例，但是应理解的是，本申请的实施方式不限于示例中给出的组合，不同附图中出现的步骤可以相结合，在此不作出穷举。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由权利要求来限制。

Claims (24)

1.一种持续集成的自动化调度方法，其特征在于，所述自动化调度方法应用于集成电路电子设计自动化软件开发，所述自动化调度方法包括：

接收输入至第一服务器中的自动化调度指令，其中，所述第一服务器用于提供编写源码的工作环境；

响应于所述自动化调度指令，根据预先配置的服务器启停机制，控制至少一个第二服务器中的每个第二服务器的启停状态，以从所述至少一个第二服务器中确定目标服务器；

利用所述目标服务器，根据所述自动化调度指令对所述源码执行持续集成任务，其中，所述第二服务器用于为所述持续集成任务提供计算资源，所述持续集成任务至少包括编译任务。

2.如权利要求1所述的自动化调度方法，其特征在于，

所述自动化调度指令包括完整指令、部分缺省指令和完全缺省指令，

其中，所述完整指令包括头指令、相对应的任务键指令和任务值指令，所述头指令用于表示当前指令的属性是自动化调度指令，所述任务键指令用于表示持续集成任务的类型，所述任务值指令用于表示相应持续集成任务的执行参数，所述完整指令用于表示按照任务值指令表示的执行参数执行相对应的任务键指令表示的类型的持续集成任务；

所述部分缺省指令包括所述头指令、相对应的所述任务键指令和缺省任务值指令，所述缺省任务值指令用于表示相应持续集成任务的执行参数为默认参数，所述部分缺省指令用于表示按照默认参数执行相对应的任务键指令表示的类型的持续集成任务；

所述完全缺省指令包括所述头指令，所述完全缺省指令用于表示针对默认源码目录使用默认参数执行编译任务。

3.如权利要求2所述的自动化调度方法，其特征在于，

所述任务键指令包括以下至少一个：源码指令、编译指令、测试指令、覆盖率统计指令、打包指令，其中，所述源码指令对应的任务值指令包括源码目录的路径名称，所述编译指令对应的任务值指令包括编译参数，所述测试指令对应的任务值指令包括测例的路径名称，所述覆盖率统计指令对应的任务值指令包括保存目录或保存文件的路径名称，所述打包指令对应的任务值指令包括是否打包。

4.如权利要求3所述的自动化调度方法，其特征在于，所述利用所述目标服务器，根据所述自动化调度指令对所述源码执行持续集成任务，包括：

利用所述目标服务器，在所述自动化调度指令中包括所述源码指令和所述源码目录的路径名称的情况下，根据所述源码目录的路径名称确定当前源码，在所述自动化调度指令中不包括所述源码指令和所述源码目录的路径名称的情况下，确定当前目录下的源码作为所述当前源码；

利用所述目标服务器，在所述自动化调度指令中包括所述编译指令和所述编译参数的情况下，提取所述编译参数作为当前编译参数，在所述自动化调度指令中不包括所述编译指令和所述编译参数的情况下，若获取到当前目录下的历史编译参数，则将所述历史编译参数作为所述当前编译参数，并根据所述当前编译参数对所述当前源码执行编译任务，得到编译结果文件，若未获取到当前目录下的历史编译参数，则输出报警信息。

5.如权利要求3所述的自动化调度方法，其特征在于，所述利用所述目标服务器，根据所述自动化调度指令对所述源码执行持续集成任务，包括：

利用所述目标服务器，在所述自动化调度指令中不包括所述测试指令、所述覆盖率统计指令和所述打包指令中的任意一个的情况下，不执行相应类型的任务；

利用所述目标服务器，在所述自动化调度指令中包括所述测试指令的情况下，若所述自动化调度指令还包括默认测例指令，则将所述默认测例指令对应的默认测例作为当前测例，若所述自动化调度指令还包括测例的路径名称，则根据所述测例的路径名称确定所述当前测例，并使用所述当前测例对所述源码的编译结果文件执行测试任务。

6.如权利要求3所述的自动化调度方法，其特征在于，

所述源码目录为共享目录；和/或

所述自动化调度方法还包括：将所述源码的编译结果文件保存至编译结果目录，所述编译结果目录为共享目录；和/或

所述目标服务器使用编译器缓存，其中，所述编译器缓存为共享缓存。

7.如权利要求2所述的自动化调度方法，其特征在于，所述任务键指令包括大测例测试指令，所述大测例测试指令用于表示所需内存容量超过预设内存容量的测试任务，所述自动化调度方法还包括：

根据所述大测例测试指令，从至少一个第三服务器中确定测试服务器，其中，所述第三服务器的内存容量大于所述第二服务器的内存容量以及所述预设内存容量；

利用所述测试服务器，根据所述大测例测试指令对所述源码的编译结果文件执行测试任务。

8.如权利要求7所述的自动化调度方法，其特征在于，所述自动化调度方法还包括：

将所述测试服务器作为所述目标服务器。

9.如权利要求7所述的自动化调度方法，其特征在于，所述利用所述测试服务器，根据所述大测例测试指令对所述源码的编译结果文件执行测试任务，包括：

接收输入至所述第一服务器中的测试参数和/或测试命令；

向所述测试服务器发送所述测试参数和/或测试命令，以使所述测试服务器根据所述大测例测试指令以及所述测试参数和/或测试命令对所述源码的编译结果文件执行测试任务。

10.如权利要求7所述的自动化调度方法，其特征在于，所述自动化调度方法还包括：

在满足预设结束条件的情况下，释放所述测试服务器的资源，以停止执行所述测试任务。

11.如权利要求1所述的自动化调度方法，其特征在于，所述利用所述目标服务器，根据所述自动化调度指令对所述源码执行持续集成任务，包括：

利用所述目标服务器，在所述自动化调度指令指示所述持续集成任务包括打包任务的情况下，对所述源码的编译结果文件和运行库文件执行打包任务，得到打包文件，其中，所述运行库文件用于提供运行所述源码的编译结果文件所需的函数和类；

利用所述目标服务器，在所述自动化调度指令指示所述持续集成任务不包括打包任务的情况下，直接保存所述源码的编译结果文件，其中，所述运行库文件被加入环境变量中。

12.如权利要求1所述的自动化调度方法，其特征在于，所述预先配置的服务器启停机制的目标是使处于启动状态的第二服务器的数量在满足执行任务需要的前提下尽可能少。

13.如权利要求12所述的自动化调度方法，其特征在于，所述响应于所述自动化调度指令，根据预先配置的服务器启停机制，控制至少一个第二服务器中的每个第二服务器的启停状态，包括：

响应于所述自动化调度指令，获取所述至少一个第二服务器中的每个第二服务器的状态参数，其中，所述状态参数用于表示相应服务器是否启动以及是否空闲，空闲表示未运行任务；

根据所述至少一个第二服务器的状态参数，确定所述至少一个第二服务器中处于启动状态的服务器的数量，记为在线节点数量；

在所述在线节点数量小于预设节点数量的情况下，启动至少一个未处于启动状态的第二服务器，以使所述在线节点数量等于所述预设节点数量；

在所述在线节点数量大于所述预设节点数量、且所述至少一个第二服务器中存在处于启动且空闲状态的服务器的情况下，关停至少一个处于启动且空闲状态的第二服务器，以使所述在线节点数量等于所述预设节点数量。

14.如权利要求13所述的自动化调度方法，其特征在于，

所述预设节点数量是在线节点最小量和需求节点数量中的最大值，所述在线节点最小量是对处于启动状态的第二服务器的最小要求数量，所述需求节点数量是执行任务所需的第二服务器的数量。

15.如权利要求14所述的自动化调度方法，其特征在于，所述需求节点数量通过以下步骤得到：

获取所述持续集成任务所归属的持续集成工作下正在执行的任务数量，记为当前任务数量；

获取所述第二服务器能够同时运行的任务数量的上限值，记为最大任务数量；

根据所述当前任务数量与所述最大任务数量的比值，确定所述需求节点数量。

16.如权利要求13所述的自动化调度方法，其特征在于，

所述在所述在线节点数量小于预设节点数量的情况下，启动至少一个未处于启动状态的第二服务器，以使所述在线节点数量等于所述预设节点数量，包括：遍历每个未处于启动状态的第二服务器，在所述在线节点数量小于预设节点数量的情况下，启动当前的第二服务器，以使所述在线节点数量等于所述预设节点数量；和/或

所述在所述在线节点数量大于所述预设节点数量、且所述至少一个第二服务器中存在处于启动且空闲状态的服务器的情况下，关停至少一个处于启动且空闲状态的第二服务器，以使所述在线节点数量等于所述预设节点数量，包括：遍历每个处于启动且空闲状态的第二服务器，在所述在线节点数量大于所述预设节点数量的情况下，关停当前的第二服务器，以使所述在线节点数量等于所述预设节点数量。

17.如权利要求1至16中的任一权利要求所述的自动化调度方法，其特征在于，所述自动化调度方法还包括：

抓取调度日志和执行日志，其中，所述调度日志用于记录对所述目标服务器的调度，所述执行日志用于记录对所述持续集成任务的执行，所述执行日志保存在源码目录下，所述源码目录是保存所述源码的目录。

18.如权利要求17所述的自动化调度方法，其特征在于，抓取所述调度日志的操作包括：

在确定到达预设触发时间的情况下，判断所述调度日志的内容是否更新，若是，则抓取所述调度日志，若否，则将所述预设触发时间延后预设时长。

19.一种持续集成的自动化调度装置，其特征在于，所述自动化调度装置应用于集成电路电子设计自动化软件开发，其中，所述自动化调度装置包括：

接收单元，被配置为接收输入至第一服务器中的自动化调度指令，其中，所述第一服务器用于提供编写源码的工作环境；

确定单元，被配置为响应于所述自动化调度指令，根据预先配置的服务器启停机制，控制至少一个第二服务器中的每个第二服务器的启停状态，以从所述至少一个第二服务器中确定目标服务器；

执行单元，被配置为利用所述目标服务器，根据所述自动化调度指令对所述源码执行持续集成任务，其中，所述第二服务器用于为所述持续集成任务提供计算资源，所述持续集成任务至少包括编译任务。

20.一种计算机可读存储介质，其特征在于，当所述计算机可读存储介质中的指令被至少一个处理器运行时，促使所述至少一个处理器执行如权利要求1至18中的任一权利要求所述的自动化调度方法。

21.一种计算机设备，其特征在于，包括：

至少一个处理器；

至少一个存储计算机可执行指令的存储器，

其中，所述计算机可执行指令在被所述至少一个处理器运行时，促使所述至少一个处理器执行如权利要求1至18中的任一权利要求所述的自动化调度方法。

22.一种计算机程序产品，包括计算机指令，其特征在于，当所述计算机指令被至少一个处理器运行时，促使所述至少一个处理器执行如权利要求1至18中的任一权利要求所述的自动化调度方法。

23.一种持续集成的自动化调度系统，其特征在于，所述自动化调度系统包括第一服务器和至少一个第二服务器，所述第一服务器包括权利要求21所述的计算机设备。

24.如权利要求23所述的自动化调度系统，其特征在于，所述自动化调度系统还包括主服务器，用于实现持续集成任务的任务调度，所述主服务器与所述第一服务器以及所述至少一个第二服务器之间建立有通信连接。