CN109739507A - 一种代码持续集成方法和代码持续交付方法 - Google Patents

Abstract

本申请公开了一种代码持续集成方法和代码持续交付方法。代码持续集成方法应用于代码评审工具Gerrit，接收开发人员提交的代码后将代码输入编译工具，代码先后通过编译工具和静态扫描工具；接收编译工具和静态扫描工具对代码的第一执行结果和第二执行结果；根据第一执行结果和第二执行结果确定代码是否可用于持续交付。开发人员可通过Gerrit平台获知第一执行结果和第二执行结果，从而在代码持续集成的过程中可实时获知代码的问题，不必等到代码合并到远程代码仓库后再确认问题。相比现有技术，该方法能够提早暴露代码持续集成过程中发现的问题，使得开发人员得以及时对代码进行修正，进而有效提升了代码及软件产品的交付速度。

Description

一种代码持续集成方法和代码持续交付方法

技术领域

本申请涉及软件工程技术领域，特别是涉及一种代码持续集成方法和代码持续交付方法。

背景技术

代码持续集成是一种软件开发实践。软件研发团队的成员经常需要集成他们的代码编写工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次代码集成都通过自动化的构建，包括：编译，发布，自动化测试等流程来验证代码。持续集成的目的是尽早发现代码集成错误，避免或减少代码集成问题。

代码持续交付是一种软件工程手法，让软件产品在一个短周期内完成产出，以保证软件可以稳定、持续的保持在随时可以释出的状况。持续交付的目标在于让软件的建置、测试与释出变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。持续交付需要将集成后的代码部署到“类线上环境”中，即部署到贴近真实运行的环境中。

代码持续集成后需要合并到远程的代码仓库中，而在此之前，代码持续集成的问题对于开发人员来说，是不可知的。开发人员只能等到合仓后，通过邮件或平台通知的方式获知代码持续集成产生的问题。因此，开发人员获知的代码持续集成暴露的问题是具有后滞性的，开发人员只能在代码合仓后解决代码问题，其后重新集成重新合仓。显然，这种代码持续集成方式严重影响代码及软件产品的交付速度。

发明内容

基于上述问题，本申请提供了一种代码持续集成方法和代码持续交付方法，以使开发人员能够尽早获知代码持续集成过程中暴露的问题，进而提高代码交付速度。

本申请实施例公开了如下技术方案：

第一方面，本申请提供一种代码持续集成方法，应用于代码评审工具Gerrit，所述方法包括：

接收开发人员提交的代码；

将所述代码输入编译工具，所述代码先后经过所述编译工具和静态扫描工具；

分别接收所述编译工具和所述静态扫描工具对所述代码的第一执行结果和第二执行结果；

根据所述第一执行结果和所述第二执行结果确定所述代码是否可用于持续交付。

可选地，所述代码经过所述静态扫描工具后，还经过单元测试工具；所述方法还包括：

接收所述单元测试工具或行覆盖率统计工具反馈的第三执行结果；当所述第三执行结果由所述单元测试工具反馈时，所述第三执行结果为所述单元测试工具对所述代码的单元测试结果；当所述第三执行结果由所述行覆盖率统计工具反馈时，所述第三执行结果为所述行覆盖率统计工具对所述单元测试工具所执行测试的行覆盖率的统计结果；

所述根据所述第一执行结果和所述第二执行结果确定所述代码是否可用于持续交付，具体包括：

根据所述第一执行结果、所述第二执行结果和所述第三执行结果确定所述代码是否可用于持续交付。

可选地，上述方法还包括：

接收所述代码的人工评审结果；

所述根据所述第一执行结果、所述第二执行结果和所述第三执行结果确定所述代码是否可用于持续交付，具体包括：

根据所述第一执行结果、所述第二执行结果、所述第三执行结果和所述人工评审结果，确定所述代码是否可用于持续交付。

可选地，所述第一执行结果为评分形式；

如果所述编译工具对所述代码编译成功，则所述第一执行结果为第一分数；如果所述编译工具对所述代码编译失败，则所述第一执行结果为第二分数；所述第一分数大于所述第二分数。

可选地，所述第二执行结果为评分形式；

如果所述静态扫描工具确定所述代码不满足第一类条件集中的任意一个条件，则所述第二执行结果为所述第二分数；

如果所述静态扫描工具确定所述代码满足所述第一类条件集中的所有条件，但是不满足所述第二类条件集中的任意一个条件，则所述第二执行结果为第三分数；所述第三分数小于所述第一分数且大于所述第二分数；

