CN113703730A - 持续集成方法、装置、计算机设备及存储介质 - Google Patents

Abstract

本发明涉及人工智能技术，提供一种持续集成方法，方法部分包括：开发者推送代码到代码库(GitLab)中，触发自动化集成工具(Jenkins)构建持续集成任务，同时自动进行代码质量检查，再通过项目管理工具(Maven)编译、打包，生成集成包(jar包)，然后把集成包(jar包)添加到应用容器引擎(Docker)的基础镜像中，以生成新镜像文件，并将新镜像文件推送(push)到私有镜像库中，应用容器引擎(Docker)从私有镜像库中拉取新镜像文件，启动容器，以实现自动化编译打包、及代码质量检查，持续集成中的任何一个环节都是自动完成的，无需太多的人工干预，有利于减少重复过程以节省时间、费用和工作量。

Description

持续集成方法、装置、计算机设备及存储介质

技术领域

本发明涉及软件开发领域，尤其涉及一种持续集成方法、装置、计算机设备及存储介质。

背景技术

软件应用一般流程是由开发人员进行编码开发，调试，提交测试，由测试人员测试，然后应用包发布，最后由项目实施人员进行项目应用部署，

产品的正常运行，依赖各种配置文件的正确设置(如xml文件/properties文件/其它文件/db/等，需配置相应的ip/端口/名称/地址等)一旦有地方配置有误，运行报错，实施人员则需要反复检查相应的配置文件/环境配置是否正确。若无法检查出问题，则还会需要找相应的开发人员寻找原因，所有的环节都是人工操作，涉及到了开发、测试、运维，不同的工具等。

发明内容

本发明提供一种持续集成方法、装置、计算机设备及存储介质，以解决一旦有地方配置有误，运行报错，实施人员则需要反复检查相应的配置文件/环境配置是否正确。若无法检查出问题，则还会需要找相应的开发人员寻找原因，所有的环节都是人工操作，涉及到了开发、测试、运维，不同的工具等的问题。

一种持续集成方法，包括：

从代码库中拉取代码；

构建持续集成任务；

采用自动化集成工具调用代码检查插件对所述代码进行代码质量检查，得到代码质量检查结果；

若所述代码质量检查结果为检查无误，则采用所述自动化集成工具以及项目管理工具对所述代码进行编译打包，生成集成包；

把所述集成包添加到应用容器引擎的基础镜像中，生成新镜像文件，其中，基础镜像为镜像模板，其包括运行容器所需的数据；

将所述新镜像文件推送至私有镜像库，以完成所述持续集成任务。

一种持续集成装置，包括：

拉取模块，从代码库中拉取代码；

构建模块，构建持续集成任务；

检查模块，采用所述自动化集成工具调用代码检查插件对所述代码进行代码质量检查，得到代码质量检查结果；

打包模块，若所述代码质量检查结果为检查无误，则采用所述自动化集成工具以及项目管理工具对所述代码进行编译打包，生成集成包；

添加模块，把所述集成包添加到应用容器引擎的基础镜像中，生成新镜像文件，其中，基础镜像为镜像模板，其包括运行容器所需的数据；

推送模块，将所述新镜像文件推送至私有镜像库，以完成所述持续集成任务。

一种计算机设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述持续集成方法的步骤。

一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述持续集成方法的步骤。

上述持续集成方法、装置、计算机设备及存储介质，开发者推送代码到代码库(GitLab)中，触发自动化集成工具(Jenkins)构建持续集成任务，同时自动进行代码质量检查，再通过项目管理工具(Maven)编译、打包，生成集成包(jar包)，然后把集成包(jar包)添加到应用容器引擎(Docker)的基础镜像中，以生成新镜像文件，并将新镜像文件推送(push)到私有镜像库中，应用容器引擎(Docker)从私有镜像库中拉取新镜像文件，启动容器，以实现自动化编译打包、及代码质量检查，持续集成中的任何一个环节都是自动完成的，无需太多的人工干预，有利于减少重复过程以节省时间、费用和工作量。

附图说明

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

图1是本发明一实施例中持续集成方法的一流程图；

图2是本发明一实施例中持续集成方法的另一流程图；

图3是本发明一实施例中持续集成方法的另一流程图；

图4是本发明一实施例中持续集成方法的另一流程图；

图5是本发明一实施例中持续集成方法的另一流程图；

