CN118113308A - 一种代码自动化部署方法、系统、服务器及存储介质 - Google Patents

Abstract

本申请适用于计算机技术领域，提供了一种代码自动化部署方法、系统服务器及存储介质，基于容器编排服务构建运行环境项目；其中，所述运行环境项目包括代码检测插件的运行环境和代码运行打包时所需的打包运行环境；将所述运行环境项目打包成对应的运行环境包，并制作运行环境包对应的运行环境镜像；在检测到代码更新触发时，触发流水线作业，以基于所述运行环境镜像启动镜像运行服务。能够有效减少代码自动部署过程中复杂环境的搭建步骤，并且不需要侵入代码管理系统，能够提高代码自动化部署的效率和安全性。

Description

一种代码自动化部署方法、系统、服务器及存储介质

技术领域

本申请属于计算机技术领域，尤其涉及一种代码自动化部署方法、系统、服务器及存储介质。

背景技术

代码自动化部署是指使用自动化工具和脚本，将软件项目本身，包括配置文件、用户手册、帮助文档等进行收集、打包、安装、配置、发布的过程。自动化部署可以通过自动化工具执行各种任务，包括代码编译、测试、打包、容器化等，从而实现快速、可靠的服务部署流程。

目前关于代码自动化部署方法可以使用持续集成/持续交付工具(ContinuousIntegration/Continuous Delivery，CI/CD工具)实现自动构建、运行测试，生成可执行文件或容器镜像，并自动部署到对应的目标环境中，以此来实现自动化部署。目前，自动化部署所需要构建运行的环境都需要在宿主机中进行搭建，这就需要宿主机具备有较高的硬件性能，而且在宿主机中搭建环境也存在可移植性差的问题，还存在因占用资源过多，易存在宕机风险。

由于直接在宿主机中搭建环境容易存在以上问题，因此引出了通过容器搭建用于执行CI/CD的工具所需的环境，然后通过代码中的流水线临时环境构建打包环境，通过容器，能够降低对宿主机资源的占用，并且也使得环境有一定的可移植性，但是构建和运行的环境都在流水线中，这样就会使得每次构建都要在工具所在的容器中重新安装对应的环境，导致构建效率低等问题。

发明内容

本申请实施例提供了一种代码自动化部署方法、系统、服务器及存储介质，能够有效减少代码自动部署过程中复杂环境的搭建步骤，并且不需要侵入代码管理系统，能够提高代码自动化部署的效率和安全性。

第一方面，本申请实施例提供一种代码自动化部署方法，包括：

基于容器编排服务构建运行环境项目；其中，上述运行环境项目包括代码检测插件的运行环境和代码运行打包时所需的打包运行环境；

将上述运行环境项目打包成对应的运行环境包，并制作运行环境包对应的运行环境镜像；

在检测到代码更新触发时，触发流水线作业，以基于上述运行环境镜像启动镜像运行服务。

在第一方面的一种实现方式中，上述运行环境镜像包括打包环境镜像和运行环境镜像，上述在检测到代码更新触发时，触发流水线作业，以基于上述运行环境镜像启动镜像运行服务，包括：

基于流水线配置文件引入打包环境镜像和运行环境镜像；

基于引入的打包镜像和流水线作业将更新的代码打包，得到目标更新代码包；

基于运行环境镜像运行上述目标更新代码包。

在第一方面的一种实现方式中，在上述在检测到代码更新触发时，触发流水线作业，以基于上述运行环境镜像启动镜像运行服务之前，还包括：

基于代码检测插件监测代码管理系统中的代码更新情况。

在第一方面的一种实现方式中，上述基于代码检测插件监测代码管理系统中的代码更新情况，包括：

根据流水线配置文件中定义的流水线触发作业，监测是否存在上述流水线触发作业对应的更新触发。

在第一方面的一种实现方式中，上述将上述运行环境项目打包成对应的运行环境包，并制作运行环境包对应的运行环境镜像之后，还包括：

将上述运行环境镜像上传至镜像管理平台。

在第一方面的一种实现方式中，上述在在检测到代码更新触发时，触发流水线作业，以基于上述运行环境镜像启动镜像运行服务之前，还包括：