如果所述静态扫描工具确定所述代码满足所述第一类条件集中的所有条件，且满足所述第二类条件集中的所有条件，则所述第二执行结果为所述第一分数。

可选地，所述第三执行结果由所述行覆盖率统计工具反馈，且所述第三执行结果为评分形式；

如果所述单元测试工具所执行测试的行覆盖率低于第一比例值，则所述第三执行结果为所述第二分数；

如果所述单元测试工具所执行测试的行覆盖率不低于所述第一比例值且不高于第二比例值，则所述第三执行结果为所述第三分数；

如果所述单元测试工具所执行测试的行覆盖率高于所述第二比例值，则所述第三执行结果为所述第一分数。

可选地，所述人工评审结果为评分形式，所述人工评审结果为不小于所述第二分数且不大于所述第一分数的任意一个分数；所述根据所述第一执行结果、所述第二执行结果、所述第三执行结果和所述人工评审结果，确定所述代码是否可用于持续交付，具体包括：

判断所述第一执行结果、所述第二执行结果、所述第三执行结果和所述人工评审结果是否均不为所述第二分数且至少有一个为所述第一分数，如果是，则确定所述代码可用于持续交付；如果否，则确定所述代码不可用于持续交付。

可选地，所述编译工具和所述静态扫描工具与所述代码所属的代码工程类型相关；

当所述代码属于java类代码工程时，所述编译工具为Maven，所述静态扫描工具为fireline；

当所述代码属于node.js代码工程时，所述编译工具为node，所述静态扫描工具为tslint和SonarQube；

当所述代码属于IOS代码工程时，所述编译工具为cocoapods，所述静态扫描工具为oclint、SonarQube和infer；

当所述代码属于android代码工程时，所述编译工具为gradle，所述静态扫描工具为SonarQube和infer。

可选地，所述单元测试工具和所述行覆盖率统计工具与所述代码所属的代码工程类型相关；

当所述代码属于java类代码工程时，所述单元测试工具为Junit，所述行覆盖率统计工具为JACOCO和Cobertura Coverage；

当所述代码属于IOS代码工程时，所述单元测试工具为ocunit2junit，所述行覆盖率统计工具为gcovr；

当所述代码属于android代码工程时，所述单元测试工具为Junit，所述行覆盖率统计工具为JACOCO和Cobertura Coverage。

第二方面，本申请提供一种代码持续交付方法，所述方法包括：

将代码进行合并；所述代码为由权利要求1-9任一项所述的方法确定的可用于持续交付的代码；所述代码合并后生成所述代码构建的生成物；

将所述生成物上传至Nexus搭建的产品库；

触发Jenkins部署的JOB项目，利用所述JOB项目将所述生成物部署到类线上环境，实现所述代码的持续交付。

可选地，所述方法还包括：

将所述生成物上传至云端镜像仓库；

所述触发Jenkins部署的JOB项目，具体包括：

当检测到所述生成物上传至所述产品库以及所述云端镜像仓库后，触发Jenkins部署的JOB项目。

相较于现有技术，本申请具有以下有益效果：

本申请提供的代码持续集成方法应用于代码评审工具Gerrit，首先接收开发人员提交的代码；其后将代码输入编译工具，代码先后通过编译工具和静态扫描工具；Gerrit分别接收编译工具和静态扫描工具对代码的第一执行结果和第二执行结果；最终，根据第一执行结果和第二执行结果确定代码是否可用于持续交付。

该方法中，代码经过编译工具和静态扫描工具后，开发人员即可通过Gerrit平台获知编译工具反馈的第一执行结果和静态扫描工具反馈的第二执行结果。可见，该方法能够使开发人员在代码持续集成的过程中实时获知代码的问题，不必等到代码合并到远程代码仓库后再确认问题。从而，相比于现有技术，该方法能够提早暴露代码持续集成过程中发现的问题，使得开发人员得以及时对代码进行修正，进而有效提升了代码及软件产品的交付速度。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种代码持续集成方法的流程图；

图2为本申请实施例提供的另一种代码持续集成方法的流程图；

图3为本申请实施例提供的一种代码持续交付方法的流程图。

具体实施方式

正如前文描述，目前的代码持续集成方法，开发人员无法在代码合并到远程的代码仓库之前，获知代码持续集成的问题。只有等到代码合并到远程的代码仓库之后，开发人员才有可能接收到关于代码问题的反馈邮件，或者在平台上获知代码问题。