图6是本发明一实施例中持续集成装置的一原理框图；

图7是本发明一实施例中计算机设备的一示意图。

具体实施方式

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

本发明提供的持续集成方法，本发明所采用的持续集成服务器可以是独立的服务器，也可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(Content Delivery Network，CDN)、以及大数据和人工智能平台等基础云计算服务的云服务器。

在一实施例中，如图1所示，提供一种持续集成方法，具体地本方案提供一种基于应用程序的持续集成方法，包括如下步骤：

S10:从代码库中拉取代码；

开发者将代码推送(push)至代码库(GitLab)中，持续集成服务器可从代码库中获取代码。

配置Web hook地址到代码库(GitLab)中，开发人员通过提交业务代码/或合并代码，以触发在自动化集成工具(Jenkins)中定义创建持续集成任务。

钩子插件(Wehook)是一种web回调或者http的push API(ApplicationProgramming Interface，应用程序编程接口)，钩子插件(Wehook)是向APP或者其他应用提供实时信息的一种方式，钩子(Wehook)在数据产生时立即发送数据。

本方案可以采用Jenkins的钩子插件(WeHooks)自动触发构建持续集成，也可以根据需要手动触发。可理解地，Jenkins有很多种触发构建的方式，例如，通过沟子插件(WeHooks)触发，通过定时更新代码触发等，同时可以在触发构建后执行自定义的构建操作，例如，可以通过编辑自定义的脚本构建；另外，自动化集成工具(Jenkins)可以同时进行任何构建操作。

S20:构建持续集成任务；

所述持续集成服务器采用自动化集成工具构建持续集成任务；可理解地，自动化集成工具(Jenkins)是一个开源的、提供友好操作界面的持续集成(CI)工具，Jenkins可以构建一个自动化的持续集成环境可以使用它来自动化编译、打包、分发部署应用，它兼容ant、maven、gradle等多种第三方构建工具。同时，自动化集成工具(Jenkins)支持很多的插件库，例如，Git、SVN、Docker和Maven等插件，用户可根据自身需要进行插件的安装，本方案通过自动化集成工具(Jenkins)从代码库中获取代码后创建持续集成任务。

持续集成(Continuous Integration)就是：指开发阶段，对项目进行持续性自动化编译、测试，以达到控制代码质量的手段，持续集成是一种软件开发实践。

S30:采用所述自动化集成工具调用代码检查插件对所述代码进行代码质量检查，得到代码质量检查结果；

在持续集成过程中，自动化集成工具(Jenkins)将自动调用代码检查插件(SonarQube)进行代码质量检查，得到代码质量检测结构。若所述代码质量检查结果为检查有误，则无法进行下一步集成，需要开发者先进行代码修复；若所述代码质量检查无误，则采用自动化集成工具(Jenkins)结合仓库管理器(Nexus)进行打包，生成集成包(jar包)。

Sonar是一个用于代码质量管理的开源平台，用于管理源代码的质量。通过插件机制，Sonar可以集成不同的测试工具、代码分析工具以及持续集成工具；通过不同的插件对这些结果进行再加工处理，通过量化的方式度量代码质量的变化，从而可以方便地对不同规模和种类的工程进行代码质量管理；例如，本方案采用代码检查插件(SonarQube)进行代码质量检查，代码检查插件(SonarQube)可以发现基本的语法规范出错了和安全隐患问题。