在项目所在的容器中将需要部署的服务通过注册命令进行注册。

在第一方面的一种实现方式中，上述基于容器编排服务构建运行环境项目，包括：

在容器编排服务的运行目录下的各个文件中定义上述代码检测插件的运行环境和代码运行打包时所需的打包运行环境。

第二方面，本申请实施例提供一种代码自动化部署系统，包括：

编排模块，用于基于容器编排服务构建运行环境项目；其中，上述运行环境项目包括代码检测插件的运行环境和代码运行打包时所需的打包运行环境；

运行环境镜像制作模块，用于将上述运行环境项目打包成对应的运行环境包，并制作运行环境包对应的运行环境镜像；

部署模块，用于在检测到代码更新触发时，触发流水线作业，以基于上述运行环境镜像启动镜像运行服务。

第三方面，本申请实施例提供一种服务器，所述服务器包括处理器、存储器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如第一方面或第一方面的任意可选方式所述的方法。

第四方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现如第一方面或第一方面的任意可选方式所述的方法。

第五方面，本申请实施例提供一种计算机程序产品，当计算机程序产品在服务器上运行时，使得服务器执行上述第一方面或第一方面的任意可选方式所述的方法。

本申请实施例与现有技术相比存在的有益效果是：

本申请实施例提出了一种代码自动部署方法、系统、服务器及存储介质，通过容器编排服务编排好代码部署工具相应的运行环境和代码运行打包所需的打包运行环境，并制作成对应的运行环境镜像，从而使得需要实现代码自动部署的服务能够直接引入该运行环境镜像来部署对应的服务，在代码部署工具执行流水线作业时，就可以通过该运行环境镜像中的包含打包运行环境执行对应的操作，能够有效减少代码自动部署过程中复杂环境的搭建步骤，并且不需要侵入代码管理系统，能够提高代码自动化部署的效率和安全性。

附图说明

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

图1是一种gitLabRunner实现自动部署的流程示意图；

图2是另一种gitLabRunner实现自动部署的流程示意图；

图3为本申请实施例提供的代码自动化部署方法的实现流程示意图；

图4为本申请实施例提供的代码自动化部署方法中中S13的实现流程示意图；

图5为本申请实施例提供的一种代码自动化部署系统的结构示意图；

图6为本申请实施例提供的一种服务器的结构示意图；

图7为本申请实施例提供的一种计算机可读存储介质的结构示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

应当理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。另外，在本申请说明书和所附权利要求书的描述中，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

还应当理解，在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。

为了更高效、更安全可靠地实现服务(基于代码提供的服务)的部署，可以选用代码自动化部署来实现服务的部署。

代码自动化部署是指使用自动化工具和脚本，将软件项目本身，包括代码内容、配置文件、用户手册、帮助文档等进行收集、打包、安装、配置、发布的过程。自动化部署可以通过自动化工作执行各种任务，包括代码编译、测试、打包、容器化等自动部署任务，从而实现快速、可靠的服务部署流程。

目前关于代码自动化部署方法可以使用代码管理系统(也可以称为代码仓库)来对代码进行管理，并在检测到代码更新后使用持续集成/持续交付工具(ContinuousIntegration/Continuous Delivery，CI/CD工具)实现自动构建、运行测试，生成可执行文件或容器镜像，并自动部署到对应的目标环境中，以此来实现自动化部署。

上述代码管理系统可以是gitLab代码托管服务，通常会采用gitLabRunner等代码检测插件来实现代码更新的检测，并在检测到代码更新后，触发流水线实现CI/CD，从而完成代码自动化部署。

以下以代码管理系统为gitLab，代码检测插件为gitLabRunner实现自动化部署进行示例性说明，可以理解的是，自动化部署中的代码管理系统还可以是gitHub等代码管理系统，自动部署时采用的代码检测插件还可以是gitHub actions等能够实现检测代码管理系统提交更新代码，并基于更新代码实现自动部署的插件。

目前针对gitLabRunner的自动化部署方案，通常包括以下两种：