然而，带有持续集成问题的代码是无法应用于持续交付的，因此，存在问题的代码需要经过开发人员进行相应的修改。但是由于开发人员无法及时尽快地获知代码问题，因此，对于代码的修改操作较为迟滞，影响代码的持续交付速度和效率。

发明人经过研究发现，如果开发人员能够尽快获知代码持续集成的问题，并及时修正问题，则可以提高代码持续交付的速度和效率。基于此，发明人提供了一种代码持续集成方法和代码持续交付方法。

本申请提供的代码持续集成方法在代码合并到远程的代码仓库之前，通过Gerrit平台向代码开发人员及时提供编译工具和静态扫描工具对代码的执行结果，并告知代码开发人员其提交的代码是否可用于持续交付，从而开发人员能够根据编译工具以及静态工具反馈的执行结果及时获知代码持续集成的问题并进行修改解决，进而更快地提交修改好的代码用于持续交付。

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

第一实施例

参见图1，该图为本申请实施例提供的一种代码持续集成方法的流程图。

如图1所示，本实施例提供的代码持续集成方法，包括：

步骤101：接收开发人员提交的代码。

本实施例中提供的代码持续集成方法应用于Gerrit工具。Gerrit是一种代码评审工具，开源，且安装操作简单，使用便捷。本实施例中，Gerrit内集成了Git模块，Git模块可用于对源代码进行管理。内置Git模块的Gerrit工具能够满足分布式大规模开发的需求，并能够有效节省Git服务器搭建和维护的成本。

对于Git模块来说，在进行代码管理时，通常关系到代码管理层面的两个概念，一个是本地的代码仓库，另一个是远程的代码仓库。在本地环境编写好的代码均隶属于本地的代码仓库，开发人员编写好的代码经过持续集成过程后，可用于持续交付的代码需要通过合并(merge)到远程的代码仓库，其后才能够与其他开发人员编写的代码融合起来，最终完成代码的开发任务。

本步骤中，由代码的开发人员向Gerrit平台提交编写好的代码用于后续进行持续集成。

步骤102：将所述代码输入编译工具，所述代码先后经过所述编译工具和静态扫描工具。

在本实施例中，代码持续集成至少要经过两个环节，第一个环节是编译，由编译工具执行，编译的目的主要是对代码的逻辑性进行检验；第二个环节是静态扫描，有静态扫描工具执行，静态扫描的目的主要是对代码的规范性、安全级别、内存性等方面进行检查。为进行持续集成，本步骤中首先需要将开发人员提交的代码输入到编译工具中。

可以理解的是，本实施例中，对于不同类型代码工程中的代码，可以采用不同的编译工具和静态扫描工具。下面针对不同类型代码工程，提供几个示例。

第一种示例：

当代码属于java类代码工程时，编译工具为Maven，静态扫描工具为fireline。

第二种示例：

当代码属于node.js代码工程时，编译工具为node，静态扫描工具为tslint和SonarQube。

第三种示例：

当代码属于IOS代码工程时，编译工具为cocoapods，静态扫描工具为oclint、SonarQube和infer。

第四种示例：

当代码属于android代码工程时，编译工具为gradle，静态扫描工具为SonarQube和infer。

可选地，本实施例进行持续集成时，第二个环节的执行性依赖于第一个环节的第一执行结果。作为示例，当代码编译不通过时，可以不再将代码输入静态扫描工具，即认为此时无需再进行静态扫描；当代码编译通过时，才有必要将代码继续输入静态扫描工具以便其对代码进行静态扫描并得出第二执行结果。

步骤103：分别接收所述编译工具和所述静态扫描工具对所述代码的第一执行结果和第二执行结果。

当代码经过编译和静态扫描，Gerrit能够分别接收到编译工具和静态扫描工具反馈的执行结果，即第一执行结果和第二执行结果。在本实施例中，第一执行结果和第二执行结果可以以评分的形式呈现，例如：第一执行结果为-2分表示代码编译不通过，第一执行结果为2分表示代码编译通过；第二执行结果为-2分表示代码静态扫描不符合通过条件，第一执行结果为2分表示代码静态扫描符合通过条件。另外，第一执行结果和第二执行结果还可以通过逻辑代数的形式呈现，例如：第一执行结果为1或0时分别表示代码编译通过或不通过；第二执行结果为1或0时分别表示代码静态扫描符合或不符合通过条件。

当然，以上仅为示例，在实际应用中，第一执行结果和第二执行结果还可以以其他形式呈现。因此，本实施例中对于第一执行结果和第二执行结果的具体呈现形式不进行限定。

