本发明涉及软件工程技术领域，特别是涉及一种代码持续交付的方法。
背景技术：
代码持续交付是一种软件工程手法，让软件产品在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以发布的状况。持续交付的目标在于让软件的构建、测试与发布变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。持续交付在持续集成的基础上，将集成后的代码部署到“类线上环境”中，即部署到贴近真实运行的环境中。
代码持续交付过程中需要持续集成代码，软件研发团队的成员经常需要集成他们的代码编写工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次代码集成都通过自动化的构建，通过各种流程来验证代码。从每次软件开发人员提交代码到合仓，每次构建流程的时间成本都客观存在，然而在不同的软件生命周期、客户现场的真实需求、项目开发的实际进度等不同情况下，过于滞后的构建时间会严重影响代码和软件的交付时间。
技术实现要素：
本发明的目的在于提供一种代码持续交付的方法，有效提高代码交付的速度。
实现上述目的的技术方案是：
一种代码持续交付的方法，使用容器安装代码持续交付过程中的各种工具，包括：
接收开发人员提交的代码；
将所述代码输入编译工具进行编译，编译处理后的所述代码经过静态扫描工具；
接收所述静态扫描工具对所述代码的第一执行结果；
根据第一执行结果判断所述代码是否可用于持续交付；
将可用于持续交付的代码持续交付。
优选的，还包括：
编译处理后的所述代码还经过单元测试工具或者行覆盖率统计工具；
接收所述单元测试工具或所述行覆盖率统计工具反馈的第二执行结果；当所述第二执行结果由所述单元测试工具反馈时，所述第二执行结果为所述单元测试工具对所述代码的单元测试结果；当所述第二执行结果由所述行覆盖率统计工具反馈时，所述第二执行结果为所述行覆盖率统计工具对所述代码所执行测试的行覆盖率的统计结果；
根据所述第一执行结果和所述第二执行结果判断所述代码是否可用于持续交付。
优选的，还包括：
编译处理后的所述代码或者满足持续交付并部署后的代码，经过自定义测试脚本或者系统测试，获得第三执行结果。
优选的，系统测试分为功能测试和健壮性测试。
优选的，还包括：
编译处理后的所述代码经过人工评审，获得第四执行结果；
根据所述第一执行结果、所述第二执行结果、所述第三执行结果和第四执行结果，判断所述代码是否可用于持续交付。
优选的，所述编译工具为maven(项目对象模型)，所述静态扫描工具为sonarqube(管理源代码质量的一个开源平台)；所述单元测试工具为junit(一个单元测试框架)，所述行覆盖率统计工具为jacoco(一个开源的代码覆盖率工具)和coberturacoverage(一种测试覆盖率报告方案)；所述人工评审使用gerrit(一种开放源代码的代码审查软件，使用网页界面)。
优选的，所述的容器为docker(一个开源的应用容器引擎)。
优选的，第一执行结果显示静态代码规则指标，根据事先定义的阈值，如果代码质量问题大于阈值判断本次代码不可用于持续交付，反之本次代码可用于持续交付。
优选的，第二执行结果显示单元测试工具或者行覆盖率统计工具测试结果，根据是否存在致命性错误和严重错误，存在判断本次代码不可用于持续交付，反之本次代码可用于持续交付。
优选的，第三执行结果显示自定义测试策略执行结果，根据测试命中的问题数量和事先定义的问题数量阈值，如果测试命中的问题数量大于阈值判断本次代码不可用于持续交付，反之本次代码可用于持续交付；
第四执行结果显示审查人员对于本次代码的代码复查，如果审查人员认为本次代码的逻辑或者代码编写规范不符合标准，则不可用于持续交付，反之，可用于持续交付。
本发明的有益效果是：本发明通过在容器中安装诸如编译工具等各种工具，然后进行执行，获得至少一个执行结果，根据执行结果判断代码是否可用于持续交付，以使开发人员能够尽早获知代码持续集成过程中暴露的问题，进而提高代码交付速度。
附图说明
图1是本发明的代码持续交付的方法的流程图；
图2是本发明中容器更新的示意图；
图3是本发明中持续交付产生文档保存的示意图。
具体实施方式
下面将结合附图对本发明作进一步说明。
本发明的代码持续交付的方法，使用容器安装代码持续交付过程中的各种工具，本实施例中采用容器为docker。
参阅图2，通过docker下载合适的持续交付工具的镜像或者构建适用于自己项目的交付工具镜像，通过镜像创建容器，运行容器。通过jenkins(一种开源的持续集成工具)容器创建构建任务，jenkins集成静态代码扫描工具sonarqube需要安装sonarqubescanner(jenkins集成sonarqube所需插件)，配置sonarqube容器的地址端口和sonarqube的token(计算机身份认证中的一种方式)。sonarqube中可以直接配置需要执行的代码扫描规则，如项目前期定义扫描规则为类名函数名是否规范，项目后期定义代码重复率检查等。可直接定义扫描规则无或者新建无静态扫描的jenkins任务完成跳过静态扫描。jenkins集成单元测试工具junit需要安装junitplugin(jenkins集成junit所需插件)，行覆盖率统计工具jacoco需要安装jacocoplugin(jenkins集成jacoco所需插件)。jenkins集成gerrit需要gerrittriggerplugin(jenkins集成gerrit所需插件)。单元测试完后生成测试报告。可直接定义测试用例无或者新建无单元测试的jenkins任务完成跳过单元测试。在gerrit里创建jenkins用户，并且为jenkins生成ssh(一种为远程登录会话和其他网络服务提供安全性的协议)密钥，将公钥添加到jenkins的gerrit帐户上。gerrit配置代码审核需要两步：jenkins自动验证和人工评审：将jenkins用户添加到none-interactive-group(通过gerrit接口进行操作的用户组)里并将其赋有审查验证功能，可直接赋予jenkins用户不用审核，直接同步部署代码。
参见图3，持续交付过程中，产生的文档统一保存在同一数据库容器中，以方便分析代码质量等各种问题。数据库容器选择mysql(一个小型关系型数据库管理系统)容器，静态代码扫描工具sonarqube等默认保存数据库即为mysql，其他默认数据库不同的，如gerrit的默认数据库为h2(一个嵌入式数据库)，可配置保存数据库为mysql。
请参阅图1，本发明的代码持续交付的方法包括下列步骤：
一、接收开发人员提交的代码。
二、将代码输入编译工具进行编译，编译处理后的代码经过静态扫描工具。
三、接收静态扫描工具对代码的第一执行结果。
四、根据第一执行结果判断所述代码是否可用于持续交付。
五、将可用于持续交付的代码持续交付。
另外，可以在第三步的前后，将编译处理后的代码还经过单元测试工具或者行覆盖率统计工具，然后接收所述单元测试工具或所述行覆盖率统计工具反馈的第二执行结果；当所述第二执行结果由所述单元测试工具反馈时，所述第二执行结果为所述单元测试工具对所述代码的单元测试结果；当所述第二执行结果由所述行覆盖率统计工具反馈时，所述第二执行结果为所述行覆盖率统计工具对所述代码所执行测试的行覆盖率的统计结果。
然后，上述第四步修改为：根据所述第一执行结果和所述第二执行结果判断所述代码是否可用于持续交付。
另外，可以在第三步之后，增加一步骤：编译处理后的代码或者满足持续交付并部署后的代码，经过自定义测试脚本或者系统测试，获得第三执行结果。系统测试分为功能测试和健壮性测试。自定义测试脚本或者系统测试可根据实际情况决定在代码部署之前还是之后集成，测试完后生成测试报告。
另外，可以在第三步之后，增加一步骤：编译处理后的代码经过人工评审，获得第四执行结果。
然后，上述第四步修改为：根据所述第一执行结果、所述第二执行结果、所述第三执行结果和第四执行结果，判断代码是否可用于持续交付。第一执行结果显示静态代码规则指标，如复杂度、覆盖率、重复、问题、可维护性、可靠性等，根据事先定义的阈值，如果代码质量问题大于阈值判断本次代码不可用于持续交付，反之本次代码可用于持续交付；第二执行结果显示单元测试工具或者行覆盖率统计工具测试结果，根据是否存在致命性错误和严重错误，存在判断本次代码不可用于持续交付，反之本次代码可用于持续交付；第三执行结果显示自定义测试策略执行结果，根据测试命中的问题数量和事先定义的问题数量阈值，如果测试命中的问题数量大于阈值判断本次代码不可用于持续交付，反之本次代码可用于持续交付；第四执行结果显示审查人员对于本次代码的代码复查，如果审查人员认为本次代码的逻辑或者代码编写规范不符合标准，则不可用于持续交付，反之，可用于持续交付。第一执行结果、所述第二执行结果、所述第三执行结果和第四执行结果独立，互不影响。
综上，在项目交付过程中根据实际需求变换代码持续交付策略，如在不同的软件开发周期中，替换静态扫描规则和单元测试；快速修改客户使用过程中遇到的问题，将系统测试放在代码部署之后；开发过程中代码功能性重复，减少代码评审环节等，从而提高持续交付发现代码问题的效率和减少持续构建的时间，进而有效的提高代码及软件产品的交付速度。
以上实施例仅供说明本发明之用，而非对本发明的限制，有关技术领域的技术人员，在不脱离本发明的精神和范围的情况下，还可以作出各种变换或变型，因此所有等同的技术方案也应该属于本发明的范畴，应由各权利要求所限定。
1.一种代码持续交付的方法，使用容器安装代码持续交付过程中的各种工具，其特征在于，包括：
接收开发人员提交的代码；
将所述代码输入编译工具进行编译，编译处理后的所述代码经过静态扫描工具；
接收所述静态扫描工具对所述代码的第一执行结果；
根据第一执行结果判断所述代码是否可用于持续交付；
将可用于持续交付的代码持续交付。
2.根据权利要求1所述的代码持续交付的方法，其特征在于，还包括：
编译处理后的所述代码还经过单元测试工具或者行覆盖率统计工具；
接收所述单元测试工具或所述行覆盖率统计工具反馈的第二执行结果；当所述第二执行结果由所述单元测试工具反馈时，所述第二执行结果为所述单元测试工具对所述代码的单元测试结果；当所述第二执行结果由所述行覆盖率统计工具反馈时，所述第二执行结果为所述行覆盖率统计工具对所述代码所执行测试的行覆盖率的统计结果；
根据所述第一执行结果和所述第二执行结果判断所述代码是否可用于持续交付。
3.根据权利要求2所述的代码持续交付的方法，其特征在于，还包括：
编译处理后的所述代码或者满足持续交付并部署后的代码，经过自定义测试脚本或者系统测试，获得第三执行结果。
4.根据权利要求3所述的代码持续交付的方法，其特征在于，系统测试分为功能测试和健壮性测试。
5.根据权利要求3所述的代码持续交付的方法，其特征在于，还包括：
编译处理后的所述代码经过人工评审，获得第四执行结果；
根据所述第一执行结果、所述第二执行结果、所述第三执行结果和第四执行结果，判断所述代码是否可用于持续交付。
6.根据权利要求5所述的代码持续交付的方法，其特征在于，所述编译工具为maven，所述静态扫描工具为sonarqube；所述单元测试工具为junit，所述行覆盖率统计工具为jacoco和coberturacoverage；所述人工评审使用gerrit。
7.根据权利要求1所述的代码持续交付的方法，其特征在于，所述的容器为docker。
8.根据权利要求1所述的代码持续交付的方法，其特征在于，第一执行结果显示静态代码规则指标，根据事先定义的阈值，如果代码质量问题大于阈值判断本次代码不可用于持续交付，反之本次代码可用于持续交付。
9.根据权利要求2所述的代码持续交付的方法，其特征在于，第二执行结果显示单元测试工具或者行覆盖率统计工具测试结果，根据是否存在致命性错误和严重错误，存在判断本次代码不可用于持续交付，反之本次代码可用于持续交付。
10.根据权利要求5所述的代码持续交付的方法，其特征在于，第三执行结果显示自定义测试策略执行结果，根据测试命中的问题数量和事先定义的问题数量阈值，如果测试命中的问题数量大于阈值判断本次代码不可用于持续交付，反之本次代码可用于持续交付；
第四执行结果显示审查人员对于本次代码的代码复查，如果审查人员认为本次代码的逻辑或者代码编写规范不符合标准，则不可用于持续交付，反之，可用于持续交付。
技术总结