第一种：直接在宿主机中搭建gitLabRunner的运行环境和打包运行环境。

示例性的，请参阅图1，图1为一种gitLabRunner实现自动部署的流程示意图。如图1所示，代码模块提交代码到代码管理系统(gitLab)中，其中，代码管理系统gitLab与部署在宿主机中的gitLabRunner通过register建立连接，因此宿主机中的gitLabRunner能够检测到代码管理系统gitLab中的代码更新情况，此时就会触发流水线作业，根据流水线配置文件.gitlab-ci.yml文件执行流水线作业，同时将更新的代码临时复制到gitLabRunner中，基于gitLabRunner和宿主机中构建的打包运行环境，将更新的代码进行打包部署，部署到对应的位置，并将打包完成的包制作为镜像，并在容器中部署运行。

其中，代码模块可以是各个服务中的开发人员用于开发和提交代码的工具。

第二种：通过在容器(例如docker)来搭建gitLabRunner的运行环境，然后通过流水线配置文件.gitlab-ci.yml文件在流水线中临时构建打包运行环境。

示例性的，请参阅图2，图2为另一种gitLabRunner实现自动部署的流程示意图。如图2所示，代码模块提交代码到代码管理系统gitLab中，gitLabRunner部署在容器，从而得到运行有gitLabRunner的容器(即gitLabRunner的运行环境搭建在容器中)，容器中的gitLabRunner跟gitLab通过register建立连接，因此容器中的gitLabRunner能够检测到代码管理系统gitLab中的代码更新情况，此时就会触发流水线作业，根据流水线配置文件.gitlab-ci.yml文件执行流水线作业，同时将更新的代码临时复制到gitLabRunner中，基于gitLabRunner和宿主机中执行流水线作业时构建的打包运行环境，将更新的代码进行打包部署，并部署到对应的位置，同时还可以根据流水线作业将打包完成的包制作为镜像，并在容器中部署运行。

以上两种基于gitLabRunner的自动部署方案存在以下问题：

第一种自动部署方法所需要构建运行的环境(包括gitLabRunner的运行环境和打包运行环境)都搭建在与宿主机中，本身gitLabRunner宿主机的cpu等硬件资源的占用就很高，因此再在宿主机中搭建其它打包运行环境，就需要宿主机具有较高的硬件性能。此外，直接在宿主机上搭建的环境，在环境搭建和移植方面也会非常麻烦，可移植性几乎为零。由于构建的环境占用了宿主机的大量资源，如果存在多个服务需要同时部署，就很容易导致系统资源被满占，使得，服务随时存在宕机的风险。

第二种自动部署方案中，gitLabRunner以docker容器的方式单独管理，相比于第一种直接在宿主机中搭建gitLabRunner的环境的，能够通过容器隔离降低宿主机资源占用风险，并且也拥有一定的可移植性，但是构建和运行的打包运行环境在流水线中，导致每次构建都要在gitLabRunner所在docker容器中去重新安装对应环境，导致构建缓慢，构建时间长还容易出错。此外，因为打包构建是在gitLabRunner容器中，并且在注册runner的时候设置docker，这样就会出现docker in docker，如果很多服务同时构建，则同样也会出现资源占用，导致服务宕机的风险。如果系统环境比较复杂，所有构建的打包运行环境的构架流程都在流水线中，就会使得流水线的流程环境非常复杂，也就是说，针对复杂的系统环境，则上述方案存在可拓展性低的问题。

综上可知，现有的代码自动部署方案，存在构建效率低且安全性差的问题。

基于此，本申请实施例提出了一种代码自动部署方法，通过容器编排服务编排好代码部署工具相应的运行环境和代码运行打包所需的打包运行环境，并制作成对应的运行环境镜像，从而使得需要实现代码自动部署的服务能够直接引入该运行环境镜像来部署对应的服务，在代码部署工具执行流水线作业时，就可以通过该运行环境镜像中的包含打包运行环境执行对应的操作，能够有效减少代码自动部署过程中复杂环境的搭建步骤，并且不需要侵入代码管理系统，能够提高代码自动化部署的效率和安全性。