本实施例中，当Gerrit工具获得编译工具反馈的第一执行结果后，能够提供给开发人员；当Gerrit工具获得静态扫描工具反馈的第二执行结果后，同样也能够提供给开发人员。从而，开发人员能够根据Gerrit工具平台提供的第一执行结果获知代码是否存在编译问题，例如逻辑不正确等；还能够根据Gerrit提供的第二执行结果获知代码是否存在静态扫描问题，例如不够规范、安全级别过低等。

可以理解的是，由于第二个环节的执行性依赖于第一个环节的第一执行结果。因此，当代码编译不通过时，由于不再将代码输入静态扫描工具，因此开发人员仅能获取到第一执行结果；仅当代码编译通过时，开发人员才能通过Gerrit获得第一执行结果以及第二执行结果。

步骤104：根据所述第一执行结果和所述第二执行结果确定所述代码是否可用于持续交付。

需要说明的是，在本实施例中，未确定代码可否用于持续交付之前，不会将代码进行合并。仅当代码确定可以用于持续交付时，代码才有可能进行合并以便实现持续交付。

可以理解的是，由于第一执行结果和第二执行结果可能以多种形式呈现，因此，本步骤中根据第一执行结果和第二执行结果的呈现形式，具体可能存在多种确定代码是否可用于持续交付的实现形式。

为便于理解，下面提供几个示例。

第一种示例：仅当第一执行结果和第二执行结果均为2分时，确定代码可用于持续交付；

第二种示例：仅当第一执行结果和第二执行结果存在至少一个2分且没有任何一个为-2分时，确定代码可用于持续交付；

第三种示例：仅当第一执行结果和第二执行结果均为1时，确定代码可用于持续交付。

当然，可以理解的是，以上仅为本步骤的示例性实现方式。在实际应用中，还可能通过其他方式实现本步骤，因此本实施例中对于步骤104的具体实现形式不进行限定。

以上即为本实施例提供的代码持续集成方法应用于代码评审工具Gerrit，首先接收开发人员提交的代码；其后将代码输入编译工具，代码先后通过编译工具和静态扫描工具；Gerrit分别接收编译工具和静态扫描工具对代码的第一执行结果和第二执行结果；最终，根据第一执行结果和第二执行结果确定代码是否可用于持续交付。

该方法中，代码经过编译工具和静态扫描工具后，开发人员即可通过Gerrit平台获知编译工具反馈的第一执行结果和静态扫描工具反馈的第二执行结果。可见，该方法能够使开发人员在代码持续集成的过程中实时获知代码的问题，不必等到代码合并到远程代码仓库后再确认问题。从而，相比于现有技术，该方法能够提早暴露代码持续集成过程中发现的问题，使得开发人员得以及时对代码进行修正，进而有效提升了代码及软件产品的交付速度。

为了进一步提高用于持续交付的代码的质量，在代码持续交付之前识别和获知的代码问题更加全面和可靠，提高开发人员对代码问题的修改效率，本申请基于前述实施例还提供了另一种代码持续集成方法。该方法在对代码进行持续集成过程中，在执行第一个和第二个环节的基础上，即对代码编译和静态扫描之后，还需对其进行单元测试。另外，该方法不但利用编译工具、静态扫描工具和单元测试工具等对代码进行评审，还在工具评审基础上结合人工的评审结果，从而使得对代码问题的识别更加全面、严谨和可靠。

下面结合实施例和附图对该实施例进行详细描述。

第二实施例

参见图2，该图为本申请实施例提供的另一种代码持续集成方法的流程图。

如图2所示，本实施例提供的代码持续集成方法，包括：

步骤201：接收开发人员提交的代码。

本实施例中，步骤201与前述实施例中步骤101的实现方式相同，关于步骤201的实现方式可参见前述实施例，此处不再赘述。

步骤202：将所述代码输入编译工具，所述代码先后经过所述编译工具、静态扫描工具和单元测试工具。

在本实施例中，代码持续集成至少要经过三个环节，第一个环节是编译，由编译工具执行，编译的目的主要是对代码的逻辑性进行检验；第二个环节是静态扫描，有静态扫描工具执行，静态扫描的目的主要是对代码的规范性、安全级别、内存性等方面进行检查；第三个环节是单元测试，由单元测试工具执行，单元测试的目的主要是对代码中的方法、函数、类等内容的正确性进行验证。为进行持续集成，本步骤Gerrit工具首先需要将开发人员提交的代码输入到编译工具，经过编译后，代码输入静态扫描工具；经过静态扫描后，代码输入单元测试工具。