代码质量检查包括对代码进行静态分析，具体地，其中一种方式，自动化集成工具(Jenkins)集成FindBugs插件对代码进行静态分析，FindBugs是一个静态分析工具，它检查类或者JAR文件，将字节码与一组缺陷模式进行对比以发现可能的问题。另有一种方式，自动化集成工具(Jenkins)与代码检查插件(SonarQube)集成，代码检查插件(SonarQube)会扫描出来到底是谁写的代码、哪一个文件，哪一行存在安全隐患，是什么安全隐患，应该如何修改以及哪一行代码有这个语法规范问题；也即，代码检查插件(SonarQube会从全方位的角度检测整个项目在代码层面有哪些问题需要修改。

S40:若所述代码质量检查结果为检查无误，则采用所述自动化集成工具以及项目管理工具对所述代码进行编译打包，生成集成包；

Maven是一个项目管理工具，包括创建、编译、打包、运行、发布、发布站点等功能，仓库管理器(Nexus)是个强大的Maven仓库管理器，它极大地简化了自己内部仓；库的维护和外部仓库的访问；利用仓库管理器(Nexus)就能够完全控制访问和部署所维护仓库中的每个Artifact，Artifact是Maven中的一个概念，表示某个模块(module)需要如何打包，一个模块(module)有了Artifacts就可以部署到应用服务器中。

集成包是代码的jar包，可以通过应用服务器或者容器跑起来，就可以提供服务。

自动化集成工具(Jenkins)结合仓库管理器(Nexus)进行编译打包，具体地，自动化集成工具(Jenkins)触发打包动作后，会去拉代码库(GitLab)中的代码和配置文件，调用自动化编译脚本，并通过项目管理工具(Maven)把有对应关系的代码进行编译打包，以形成jar包，最后将jar包发送至仓库管理器(Nexus)中；其中，编译的方式包括maven、gradle或shell等，具体本发明不做限定；当然，还可以采用分布式编译器distcc来加快编译速度；打包的方式可以包括maven、gradle或shell等。

S50:把所述集成包添加到应用容器引擎的基础镜像中生成新镜像文件，其中，基础镜像为镜像模板，其包括运行容器所需的数据；

容器可以理解为面向对象编程中的“对象”，即镜像实例化，一个可以运行的实体。最终提供给用户访问的，都是某个容器所提供的某个服务。

Docker是开源的应用容器引擎，让开发者打包他们的应用以及依赖包到一个轻量级、可移植的容器中，然后发布到任何的Linux机器上，也可以实现虚拟化。

应用容器引擎(Docker)的基础镜像是一个只读的模板，一个独立的文件***，包括运行容器所需的数据，可以用来创建新的容器。当然，可以在应用容器引擎(Docker)中添加阿里云镜像加速器，以便于应用容器引擎(Docker)在拉取基础镜像的时候速度快些。

Dockerfile是Docker构建镜像的一种方式，类似于一个构建镜像的脚本文件。具体地，Docker可以通过阅读Docker的指令自动构建映像构建文件(Dockerfile)，构建文件(Dockerfile)是一个文本文档，其中包含用户可以在命令上调用以组装图像的所有命令。

本方案，通过在代码库(GitLab)中内置容器化应用的构建文件(Dockerfile)以及编译容器镜像需要的额外配置文件，其中，构建文件(Dockerfile)的内容涵盖能使应用正常所需要的一整套环境配置；同时，构建文件(Dockerfile)记录这构建镜像的整个步骤，具体包括基础镜像信息、维护者信息、镜像操作指令、容器启动时执行指令等，通过调用构建文件(Dockerfile)把jar包添加到应用容器引擎(Docker)的基础镜像后，生成新镜像文件。

S60:将所述新镜像文件推送至私有镜像库，以完成所述持续集成任务。

私有镜像库是用于存放Docker镜像的仓库，并提供新镜像文件的下载上传功能。

通过调用应用容器引擎(Docker)对应的插件完成应用的容器化及将生成好的新镜像文件推送到私有镜像库中，以完成所述持续集成任务。

再者，通过应用容器引擎(Docker)从私有镜像库中拉取新镜像文件，启动容器，就可以访问应用程序。

在图1对应的实施例中，开发者推送代码到代码库(GitLab)中，触发自动化集成工具(Jenkins)构建持续集成任务，同时自动进行代码质量检查，再通过项目管理工具(Maven)编译、打包，生成集成包(jar包)，然后把集成包(jar包)添加到应用容器引擎(Docker)的基础镜像中，以生成新镜像文件，并将新镜像文件推送(push)到私有镜像库中，应用容器引擎(Docker)从私有镜像库中拉取新镜像文件，启动容器，以实现自动化编译打包、及代码质量检查，持续集成中的任何一个环节都是自动完成的，无需太多的人工干预，有利于减少重复过程以节省时间、费用和工作量。

在一实施例中，如图2所示，在步骤S10中，业绩所述从代码库中拉取代码，具体包括如下步骤：

S11：定义所述代码库的源地址；

代码库(GitLab)提供一个代码片段收集功能可以轻松实现代码复用，便于日后有需要的时候进行查找。

S12：定时检查所述代码的状态，若所述代码的状态为新更新状态且接收到所述自动化集成工具的触发指令，则触发构建持续集成任务；

持续集成服务器定时检查代码状态，查看代码是否有更新，如果发现有代码更新，也即若代码状态为新更新状态，那么就从代码库(GitLab)中下载最新的代码，且在接收到所述自动化集成工具的触发指令时，则所述持续集成服务器触发构建持续集成任务。进一步地，每次代码提交之后，都会在持续集成服务器上触发一个定时构建，然后再进行代码分析以及编译。

S13：通过所述代码库的源地址从所述代码库中拉取所述代码。

需要定义代码库(GitLab)的源地址，采用自动化集成工具(Jenkins)创建持续集成时，通过代码库(GitLab)的源地址进行代码的拉取。

此外，需要构建的master分支，开发者拉取(push)代码或者合并代码到代码库(GitLab)的master分支，自动化集成工具(Jenkins)就部署代码到对应服务器。

在图2对应的实施例中，持续集成服务器定时检查代码状态，查看代码是否有更新，如果发现有代码更新，也即若代码状态为新更新状态，则自动化集成工具触发创建持续集成任务，接着通过代码库的源地址从代码库(GitLab)中拉取最新的代码，通过代码库的源地址可以快速将代码从代码库中拉取出来。

在一实施例中，如图3所示，步骤S40之后S50之前，也即所述生成集成包之后，所述把集成包添加到应用容器引擎的基础镜像中之前，具体包括如下步骤：

S70:通过所述自动化集成工具对所述指定代码进行自动化测试；

生成集成包(jar包)后进行自动化测试；可通过自动化集成工具(Jenkins)对jar包中的代码做进行自动化测试；具体地，根据测试任务的类型，构建若干个用于实现测试环境的基础镜像，其中，每一个所述基础镜像对应一种接口测试类型；当接收到自动化测试请求时，获取与所述自动化测试请求对应的指定代码；根据指定代码生成与指定代码对应的自动化测试脚本；根据与所述接口测试类型对应的基础镜像创建相应的容器；在创建的所述容器中根据所述自动化测试脚本对所述接口测试类型涉及的接口进行测试。

基础镜像(Image)是构建容器的基础，其是一种分层结构的文件***。一个只读层被称为基础镜像，一个基础镜像是永久不会变的。由于容器技术使用统一的文件***，认为整个文件***是以读写方式挂载的。但是所有的变更都发生顶层的可写层，而下层的原始的只读镜像文件并未变化。也就是说，基础镜像提供了只读层，而在只读层上添加了读写层后便构成容器，也即基础镜像在设备上部署为容器。

此外，自动化集成工具(Jenkins)也可以添加额外的集成测试任务，如跑单元测试等，用于运行自动化测试脚本验证部署好的环境，并生成测试报告通过邮件或企业沟通群的方式通知QA和测试人员。

在步骤S60之后，也即所述将新镜像文件推送至私有镜像库之后，具体还包括如下步骤：

S80:调用批量部署命令执行批量部署，以远程控制部署服务器进行持续部署。

持续部署(Continuous Deployment)是在持续交付的基础上，把部署到生产环境的过程自动化；也即是持续交付的下一步或者说更高阶段，指的是代码通过质量检查后(或者是通过自动化测试以后)，自动部署到各个环境中，其中，环境包括开发环境、测试环境、验收测试环境、生产环境。持续部署是持续交付的最高阶段。这意味着，所有通过了一系列的自动化测试的改动都将自动部署到各个环境。

批量部署(Ansile)是一个批量部署的工具，通过调用批量部署(Ansile)对应的插件执行批量部署命令，能够批量把私有镜像库中的新镜像文件进行批量部署到多个容器，不用一台一台去部署。

持续部署(CD Continuous Delivery和Continuous Deployment)的过程即是对S10-S70持续集成(Continuous Integration)流程中构建的交付物进行自动化部署到开发、测试和生产环境中的过程。通过调用批量部署(Ansile)对应的插件执行批量部署命令，能够批量把私有镜像库中的新镜像文件进行批量部署到多个容器，不用一台一台去部署，增加部署效率。

部署服务器执行批量部署命令进行相关应用部署包括以下步骤：镜像构建完成后，查看当前是否有运行相关容器，如果有执行停机并删除相关容器，具体地，使用ssh远程登录部署服务器上删除已经存在的容器以及拉取的新镜像文件，重新部署新的容器，接着启动新容器；最后检查新的容器是否存在异常；其中，相关应是指jar包提供的应用服务，相关容器就是运行jar包的docker容器。

本方案由开发者提交代码，持续集成服务器获取代码，触发构建持续集成任务，在所述代码进行自动化测试，如果测试通过，自动部署到各个环境，全程自动化高效运转。

在图3对应的实施例中，把开发，测试，部署集成到一起，自动化部署意味着更快的部署时间，这和现在互联网要求的高频率小变更的项目方式是一致的。

在一实施例中，如图4所示，在步骤S40之后S50之前，也即所述生成集成包之后，所述把集成包添加到应用容器引擎的基础镜像中之前，还包括：

S90：采用所述自动化集成工具中的部署日记进行监控，其中，部署日志记录着持续集成方法的整个过程，每个步骤都会生产一个部署日志；

自动化集成工具(Jenkins)能实施监控集成中存在的错误，并提供详细的部署日记；通过部署日志可实现监控以及追踪，部署日志记录着持续集成方法的整个过程，每发布一次都会生产一个部署日志，记录着时间，操作过程等；部署日志还能用图表的形式形象地展示项目构建的趋势和稳定性。

S100：若所述监控过程中发生错误，则进行出错提醒并通过所述部署日记进行问题追溯；

如果其中步骤S20-S60过程任何一个步骤失败，就表示build失败，持续集成服务器会给予响应的反馈。具体地，通过部署日志还有提醒功能，出错后及时提醒开发者修复，Jenkins中通过配置SMTP配置信息，邮件模板等，创建事件触发器，在事件(如编译失败)发生时，及时发送邮件通知开发者。

在图4对应的实施例中，持续集成服务器采用自动化集成工具中的部署日记进行监控以及问题追溯，以使得所有软件发布包、配置变更、卸载或者回滚等操作都是可追踪的，通过部署日志骤进行监控，对问题进行追溯，以实现问题分析定位。

在一实施例中，如图5所示，在步骤S80中，所述调用批量部署命令执行批量部署，以远程控制部署服务器进行持续部署，具体包括如下步骤：

远程控制部署服务器进行持续部署，包括对环境进行持续部署，其中，环境包括开发环境、测试环境、验收测试环境、生产环境。

S81:调用批量部署命令控制所述部署服务器触发开发环境的部署；

开发环境(DEV)：是专门用于开发的服务器，配置可以比较随意，为了开发调试方便。

S82:控制所述部署服务器触发开发环境的部署之后，控制所述部署服务器触发测试环境的部署；

测试环境(SIT)：一般是克隆一份生产环境的配置，一个程序在测试环境工作不正常，那么肯定不能把它发布到生产机上。

S83:控制所述部署服务器触发测试环境的部署之后，控制所述部署服务器触发验收测试环境的部署；

UAT环境：UAT，(User Acceptance Test)，用户接受度测试即验收测试，所以UAT环境主要是用来作为客户体验的环境。

经测试后，已经按照设计把所有的模块组装成一个完整的软件***，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务。

S84:控制所述部署服务器触发验收测试环境的部署之后，控制所述部署服务器触发生产环境的部署。

生产环境(PROD)：是指正式提供对外服务的，一般会关掉错误报告，打开错误日志。可以理解为包含所有的功能的环境，任何项目所使用的环境都以这个为基础，然后根据客户的个性化需求来做调整或者修改。

可理解地，生产环境的部署根据定时器的设置时间定时触发。软件开发中，完整环境包括开发环境(DEV)、测试环境(SIT)、验收测试环境(UAT)、生产环境(PROD)；需要注意的是，在部署执行过程中，如果某个环境的部署发现问题，则进行回滚，回滚操作依赖于人工在备份中选取正取版本，进行数据库的回滚；如果数据安装包里按规范要求提供了回滚脚本，则开源工具(DevOps)可以自动调用该脚本进行回滚操作；所有软件发布包、配置变更、卸载或者回滚等操作都是可追踪的、有部署日志和部署步骤可追溯。

在图5对应的实施例中，自动化以提升工作效率，但自动化也可能出错，例如误删除文件及其它应用、误启停服务/容器，由此，需要逐步对开发环境(DEV)、测试环境(UAT)、验收测试环境(UAT)、生产环境(PROD)进行持续部署来规避上述问题，同时，实现开发环境(DEV)、测试环境(SIT)、验收测试环境(UAT)、生产环境(PROD)的一键发布。

在一实施例中，在步骤S80之前，也即所述调用批量部署命令执行批量部署之前，具体还包括如下步骤：

所述持续集成服务器控制所述部署服务器采用所述自动化集成工具分别传入开发环境、测试环境、验收测试环境、生产环境对应的参数后进行部署。

参数化管理是自动化集成工具(Jenkins)特有的功能，自动化集成工具(Jenkins)能够通过脚本实现参数化构建部署，比如环境参数就有开发环境(DEV)、测试环境(SIT)、验收测试环境(UAT)、生产环境(PROD)。

在本实施例中，统一部署脚本，通过参数化管理来区分各个环境之间的差异，极大的降低了在不同环境部署时因人员失误导致的部署异常或失败。且一次配置多次复用，缩短部署耗时，提高部署效率。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明的实施过程构成任何限定。

在一实施例中，提供一种持续集成装置，该持续集成装置与上述实施例中持续集成方法一一对应。如图6所示，该持续集成装置包括拉取模块10、触发构建模块20、检查模块30、打包模块40、添加模块50和推送模块60。各功能模块详细说明如下：

拉取模块10，从代码库中拉取代码；

触发构建模块20，构建持续集成任务；

检查模块30，采用所述自动化集成工具调用代码检查插件对所述代码进行代码质量检查，得到代码质量检查结果；

打包模块40，若所述代码质量检查结果为检查无误，则采用所述自动化集成工具以及项目管理工具对所述代码进行编译打包，生成集成包；

添加模块50，把所述集成包添加到应用容器引擎的基础镜像中，生成新镜像文件，其中，基础镜像为镜像模板，其包括运行容器所需的数据；

推送模块60，将所述新镜像文件推送至私有镜像库，以完成所述持续集成任务。

所述打包模块40，具体用于：

定义所述代码库的源地址；

定时检查所述代码的状态，若所述代码的状态为新更新状态且接收到所述自动化集成工具的触发指令，则触发构建持续集成任务；

通过所述代码库的源地址从所述代码库中拉取所述代码。

所述装置还包括自动化测试模块，所述自动化测试模块具体用于：

通过所述自动化集成工具对指定代码进行自动化测试，所述指定代码是指集成包中的代码；

所述装置还包括批量部署模块，所述批量部署模块具体用于：

调用批量部署命令执行批量部署，以远程控制部署服务器进行持续部署。

所述装置还包括监控追溯模块，所述监控追溯模块模块具体用于：

采用所述自动化集成工具中的部署日记进行监控，其中，部署日志记录着持续集成方法的整个过程，每个步骤都会生产一个部署日志；

若所述监控过程中发生错误，则进行出错提醒并通过所述部署日记进行问题追溯。

所述装置还包括批量部署单元，所述批量部署单元具体用于：

调用批量部署命令控制所述部署服务器触发开发环境的部署；

控制所述部署服务器触发开发环境的部署之后，控制所述部署服务器触发测试环境的部署；

控制所述部署服务器触发测试环境的部署之后，控制所述部署服务器触发验收测试环境的部署；

控制所述部署服务器触发验收测试环境的部署之后，控制所述部署服务器触发生产环境的部署。

所述装置还包括的传入参数单元，所述传入参数单元具体用于：

控制所述部署服务器采用所述自动化集成工具分别传入开发环境、测试环境、验收测试环境、生产环境对应的参数后进行部署。

关于持续集成装置的具体限定可以参见上文中对于持续集成方法的限定，在此不再赘述。上述持续集成装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图7所示。该计算机设备包括通过***总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作***、计算机程序和数据库。该内存储器为非易失性存储介质中的操作***和计算机程序的运行提供环境。该计算机设备的数据库用存储代码、集成包、基础镜像以及新镜像文件等。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种持续集成方法。

在一个实施例中，提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现以下步骤：

从代码库中拉取代码；

构建持续集成任务；

采用所述自动化集成工具调用代码检查插件对所述代码进行代码质量检查，得到代码质量检查结果；

若所述代码质量检查结果为检查无误，则采用所述自动化集成工具以及项目管理工具对所述代码进行编译打包，生成集成包；

把所述集成包添加到应用容器引擎的基础镜像中，生成新镜像文件，其中，基础镜像为镜像模板，其包括运行容器所需的数据；

将所述新镜像文件推送至私有镜像库，以完成所述持续集成任务。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：

从代码库中拉取代码；

构建持续集成任务；

采用所述自动化集成工具调用代码检查插件对所述代码进行代码质量检查，得到代码质量检查结果；

若所述代码质量检查结果为检查无误，则采用所述自动化集成工具以及项目管理工具对所述代码进行编译打包，生成集成包；

把所述集成包添加到应用容器引擎的基础镜像中，生成新镜像文件，其中，基础镜像为镜像模板，其包括运行容器所需的数据；

将所述新镜像文件推送至私有镜像库，以完成所述持续集成任务。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。

以上所述实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围，均应包含在本发明的保护范围之内。

Claims (10)

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

从代码库中拉取代码；

构建持续集成任务；

采用自动化集成工具调用代码检查插件对所述代码进行代码质量检查，得到代码质量检查结果；

若所述代码质量检查结果为检查无误，则采用所述自动化集成工具以及项目管理工具对所述代码进行编译打包，生成集成包；

把所述集成包添加到应用容器引擎的基础镜像中，生成新镜像文件，其中，基础镜像为镜像模板，其包括运行容器所需的数据；

将所述新镜像文件推送至私有镜像库，以完成所述持续集成任务。

2.如权利要求1所述的持续集成方法，其特征在于，所述从代码库中拉取代码，包括：

定义代码库的源地址；

定时检查所述代码的状态，若所述代码的状态为新更新状态且接收到所述自动化集成工具的触发指令，则触发构建持续集成任务；

通过所述代码库的源地址从所述代码库中拉取所述代码。

3.如权利要求1所述的持续集成方法，其特征在于，在所述生成集成包之后，所述把集成包添加到应用容器引擎的基础镜像中之前，还包括：

通过所述自动化集成工具对指定代码进行自动化测试，所述指定代码是指集成包中的代码；

在所述将新镜像文件推送至私有镜像库之后，还包括：

调用批量部署命令执行批量部署，以远程控制部署服务器进行持续部署。

4.如权利要求1所述的持续集成方法，其特征在于，在所述生成集成包之后，所述把集成包添加到应用容器引擎的基础镜像中之前，还包括：

采用所述自动化集成工具中的部署日记进行监控；

若所述监控过程中发生错误，则进行出错提醒并通过所述部署日记进行问题追溯。

5.如权利要求3所述的持续集成方法，其特征在于，所述调用批量部署命令执行批量部署，以远程控制部署服务器进行持续部署，包括：

调用批量部署命令，控制所述部署服务器触发开发环境的部署；

控制所述部署服务器触发开发环境的部署之后，控制所述部署服务器触发测试环境的部署；

控制所述部署服务器触发测试环境的部署之后，控制所述部署服务器触发验收测试环境的部署；

控制所述部署服务器触发验收测试环境的部署之后，控制所述部署服务器触发生产环境的部署。

6.如权利要求5所述的持续集成方法，其特征在于，所述调用批量部署命令执行批量部署之前，还包括：

控制所述部署服务器采用所述自动化集成工具分别传入开发环境、测试环境、验收测试环境以及生产环境对应的参数后进行部署。

7.一种持续集成装置，其特征在于，包括：

拉取模块，从代码库中拉取代码；

构建模块，构建持续集成任务；

检查模块，采用所述自动化集成工具调用代码检查插件对所述代码进行代码质量检查，得到代码质量检查结果；

打包模块，若所述代码质量检查结果为检查无误，则采用所述自动化集成工具以及项目管理工具对所述代码进行编译打包，生成集成包；

添加模块，把所述集成包添加到应用容器引擎的基础镜像中，生成新镜像文件，其中，基础镜像为镜像模板，其包括运行容器所需的数据；

推送模块，将所述新镜像文件推送至私有镜像库，以完成所述持续集成任务。

8.如权利要求7所述的持续集成装置，其特征在于，所述打包模块，具体用于：

定义所述代码库的源地址；

定时检查所述代码的状态，若所述代码的状态为新更新状态且接收到所述自动化集成工具的触发指令，则触发构建持续集成任务；

通过所述代码库的源地址从所述代码库中拉取所述代码。

9.一种计算机设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至6任一项所述持续集成方法的步骤。

10.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至6任一项所述持续集成方法的步骤。

Images