以下将对本申请实施例提供的代码自动部署方法进行详细的说明：

请参阅图3，图3示出了本申请实施例提供的一种代码自动部署方法的实现流程。

需要说明的是，本申请实施例提供的代码自动部署方法的执行主体可以是服务器，服务器中可以通过docker-compose编排好gitLabRunner的运行环境和代码的打包运行环境，且gitLabRunner已经通过register与gitLab注册绑定。当然，上述执行主体也可以是实体设备，上述实体的设备可以是手机、台式电脑、笔记本电脑等设备，本申请对此不作具体限制。以下以执行主体为服务器为例进行说明：

需要说明的是，gitLabRunner是gitLab的一个插件，可以称为代码检测插件，其作为一种代码部署工具，能够实现gitLab的代码更新检测，并且能够触发流水线实现CI/CD，完成代码自动化部署。

如图3所示，上述代码自动部署方法具体可以包括S11～S13：

在S11中，基于容器编排服务构建运行环境项目。

在具体应用中，容器编排服务docker-compose能够实现对容器集群的快速编排，docker-compose将其管理的所有的容器分为三层，分别为工程(project)、服务(service)以及容器(container)，docker-compose运行目录下的所有文件能够构建出一个运行环境项目，该运行环境项目中就包括了gitLabRunner对应的运行环境以及代码运行打包时所需的打包运行环境。

利用上述运行环境项目构建包含上述gitLabRunner的运行环境以及代码运行打包时所需的打包运行环境，具体可以在docker-compose的运行目录下的所有的文件例如配置文件(docker-compose.yml文件)，组合映像命令文件(DockerFile文件)，扩展文件(extends文件)和/或环境变量文件等。也即在相关文件中定义上述gitLabRunner的运行环境以及代码运行打包时所需的打包运行环境的相关内容。

在S12中，将所述运行环境项目打包成对应的运行环境包，并制作运行环境包对应的运行环境镜像。

在具体应用中，针对不同的开发语言，对应的打包运行环境不同，因此在构建代码运行打包时所需的打包运行环境时，可以针对每一种开发语言构建该开发语言对应的打包运行环境。例如针对java语言，则在这个运行环境包中需要中安装打包环境包括的maven及jdk，这样就满足了java语言的打包运行环境。又例如node js语言，则需要安装对应的node，npm，yarn，nginx等环境。如果服务中还需要其它环境，则可以在上述配置文件docker-compose.yml文件和对应的组合映像命令文件DockerFile文件中做相应的配置，就能实现对应的打包运行环境的构建。打包运行环境包括了打包环境和运行环境。上述运行环境镜像也包括了打包环境镜像和运行环境镜像。

在一些实施例中，上述将所述运行环境项目打包成对应的运行环境包，并制作运行环境包对应的运行环境镜像同样可以基于流水线作业来实现。

在具体应用中，上述运行环境镜像中包含了gitLabRunner环境及需要运行的服务的运行环境容器。

在具体应用中，为了保证能够在上述运行环境中打包代码运行镜像，在制作上述运行环境包对应的运行环境镜像时，需要在该运行环境镜像中安装docker相关的运行环境。

在一些实施例中，上述运行环境镜像制作完成后，还可以将该运行环境镜像上传到镜像管理平台中，这样不同的服务就能够根据需要从镜像管理平台中使用该运行环境镜像。

在具体应用中，基于上述运行环境镜像，针对需要自动部署的服务，可以在项目所在的容器中将对需要部署的服务通过注册命令进行注册实现绑定后，就可以使用该运行环境镜像，从而能够有效地提高运行环境镜像的构建效率，而且在一次构建后，同类服务都可以使用该运行环境镜像，且还可以将该运行环境镜像移植到其他环境中重复使用，从而能够有效地提高代码自动部署方案的环境部署效率。在具体应用中，运行环境镜像可以通过容器托管服务来实现管理，上述容器托管服务可以是registry服务。

上述注册命令具体可以是：docker exec-it******register。