可以理解的是，本实施例中，对于不同类型代码工程中的代码，可以采用不同的编译工具、静态扫描工具以及单元测试工具。前述实施例中对不同类型代码工程的代码进行持续集成时所使用的编译工具和静态扫描工具分别进行了举例介绍。下面，针对不同类型代码工程，提供几种示例性的单元测试工具。

如果代码属于java类代码工程，可以采用Junit作为单元测试工具；如果代码属于IOS代码工程，可以采用ocunit2junit作为单元测试工具；如果代码属于android代码工程，也可以采用Junit作为单元测试工具。

可选地，本实施例进行代码持续集成过程中，第二个环节的执行性依赖于第一个环节的第一执行结果；第三个环节的执行性依赖于第二个环节的第二执行结果。例如，当代码编译不通过时，无需再将代码输入至静态扫描工具；当代码静态扫描不满足静态测试条件时，无需再将代码输入至单元测试工具。

步骤203：分别接收所述编译工具和所述静态扫描工具对所述代码的第一执行结果和第二执行结果。

在本实施例中，第一执行结果和第二执行结果分别以评分的形式呈现。下面提供了编译工具和静态扫描工具对代码进行持续集成的具体评分策略。

对于第一执行结果：

(1)如果所述编译工具对所述代码编译成功，则所述第一执行结果为第一分数；

(2)如果所述编译工具对所述代码编译失败，则所述第一执行结果为第二分数。

对于第二执行结果：

(1)如果所述静态扫描工具确定所述代码不满足第一类条件集中的任意一个条件，则所述第二执行结果为第二分数；

(2)如果所述静态扫描工具确定所述代码满足所述第一类条件集中的所有条件，但是不满足所述第二类条件集中的任意一个条件，则所述第二执行结果为第三分数；

(3)如果所述静态扫描工具确定所述代码满足所述第一类条件集中的所有条件，且满足所述第二类条件集中的所有条件，则所述第二执行结果为第一分数。

在本实施例中，第一分数大于第三分数，第三分数大于第二分数。例如，第一分数为2分，第二分数为-2分，第三分数为-1分。可以理解的是，第一分数、第二分数以及第三分数还可设置为其他具体的分数。

在以上示例的评分策略中，第一类条件集可以理解为强制条件集，强制条件集中包含多个强制条件。例如：代码中的命名不以下划线或美元符号开始；代码中的命名不以下划线或美元符号结束。

第二类条件集可以理解为推荐条件集，推荐条件集中包含多个推荐条件。例如：模块、接口、类、方法使用了设计模式，在命名时体现出具体设计模式。

可以理解的是，在实际应用中，评分策略和评分分数档位、分值均可以根据实际需求相应变化。因此，以上评分策略仅为示例，本实施例中对于以评分形式呈现的第一执行结果和第二执行结果的评分策略不进行具体限定。

步骤204：接收所述单元测试工具或行覆盖率统计工具反馈的第三执行结果。

本实施例中，为提高用于持续交付的代码的质量，还可以对持续集成的具体环节覆盖率进行统计评分，例如，由行覆盖率统计工具对单元测试工具执行的单元测试进行行覆盖率统计。在具体实现时，可以由行覆盖率统计工具对单元测试工具执行的单元测试结果中相关文件进行行覆盖率的统计。例如，通过行覆盖率统计，确定单元测试工具实际对100行代码中的60行代码进行了单元测试，则单元测试的行覆盖率为60％。

可以理解的是，行覆盖率统计工具与所述代码所属的代码工程类型相关，例如：当代码属于java类代码工程时，行覆盖率统计工具为JACOCO和Cobertura Coverage；当代码属于IOS代码工程时，行覆盖率统计工具为gcovr；当代码属于android代码工程时，行覆盖率统计工具为JACOCO和Cobertura Coverage。

本实施例中，在对代码质量进行评价时，不但需要参照持续集成的第一个环节和第二个环节的评分，还需要依据第三个环节的评分，即第三执行结果。

第三执行结果可能有两种反馈渠道，一种是由单元测试工具反馈，第三执行结果即为单元测试工具对所述代码的单元测试结果；另一种是由行覆盖率统计工具反馈，第三执行结果即为行覆盖率统计工具对单元测试工具所执行测试的行覆盖率的统计结果。