需要说明的是，为了避免docker in docker操作，可以在gitLabRunner注册时，将其脚本执行类型选择为shell，这样在执行的时候，就会在gitLabRunner所在设备中启动一个对应的终端，在该终端中执行作业中定义的命令。按照以上搭建的环境，经过.gitlab-ci.yml中定义的流水线作业，就会单独启动一个代码运行镜像，从而避免docker indocker破环原打包环境。

同类型代码服务中的每一个项目都可以使用制作的运行环境镜像，并且对应的配置文件都可以复用，在同类型的代码服务的新运行环境中，就算项目不同，只需要引入上述运行环境镜像，部署的脚本就几乎可以复用，因此能够有效地提高服务管理的部署效率，而且代码可维护性强，服务额定可靠性强，且该环境可以重复利用，实现较高的可移植性。

在S13中，在检测到代码更新触发时，触发流水线作业，以基于所述运行环境镜像启动镜像运行服务。

在具体应用中，代码检测插件gitLabRunner能够监听代码管理系统gitLab中代码的更新情况，在检测到代码更新触发时，可以触发流水线作业，根据流水线配置文件.gitlab-ci.yml文件中定义的指令执行相应的操作，在流水线配置文件.gitlab-ci.yml文件中通过上述docker-compose.yml文件引入制作好的运行环境镜像，并通过DockerFile文件引入运行环境，从而启动镜像运行服务，基于CI/CD将该镜像运行服务部署到对应的位置中。

需要说明的是，上述代码检测插件gitLabRunner和gitLab通过register建立连接。

在一些实施例中，gitLabRunner也可以根据流水线配置文件.gitlab-ci.yml文件中定义的流水线触发作业，监测是否存在流水线触发作业对应的更新触发，当定义的流水线触发作业被触发的情况下，gitLabRunner会下载对应的代码并触发流水线作业，利用制作好的运行环境镜像和DockerFile文件引入运行环境，从而启动镜像运行服务，从而实现自动化部署。

需要说明的是，上述流水线作业的触发动作可以自定义，例如代码打包，制作镜像，镜像上传，部署，清除等操作，即在发生代码打包，制作镜像，镜像上传，部署，清除等操作时，gitLabRunner就可以下载该操作对应的代码，并触发流水线作业，根据流水线配置文件.gitlab-ci.yml文件执行流水线作业，从而启动对应的镜像运行服务，实现自动化部署，例如打包更新部署到对应位置。

需要说明的是，上述.gitlab-ci.yml文件用于存储从代码到服务的部署步骤的全部指令，上述文件可以是管理员提前配置好的，可以是根据需要编写对应的CI/CD流程，然后根据对应的环境去使用该运行环境镜像，也可以是根据用户交互生成的，还可以是通过通用模板自动生成的，本实施例对此不作具体限制。

在本申请一实施例中，请参阅图4，图4为本申请实施例提供的代码自动化部署方法中S13的实现流程图。如图4所示，上述S13具体可以包括以下步骤：

在S131中，基于流水线配置文件引入打包环境镜像和运行环境镜像。

在S132中，基于引入的打包镜像和流水线作业将更新的代码打包，得到目标更新代码包。

在S133中，基于运行环境镜像运行所述目标更新代码包。

在具体应用中，在构建流水线时，同样可以使用docker-compose，将流水线制作的服务镜像通过docker-compose.yml文件引入，即通过配置流水线配置文件.gitlab-ci.yml通过docker-compose.yml文件引入打包环境镜像，再利用流水线，通过DockerFile文件引入运行环境镜像运行完成打包的代码更新包，从而实现单独启动镜像运行服务，实现相关的服务的自动部署。

以上可以看出，本申请实施例提供的一种代码自动化部署，通过容器编排服务编排好代码部署工具(具体可以是上述代码检测插件)相应的运行环境和代码运行打包所需的打包运行环境，并制作成对应的运行环境镜像，从而使得需要实现代码自动部署的服务能够直接引入该运行环境镜像来部署对应的服务，在代码部署工具执行流水线作业时，就可以通过该运行环境镜像中的包含打包运行环境执行对应的操作，能够有效减少代码自动部署过程中复杂环境的搭建步骤，并且不需要侵入代码管理系统，能够提高代码自动化部署的效率和安全性。

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