下面针对上述第二种反馈渠道，对评分形式呈现的第三执行结果提供了一种示例性的评分策略。

(1)如果所述单元测试工具所执行测试的行覆盖率低于第一比例值，则所述第三执行结果为第二分数；

(2)如果所述单元测试工具所执行测试的行覆盖率不低于所述第一比例值且不高于第二比例值，则所述第三执行结果为第三分数；

(3)如果所述单元测试工具所执行测试的行覆盖率高于所述第二比例值，则所述第三执行结果为第一分数。

在本实施例中，第一比例值小于第二比例值。作为一示例，第一比例值为50％，第二比例值为70％。当然，可以理解的是，第一比例值和第二比例值均可以根据实际需求设定，此处对于第一比例值和第二比例值的具体数值不加以限定。

可以理解的是，在以上评分策略中，由于第一比例值小于第二比例值，当单元测试工具所执行测试的行覆盖率越高，单元测试质量越高，对应代码质量筛查越严谨，此时给予代码的第三执行结果评分较高；而当单元测试工具所执行测试的行覆盖率越低，单元测试质量越低，对应代码质量筛查较为不严谨，此时给予代码的第三执行结果评分较低。

可以理解的是，在实际应用中，评分策略和评分分数档位、分值均可以根据实际需求相应变化。因此，以上评分策略仅为示例，本实施例中对于以评分形式呈现的第三执行结果的评分策略不进行具体限定。

步骤205：接收所述代码的人工评审结果。

本实施例中，不但由持续集成的各个工具对代码反馈执行结果(即评分)，还接收人工评审结果。人工评审结果为评分形式，人工评审结果评分区间与工具评分区间相互对应。例如，第一执行结果、第二执行结果、第三执行结果均为第二分数至第一分数区间内的分数，则人工评审结果也可能为不小于所述第二分数且不大于所述第一分数的任意一个分数。

对于代码的人工评审可以由代码方面的资深人员执行，例如架构师等。对于代码的人工评审角度可能与工具评审角度相同，也可能与工具评审角度不同。

显然，通过人工评审和各个持续集成工具的工具评审，能够对代码质量进行更为全面更为完善的筛查，从而使得对代码问题的识别更加全面、严谨和可靠。

需要说明的是，本实施例中，步骤205可以先于其他步骤202-204执行，也可以在步骤202-204之后执行，当然也可以与步骤202-204中任意一个步骤同时执行。此处对于步骤205相对于其他步骤202-204的执行顺序不进行限定。

步骤206：根据所述第一执行结果、所述第二执行结果、所述第三执行结果和所述人工评审结果，确定所述代码是否可用于持续交付。

基于前述评分策略的描述，沿用其示例，此处还提供了本步骤的一种具体实现方式：

判断所述第一执行结果、所述第二执行结果、所述第三执行结果和所述人工评审结果是否均不为第二分数且至少有一个为第一分数，如果是，则确定所述代码可用于持续交付；如果否，则确定所述代码不可用于持续交付。

以上即为本申请实施例提供的代码持续集成方法。该方法不但利用编译工具、静态扫描工具和单元测试工具等对代码进行评审，还在工具评审基础上结合人工的评审结果，从而使得对代码问题的识别更加全面、严谨和可靠。另外，开发人员能够在代码合并之前通过Gerrit工具获知第一执行结果、第二执行结果、第三执行结果以及人工评审结果，从而便于及时修改上述结果反映出的代码问题，进而将代码质量提高后用于持续交付。由此可将，该方法也能够有效提高代码持续交付的速度和效率。

可以理解的是，当Gerrit确定代码不可用于持续交付后，由开发人员对代码进行对应的修改，并重新提交至Gerrit平台，从而，由Gerrit工具再次采用上述实施例描述的代码持续集成方法对代码进行持续集成，直至提交的代码符合步骤206的描述，确定为可用于持续交付的代码。

此处，本申请还介绍一种基于Java开发的持续集成工具Jenkins，该工具用于监控持续重复的工作，使用简单并且可添加大量插件，集成性能优良。前述实施例提供的代码持续集成方法中，具体可以依托于Jenkins工具实现。

Jenkins工具上可以部署承载着执行持续集成的各个环节的多个不同JOB(又称项目)，JOB通过配置实现具体功能。例如，第一JOB通过配置实现对代码的编译；第二JOB通过配置实现对代码的静态扫描；第三JOB通过配置实现对代码的单元测试等。

基于前述实施例提供的代码持续集成方法，相应地，本申请还提供一种代码持续交付方法。下面结合实施例和附图对该方法进行详细描述。