基于上述实施例所提供的代码自动化部署方法，本发明实施例进一步给出实现上述方法实施例的代码自动化部署系统的实施例。

请参阅图5，图5是本申请实施例提供的一种代码自动部署系统的结构示意图。本申请实施例中，代码自动化部署系统包括的各单元用于执行图3对应的实施例中的各步骤。具体请参阅图3以及图3对应的实施例中的相关描述。为了便于说明，仅示出了与本实施例相关的部分。如图5所示，上述代码自动化部署系统50可以包括编排模块501、运行环境镜像制作模块502以及部署模块503，其中：

编排模块501用于基于容器编排服务构建运行环境项目；其中，运行环境项目包括代码检测插件的运行环境和代码运行打包时所需的打包运行环境。

运行环境镜像制作模块502用于将运行环境项目打包成对应的运行环境包，并制作运行环境包对应的运行环境镜像。

部署模块503用于在检测到代码更新触发时，触发流水线作业，以基于运行环境镜像启动镜像运行服务。

在一些实现方式中，运行环境镜像包括打包环境镜像和运行环境镜像，上述部署模块503可以包括引入单元、打包单元和运行单元。其中：

引入单元用于基于流水线配置文件引入打包环境镜像和运行环境镜像。

打包单元用于基于引入的打包镜像和流水线作业将更新的代码打包，得到目标更新代码包。

运行单元用于基于运行环境镜像运行目标更新代码包。

在一些实现方式中，所述代码自动化部署系统还包括监测模块。

监测模块用于基于代码检测插件监测代码管理系统中的代码更新情况。

在一些实现方式中，上述监测模块还用于根据流水线配置文件中定义的流水线触发作业，监测是否存在所述流水线触发作业对应的更新触发。

在一些实现方式中，上述代码自动化部署系统还包括上传模块。

上传模块用于将运行环境镜像上传至镜像管理平台。

在一些实现方式中，上述代码自动化部署系统还包括注册模块。

注册模块用于在项目所在的容器中将需要部署的服务通过注册命令进行注册。

在一些实现方式中，上述编排模块501具体用于在容器编排服务的运行目录下的各个文件中定义所述代码检测插件的运行环境和代码运行打包时所需的打包运行环境。

需要说明的是，上述各个单元之间的信息交互、执行过程等内容，由于与本申请方法实施例基于同一构思，其具体功能及带来的技术效果，具体可参照方法实施例部分，此处不再赘述。

因此，本申请实施例提供的一种代码自动化部署系统，同样能够通过容器编排服务编排好代码部署工具相应的运行环境和代码运行打包所需的打包运行环境，并制作成对应的运行环境镜像，从而使得需要实现代码自动部署的服务能够直接引入该运行环境镜像来部署对应的服务，在代码部署工具执行流水线作业时，就可以通过该运行环境镜像中的包含打包运行环境执行对应的操作，能够有效减少代码自动部署过程中复杂环境的搭建步骤，并且不需要侵入代码管理系统，能够提高代码自动化部署的效率和安全性。

图6是本申请另一实施例提供的一种服务器的结构示意图。如图6所示，该实施例提供的服务器6包括：处理器60、存储器61以及存储在所述存储器61中并可在所述处理器60上运行的计算机程序62，例如图像分割程序。处理器60执行所述计算机程序62时实现上述各个代码自动化部署方法实施例中的步骤，例如图2所示的S11～S13。或者，所述处理器60执行所述计算机程序62时实现上述各服务器实施例中各模块/单元的功能，例如图5所示单元501～503的功能。

示例性的，所述计算机程序62可以被分割成一个或多个模块/单元，所述一个或者多个模块/单元被存储在所述存储器61中，并由处理器60执行，以完成本申请。所述一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述所述计算机程序62在所述服务器6中的执行过程。例如，所述计算机程序62可以被分割成获取单元、确定单元以及计算单元，各单元具体功能请参阅图7对应地实施例中的相关描述，此处不赘述。