第三实施例

参见图3，该图为本申请实施例提供的一种代码持续交付方法的流程图。

如图3所示，本实施例提供的代码持续交付方法，包括：

步骤301：将代码进行合并，代码合并后生成所述代码构建的生成物。

根据前文描述，开发人员编写好的代码经过持续集成过程后，可用于持续交付的代码需要通过合并(merge)到远程的代码仓库，其后才能够与其他开发人员编写的代码融合起来，最终完成代码的开发任务。

本实施例中，步骤301所指的代码，具体是根据前述实施例确定的可用于持续交付的代码。

例如，采用第二实施例方法，第一执行结果、所述第二执行结果、所述第三执行结果和所述人工评审结果均不为第二分数(例如-2分)且至少有一个为第一分数(例如2分)，则提交的代码为可用于持续交付的代码。本步骤即是将该代码进行合并。具体地，可以是将代码合并到远程的代码仓库中用于后续与其他开发人员编写的代码融合起来。

由于合并的代码是经过持续集成的代码，当其合并后发布到代码工程的各个分支后，能够自动地进行代码构建，并生成代码构建的生成物。

步骤302：将所述生成物上传至Nexus搭建的产品库。

Nexus是Maven(一种编译工具)的私服仓库管理工具。当生成物上传到产品库后，表明该生成物需要接下来部署到类线上环境中。本实施例中，预先在Jenkins部署一个特殊的JOB，该JOB的功能时将生成物部署到类线上环境。该JOB能够在生成物上传到产品库后被触发，启动其自身功能。

步骤303：触发Jenkins部署的JOB项目，利用所述JOB项目将所述生成物部署到类线上环境，实现所述代码的持续交付。

以上即为本申请实施例提供的代码持续交付方法，该方法由于进行持续交付的代码是通过前述代码集成方法确定并提供的，因此，代码质量较高，不易在代码合并后发现持续集成的质量问题。由此，能够有效提高代码交付的效率和速度。

可以理解的是，在实际应用中，代码的生成物还有可能被需要应用于其他环境中。为便利于此，本申请提供的代码持续交付方法还可以在合并且生成生成物之后，将生成物上传到云端镜像仓库，例如阿里云的docker镜像仓库。通过上传生成物到云端镜像仓库，能够便于将该代码生成物应用于其他任意环境中。这一操作可以在利用JOB将生成物部署到类线上环境之前执行，因此本实施例中，步骤303还可以具体为：当检测到所述生成物上传至所述产品库以及所述云端镜像仓库后，触发Jenkins部署的JOB项目。

经过对代码集成方法和代码交付方法的描述，不难发现，本实施例提供的技术方案采用多种开源的工具，成本低，且可结合代码开发项目团体自身的水平和开发模式进行定制。代码集成和代码交付的流程均是可持续、自动化、可定制化且可扩展的，同时也是可记录、可重复、可追溯的。通过对多种开源工具的结合使用和严谨编排，有效提升了代码和产品交付的速度和自动化程度。因此，本申请提供的代码集成方法和代码交付方法具有十分重要的意义。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。以上所描述的设备及系统实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元提示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述，仅为本申请的一种具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应该以权利要求的保护范围为准。

Claims (11)

1.一种代码持续集成方法，其特征在于，应用于代码评审工具Gerrit，所述方法包括：

接收开发人员提交的代码；

将所述代码输入编译工具，所述代码先后经过所述编译工具和静态扫描工具；

分别接收所述编译工具和所述静态扫描工具对所述代码的第一执行结果和第二执行结果；

根据所述第一执行结果和所述第二执行结果确定所述代码是否可用于持续交付。

2.根据权利要求1所述的代码持续集成方法，其特征在于，所述代码经过所述静态扫描工具后，还经过单元测试工具；所述方法还包括：

接收所述单元测试工具或行覆盖率统计工具反馈的第三执行结果；当所述第三执行结果由所述单元测试工具反馈时，所述第三执行结果为所述单元测试工具对所述代码的单元测试结果；当所述第三执行结果由所述行覆盖率统计工具反馈时，所述第三执行结果为所述行覆盖率统计工具对所述单元测试工具所执行测试的行覆盖率的统计结果；

所述根据所述第一执行结果和所述第二执行结果确定所述代码是否可用于持续交付，具体包括：

根据所述第一执行结果、所述第二执行结果和所述第三执行结果确定所述代码是否可用于持续交付。

3.根据权利要求2所述的代码持续集成方法，其特征在于，还包括：

接收所述代码的人工评审结果；

所述根据所述第一执行结果、所述第二执行结果和所述第三执行结果确定所述代码是否可用于持续交付，具体包括：

根据所述第一执行结果、所述第二执行结果、所述第三执行结果和所述人工评审结果，确定所述代码是否可用于持续交付。

4.根据权利要求3所述的代码持续集成方法，其特征在于，所述第一执行结果为评分形式；

如果所述编译工具对所述代码编译成功，则所述第一执行结果为第一分数；如果所述编译工具对所述代码编译失败，则所述第一执行结果为第二分数；所述第一分数大于所述第二分数。

5.根据权利要求4所述的代码持续集成方法，其特征在于，所述第二执行结果为评分形式；

如果所述静态扫描工具确定所述代码不满足第一类条件集中的任意一个条件，则所述第二执行结果为所述第二分数；

如果所述静态扫描工具确定所述代码满足所述第一类条件集中的所有条件，但是不满足所述第二类条件集中的任意一个条件，则所述第二执行结果为第三分数；所述第三分数小于所述第一分数且大于所述第二分数；

如果所述静态扫描工具确定所述代码满足所述第一类条件集中的所有条件，且满足所述第二类条件集中的所有条件，则所述第二执行结果为所述第一分数。

6.根据权利要求5所述的代码持续集成方法，其特征在于，所述第三执行结果由所述行覆盖率统计工具反馈，且所述第三执行结果为评分形式；

如果所述单元测试工具所执行测试的行覆盖率低于第一比例值，则所述第三执行结果为所述第二分数；

如果所述单元测试工具所执行测试的行覆盖率不低于所述第一比例值且不高于第二比例值，则所述第三执行结果为所述第三分数；

如果所述单元测试工具所执行测试的行覆盖率高于所述第二比例值，则所述第三执行结果为所述第一分数。

7.根据权利要求6所述的代码持续集成方法，其特征在于，所述人工评审结果为评分形式，所述人工评审结果为不小于所述第二分数且不大于所述第一分数的任意一个分数；所述根据所述第一执行结果、所述第二执行结果、所述第三执行结果和所述人工评审结果，确定所述代码是否可用于持续交付，具体包括：

判断所述第一执行结果、所述第二执行结果、所述第三执行结果和所述人工评审结果是否均不为所述第二分数且至少有一个为所述第一分数，如果是，则确定所述代码可用于持续交付；如果否，则确定所述代码不可用于持续交付。

8.根据权利要求1所述的代码持续集成方法，其特征在于，所述编译工具和所述静态扫描工具与所述代码所属的代码工程类型相关；

当所述代码属于java类代码工程时，所述编译工具为Maven，所述静态扫描工具为fireline；

当所述代码属于node.js代码工程时，所述编译工具为node，所述静态扫描工具为tslint和SonarQube；

当所述代码属于IOS代码工程时，所述编译工具为cocoapods，所述静态扫描工具为oclint、SonarQube和infer；

当所述代码属于android代码工程时，所述编译工具为gradle，所述静态扫描工具为SonarQube和infer。

9.根据权利要求2-7任一项所述的代码持续集成方法，其特征在于，所述单元测试工具和所述行覆盖率统计工具与所述代码所属的代码工程类型相关；

当所述代码属于java类代码工程时，所述单元测试工具为Junit，所述行覆盖率统计工具为JACOCO和Cobertura Coverage；

当所述代码属于IOS代码工程时，所述单元测试工具为ocunit2junit，所述行覆盖率统计工具为gcovr；

当所述代码属于android代码工程时，所述单元测试工具为Junit，所述行覆盖率统计工具为JACOCO和Cobertura Coverage。

10.一种代码持续交付方法，其特征在于，所述方法包括：

将代码进行合并；所述代码为由权利要求1-9任一项所述的方法确定的可用于持续交付的代码；所述代码合并后生成所述代码构建的生成物；

将所述生成物上传至Nexus搭建的产品库；

触发Jenkins部署的JOB项目，利用所述JOB项目将所述生成物部署到类线上环境，实现所述代码的持续交付。

11.根据权利要求10所述的代码持续交付方法，其特征在于，所述方法还包括：

将所述生成物上传至云端镜像仓库；

所述触发Jenkins部署的JOB项目，具体包括：

当检测到所述生成物上传至所述产品库以及所述云端镜像仓库后，触发Jenkins部署的JOB项目。