所述服务器可包括但不仅限于，处理器60、存储器61。本领域技术人员可以理解，图6仅仅是服务器6的示例，并不构成对服务器6的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如所述服务器还可以包括输入输出设备、网络接入设备、总线等。

所称处理器60可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

所述存储器61可以是所述服务器6的内部存储单元，例如服务器6的硬盘或内存。所述存储器61也可以是所述服务器6的外部存储设备，例如所述服务器6上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。进一步地，所述存储器61还可以既包括所述服务器6的内部存储单元也包括外部存储设备。所述存储器61用于存储所述计算机程序以及所述服务器所需的其他程序和数据。所述存储器61还可以用于暂时地存储已经输出或者将要输出的数据。

本申请实施例还提供了一种计算机可读存储介质。请参阅图7，图7是本申请实施例提供的一种计算机可读存储介质的结构示意图，如图7所示，计算机可读存储介质70中存储有计算机程序62，计算机程序62被处理器执行时可实现上述代码自动化部署方法。

本申请实施例提供了一种计算机程序产品，当计算机程序产品在服务器上运行时，使得服务器执行时实现可实现上述代码自动化部署方法。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述服务器的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参照其它实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

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

Claims (10)

1.一种代码自动化部署方法，其特征在于，包括：

基于容器编排服务构建运行环境项目；其中，所述运行环境项目包括代码检测插件的运行环境和代码运行打包时所需的打包运行环境；

将所述运行环境项目打包成对应的运行环境包，并制作运行环境包对应的运行环境镜像；

在检测到代码更新触发时，触发流水线作业，以基于所述运行环境镜像启动镜像运行服务。

2.根据权利要求1所述的代码自动化部署方法，其特征在于，所述运行环境镜像包括打包环境镜像和运行环境镜像，所述在检测到代码更新触发时，触发流水线作业，以基于所述运行环境镜像启动镜像运行服务，包括：

基于流水线配置文件引入打包环境镜像和运行环境镜像；

基于引入的打包镜像和流水线作业将更新的代码打包，得到目标更新代码包；

基于运行环境镜像运行所述目标更新代码包。

3.根据权利要求1所述的代码自动化部署方法，其特征在于，在所述在检测到代码更新触发时，触发流水线作业，以基于所述运行环境镜像启动镜像运行服务之前，还包括：

基于代码检测插件监测代码管理系统中的代码更新情况。

4.根据权利要求3所述的代码自动化部署方法，其特征在于，所述基于代码检测插件监测代码管理系统中的代码更新情况，包括：

根据流水线配置文件中定义的流水线触发作业，监测是否存在所述流水线触发作业对应的更新触发。

5.根据权利要求1至3任一项所述的代码自动化部署方法，其特征在于，所述将所述运行环境项目打包成对应的运行环境包，并制作运行环境包对应的运行环境镜像之后，还包括：

将所述运行环境镜像上传至镜像管理平台。

6.根据权利要求5所述的代码自动化部署方法，其特征在于，所述在检测到代码更新触发时，触发流水线作业，以基于所述运行环境镜像启动镜像运行服务之前，还包括：

在项目所在的容器中将需要部署的服务通过注册命令进行注册。

7.根据权利要求1所述的代码自动化部署方法，其特征在于，所述基于容器编排服务构建运行环境项目，包括：

在容器编排服务的运行目录下的各个文件中定义所述代码检测插件的运行环境和代码运行打包时所需的打包运行环境。

8.一种代码自动部署系统，其特征在于，包括：

编排模块，用于基于容器编排服务构建运行环境项目；其中，所述运行环境项目包括代码检测插件的运行环境和代码运行打包时所需的打包运行环境；

运行环境镜像制作模块，用于将所述运行环境项目打包成对应的运行环境包，并制作运行环境包对应的运行环境镜像；

部署模块，用于在检测到代码更新触发时，触发流水线作业，以基于所述运行环境镜像启动镜像运行服务。

9.一种服务器，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序的可读指令时实现如权利要求1至7任一项所述的代码自动化部署方法。

10.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序的可读指令被处理器执行时实现如权利要求1至7任一项所述的代码自动化部署方法。