CN112732561A - 一种项目部署方法、装置、计算机设备和存储介质 - Google Patents

Abstract

本公开提供了一种项目部署方法、装置、计算机设备和存储介质，其中，该方法包括：获取开发人员上传的待部署代码；基于预先设定的项目部署平台，对所述待部署代码进行测试；其中，所述项目部署平台具有统一的部署流程和部署规范；在测试成功后，将所述待部署代码部署到生产环境中。本公开实施例通过利用预先设定的项目部署平台，自动化将待部署代码部署到生产环境中，提高了部署效率、分支代码部署准确率，降低了管理成本。

Description

一种项目部署方法、装置、计算机设备和存储介质

技术领域

本公开涉及计算机技术领域，具体而言，涉及一种项目部署方法、装置、计算机设备和存储介质。

背景技术

现有技术中，服务端的应用在各个环节的构建部署是利用一种开源软件项目jenkins工具完成的，在对一个新创建的应用进行构建部署时，需要在jenkins中构建该应用对应的工作单元job。目前，针对服务应用上线前的构建部署，存在以下缺陷：一方面，针对各个服务开发负责人对于分支代码管理策略的不统一，导致各个测试环境部署策略混乱，容易将错误的分支代码部署到测试环境中，如果将项目交接给其他技术人员统一管理，同样会存在管理成本高、效率低等问题；另一方面，对于新服务的接入，需要技术人员创建各个环境的项目，导致人工成本高。

发明内容

本公开实施例至少提供一种项目部署方法、装置、计算机设备和存储介质。

第一方面，本公开实施例提供了一种项目部署方法，包括：

获取开发人员上传的待部署代码；

基于预先设定的项目部署平台，对所述待部署代码进行测试；其中，所述项目部署平台具有统一的部署流程和部署规范；

在测试成功后，将所述待部署代码部署到生产环境中。

一种可选的实施方式中，所述基于预先设定的项目部署平台，对所述待部署代码进行测试，包括：

将所述待部署代码打包成第一镜像；

将所述第一镜像部署到集成测试环境中。

一种可选的实施方式中，还包括：

在集成测试成功后，将所述第一镜像部署到验收测试环境中。

一种可选的实施方式中，在将所述待部署代码部署到生产环境中之后，还包括：

检测所述待部署代码在所述生产环境中是否稳定；

若稳定，则将所述待部署代码合并至主分支代码。

一种可选的实施方式中，所述基于预先设定的项目管理平台，对所述待部署代码进行测试，还包括：

将所述待部署代码打包成所述第一镜像；

将所述第一镜像部署到功能测试环境中；

在功能测试成功后，将所述待部署代码合并至预发布分支代码；

将所述预发布分支代码打包成第二镜像；

将所述第二镜像部署到集成环境测试中。

一种可选的实施方式中，还包括：

在集成测试成功后，将所述第二镜像部署到验收测试环境中。

一种可选的实施方式中，在将所述待部署代码部署到生产环境中之后，还包括：

检测所述预发布分支代码在所述生产环境中是否稳定；

若稳定，则将所述预发布分支代码合并至主分支代码。

一种可选的实施方式中，还包括：

检测所述主分支代码是否需要进行修复；

若是，则将所述待部署代码修改为修订待部署代码；

将所述修订待部署代码部署到修复测试环境中；

在修复测试成功后，将所述修订待部署代码部署到生产环境中。

一种可选的实施方式中，在将所述修订待部署代码部署到生产环境中之后，所述方法还包括：

检测所述修订待部署代码在所述生产环境中是否稳定；

若稳定，则将所述修订待部署代码合并至所述预发布分支代码以及所述主分支代码。

第二方面，本公开实施例还提供一种项目部署装置，包括：

获取模块，用于获取开发人员上传的待部署代码；

测试模块，用于基于预先设定的项目部署平台，对所述待部署代码进行测试；其中，所述项目部署平台具有统一的部署流程和部署规范；

部署模块，用于在测试成功后，将所述待部署代码部署到生产环境中。

一种可选的实施方式中，所述测试模块，用于将所述待部署代码打包成第一镜像；将所述第一镜像部署到集成测试环境中。

一种可选的实施方式中，所述测试模块，用于在集成测试成功后，将所述第一镜像部署到验收测试环境中。

一种可选的实施方式中，还包括第一合并模块，用于在部署模块之后，检测所述待部署代码在所述生产环境中是否稳定；若稳定，则将所述待部署代码合并至主分支代码。

一种可选的实施方式中，所述测试模块，用于将所述待部署代码打包成所述第一镜像；将所述第一镜像部署到功能测试环境中；在功能测试成功后，将所述待部署代码合并至预发布分支代码；将所述预发布分支代码打包成第二镜像；将所述第二镜像部署到集成环境测试中。

一种可选的实施方式中，所述测试模块，用于在集成测试成功后，将所述第二镜像部署到验收测试环境中。

一种可选的实施方式中，还包括第二合并模块，用于在部署模块之后，检测所述预发布分支代码在所述生产环境中是否稳定；若稳定，则将所述预发布分支代码合并至主分支代码。

一种可选的实施方式中，还包括修复模块，用于检测所述主分支代码是否需要进行修复；若是，则将所述待部署代码修改为修订待部署代码；将所述修订待部署代码部署到修复测试环境中；

所述部署模块，用于在修复测试成功后，将所述修订待部署代码部署到生产环境中。

一种可选的实施方式中，还包括第三合并模块，用于在部署模块之后，检测所述修订待部署代码在所述生产环境中是否稳定；若稳定，则将所述修订待部署代码合并至所述预发布分支代码以及所述主分支代码。

第三方面，本公开实施例还提供一种计算机设备，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当计算机设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行上述第一方面，或第一方面中任一种可能的实施方式中的步骤。

第四方面，本公开实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述第一方面，或第一方面中任一种可能的实施方式中的步骤。

关于上述项目部署装置、计算机设备和存储介质的效果描述参见上述项目部署方法的说明，这里不再赘述。

本公开实施例提供的项目部署方法、装置、计算机设备和存储介质，通过获取开发人员上传的待部署代码；基于预先设定的项目部署平台，对待部署代码进行测试；其中，项目部署平台具有统一的部署流程和部署规范；在测试成功后，将待部署代码部署到生产环境中。与现有技术中的针对分支代码管理策略不统一相比，其利用预先设定的项目部署平台，自动化将待部署代码部署到生产环境中，提高了部署效率、分支代码部署准确率，降低了管理成本。

进一步，本公开实施例提供的项目部署方法，还可以利用生成的第一镜像和第二镜像部署测试环境，避免待部署代码变更影响测试环境的稳定性，同时减少了待部署代码拉取、编译、打包过程的时间，提高部署效率。

为使本公开的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本公开实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，此处的附图被并入说明书中并构成本说明书中的一部分，这些附图示出了符合本公开的实施例，并与说明书一起用于说明本公开的技术方案。应当理解，以下附图仅示出了本公开的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本公开实施例所提供的一种项目部署方法中功能测试环境部署的流程图；

图2示出了本公开实施例所提供的RD构建发布的示意图；

图3示出了本公开实施例所提供的待部署代码进行上线的流程图；

图4示出了本公开实施例所提供的功能测试发布的示意图；

图5示出了本公开实施例所提供的待部署代码部署到集成测试环境的流程图

图6示出了本公开实施例所提供的集成测试发布的示意图；

图7示出了本公开实施例所提供的各流水线运行步骤的示意图；

图8示出了本公开实施例所提供的CD发布系统架构示意图；

图9示出了本公开实施例所提供的一种项目部署装置的示意图；

图10示出了本公开实施例所提供的一种计算机设备的结构示意图。

具体实施方式

为使本公开实施例的目的、技术方案和优点更加清楚，下面将结合本公开实施例中附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本公开一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本公开实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本公开的实施例的详细描述并非旨在限制要求保护的本公开的范围，而是仅仅表示本公开的选定实施例。基于本公开的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本公开保护的范围。

首先，对本发明实施例中涉及的部分用语进行说明，以便于本领域技术人员理解。

1、CD：持续部署(Continuous Deployment)是指当交付的代码通过验收测试之后，自动部署到生产环境中。持续部署是持续交付的最高阶段。

2、Jenkins：是一个开源软件项目，基于Java开发的一种持续集成工具，用于监控持续重复的工作，旨在提供一个开放易用的软件平台，使软件的持续集成变成可能。

3、Gitlab：是一个用于仓库管理系统的开源项目，使用Git作为代码管理工具，并在此基础上搭建起来的web服务。

4、git：是一个开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目版本管理。

5、dev环境：是指一种开发环境。开发环境是程序员们专门用于开发的服务器。

6、prod环境：是指一种生产环境。面向外部用户的环境，连接上互联网即可访问的正式环境。

7、beta测试：一种验收测试。所谓验收测试是软件产品完成了功能测试和系统测试之后，在产品发布之前所进行的软件测试活动，它是技术测试的最后一个阶段，通过了验收测试，产品就会进入发布阶段。

8、hotfix：是针对某一个具体的系统漏洞或安全问题而发布的专门解决该漏洞或安全问题，通常称为修补程序。

11、Docker：是一个开源的应用容器引擎，让开发者可以打包应用以及依赖包到一个可移植的容器中。

12、release分支为git分支的一种。

13、master分支为git分支的一种。

14、RD：Research&Develop研发工程师或开发工程师。

另外，本公开实施例中的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。

在本文中提及的“多个或者若干个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

经研究发现，服务应用上线过程存在较多缺陷，比如：1、jenkins job构建需要经过最新分支代码的拉取、编译、打包、部署等流程，由于每一次jenkins job的构建都只能拉取最新的分支代码，无法隔离分支代码的修改对测试环境的影响。例如，当需要对历史开发的分支代码进行测试时，由于只能从Gitlab拉取最新的分支代码进行环境的部署，因此，不能隔离最新分支代码对测试环境的影响。2、由于原jenkins job构建每次都需要拉取对应分支的代码进行编译打包，会导致整个构架部署时间较长。3、由于各个服务开发负责人对分支代码管理策略不统一，会导致各个服务测试环境部署策略混乱，容易导致部署错误分支代码，同时，仅通过技术人员手动查询并限制统一策略的可靠性低，且服务交接给其他开发人员成本较大。

基于上述研究，本公开提供了一种项目部署方法，针对上述现有技术存在的缺点，本发明具有针对性的解决了其存在的缺陷问题，比如，1、测试工程师在功能测试环境使用第一镜像进行部署，在集成测试环境使用第二镜像进行部署，不会受到分支代码变更对测试环境稳定性的影响。2、由于将每一待部署代码对应打包成第一镜像和将预发布分支代码打包成第二镜像，因此，减少了构建环境过程中针对每一待部署代码或预发布分支代码的拉取、编译、打包，所以可以减少功能测试环境，集成测试环境，验收测试环境，生产环境的部署时间，提高部署效率。3、统一了服务的构建发布流程步骤，降低了技术人员部署错误分支代码的概率，在便于不熟悉该领域的技术人员学习的同时，无需技术人员手动部署测试环境，减少了环境部署时间，节省了人工成本。

针对以上方案所存在的缺陷，均是发明人在经过实践并仔细研究后得出的结果，因此，上述问题的发现过程以及下文中本公开针对上述问题所提出的解决方案，都应该是发明人在本公开过程中对本公开做出的贡献。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

为便于对本实施例进行理解，首先对本公开实施例所公开的一种项目部署方法进行详细介绍，本公开实施例所提供的项目部署方法的执行主体一般为具有一定计算能力的计算机设备，该计算机设备例如包括：终端设备或服务器或其它处理设备，终端设备可以为用户设备(User Equipment，UE)、移动设备、用户终端、终端、蜂窝电话、无绳电话、个人数字助理(Personal Digital Assistant，PDA)、手持设备、计算设备、车载设备、可穿戴设备等。在一些可能的实现方式中，该项目部署方法可以通过处理器调用存储器中存储的计算机可读指令的方式来实现。

下面以执行主体为计算机设备为例对本公开实施例提供的项目部署法加以说明。

实施例一

参见图1所示，为本公开实施例提供的项目部署方法中功能测试环境部署的流程图，该方法包括步骤S101～S103，其中：

S101：获取开发人员上传的待部署代码。

本步骤中，待部署代码可以包括针对目标项目的已开发的功能代码。其中，目标项目可以是待部署代码对应的服务项目。

S102：基于预先设定的项目部署平台，对待部署代码进行测试。

其中，项目部署平台具有统一的部署流程和部署规范。

在一种可能的实施方式中，可以针对待部署代码进行开发环境测试。首先，需要对待部署代码进行开发环境的部署。基于预先设定的项目部署平台，可以通过构建一条“RD构建发布”流水线，在构建发布过程中进行dev环境构建发布，参见图2所示，其为RD构建发布的示意图，其中，“代码分支”项表示开发人员上传的待部署代码的名称，“环境”项表示当前待部署代码所在的运行环境；“备注”项表示当前待部署代码所具有的功能。具体实施时，对目标项目进行某一项功能的开发，可以在针对该功能的待部署代码编写完成之后，开发人员利用待部署代码的dev环境对待部署代码进行测试，将测试完成的待部署代码部署到dev环境中。

在针对目标项目的待部署代码完成开发环境测试后，可以直接进行集成测试环境的部署。在一种可能的实施方式中，可以将待部署代码打包成第一镜像，将第一镜像直接部署到集成测试环境中。示例性的，针对一个待部署代码对应的功能进行上线前处理，则可以通过将该待部署代码打包成第一镜像，直接将第一镜像部署到集成测试环境中，完成上线前的处理。另外，还可以检测待部署代码在生产环境中是否稳定；若稳定，则将待部署代码合并至主分支代码；若不稳定，则将待部署代码进行修改，将修改后的待部署代码打包成第一镜像，将第一镜像部署到集成测试环境中。

这里，在将第一镜像部署到集成测试环境中后，如果集成测试成功，则可以将第一镜像部署到验收测试环境中，等待上线。

可以参见图3所示，其为待部署代码进行上线的流程图。

S301：获取开发人员上传的待部署代码；

S302：将待部署代码打包成第一镜像；

S303：将第一镜像部署到集成测试环境中；

S304：在集成测试成功后，将第一镜像部署到验收测试环境中；

S305：检测所述待部署代码在生产环境中是否稳定，如果是，则执行步骤S306；如果否，则执行步骤S307；

S306：将待部署代码合并至主分支代码，结束流程；

S307：修改不稳定的待部署代码，将修改后的待部署代码打包成第一镜像，执行步骤S302。

另外，在针对目标项目的待部署代码完成开发环境测试后，还可以先进行功能测试环境的部署，再进行集成测试环境的部署。在一种可能的实施方式中，可以通过构建一条“功能测试发布”流水线，在构建发布过程中进行功能测试环境发布、功能代码合并到release分支和集成测试镜像构建，参见图4所示，其为功能测试发布的示意图。参见图5所示，其为待部署代码部署到集成测试环境的流程图，包括步骤S501～S505，其中：

S501：将待部署代码打包成第一镜像。

本步骤中，可以通过构建部件对待部署代码进行打包，得到第一镜像，其中，构建部件可以为Dokcer工具。并将打包的第一镜像存储在存储部件中，其中，存储部件可以为镜像管理服务器。

S502：将第一镜像部署到功能测试环境中。

本步骤中，进行功能测试环境发布，具体实施时，如图4所示，针对“功能测试环境发布”模块中的“镜像”项表示获取的针对目标项目所需的第一镜像，“测试子环境”项表示为功能测试环境提供上一级测试环境中的代码，即开发环境中的待检测代码。将第一镜像部署到功能测试中，对待检测代码进行功能测试。

S503：在功能测试成功后，将待部署代码合并至预发布分支代码。

具体实施时，针对功能测试环境发布的待检测代码进行合并，比如，可以将每一待检测代码合并到release分支中，确定预发布分支代码。在待检测代码进行合并的过程中，需要检测待检测代码是否冲突，其中，冲突的原因可能但不仅限于是目前release分支中待检测代码版本信息不一致或者共同创建了同一个文件名称引起冲突等，在此不一一赘述。在待检测代码合并后不冲突的情况下，可以进行集成处理。

S504：将预发布分支代码打包成第二镜像。

S505：将第二镜像部署到集成环境测试中。

在一种可能的实施方式中，将第二镜像部署到集成环境测试中之后，在集成测试成功后，将所述第二镜像部署到验收测试环境中还可以检测预发布分支代码在生产环境中是否稳定；若稳定，则将预发布分支代码合并至主分支代码；若不稳定，则将预发布分支代码对应的若干个待部署代码进行修改，将修改后的待部署代码打包成第一镜像，执行步骤S502。

这里，在将第二镜像部署到集成测试环境中后，如果集成测试成功，则可以将第二镜像部署到验收测试环境中，等待上线。

在另一种可能的实施方式中，在针对目标项目的待部署代码完成开发环境测试和功能测试后，进行集成测试环境的部署。可以通过构建一条“集成测试发布”流水线，进行集成测试环境发布、beta环境发布、prod环境发布、以及将release代码合并到master，参见图6所示，其为集成测试发布的示意图。

一种实施方式，进行集成测试环境发布，具体实施时，如图6所示，其中，针对“集成测试环境发布”模块中，“镜像”项表示获取的针对目标项目所需的第二镜像，对显示的“备注”项表示该第二镜像所具有的功能。将第二镜像部署到集成测试环境，利用集成测试环境对预发布分支代码进行集成测试。

一种实施方式，进行beta环境发布，具体实施时，利用集成测试环境对预发布分支代码进行集成测试通过之后，可以针对集成测试环境中发布的预发布分支代码进行验收测试。需要说明的是，根据用户的需要，针对特定的目标项目对应的预发布分支代码可以跳过验收测试的步骤，直接进行prod环境发布。

S103：在测试成功后，将待部署代码部署到生产环境中。

具体实施时，可以直接将集成测试通过后的第一镜像对应的待部署代码部署到生产环境中；或者，可以将验收测试通过后的第一镜像对应的待部署代码部署到生产环境中；或者，可以将集成测试通过后的第二镜像对应的预发布分支代码部署到生产环境中。或者，可以将验收测试通过后的第二镜像对应的待部署代码部署到生产环境中。

参见图6所示，“集成测试发布”流水线中的prod环境发布，如下：

一种实施方式，进行prod环境发布，具体实施时，利用验收测试环境对预发布分支代码进行验收测试通过之后，将预发布分支代码部署到生产环境中进行上线处理。

参见图6所示，“集成测试发布”流水线中的将release代码合并到master的模块，如下：

一种实施方式，进行将release代码合并到master，具体实施时，在预发布分支代码在生产环境中稳定运行的情况下，将预发布分支代码进行合并，确定主分支代码，并将主分支代码存储。

在另一种可能的实施方式中，在主分支代码应用过程中出现运行不正常的情况下，可以通过构建一条“hotfix测试发布”流水线，进行修复测试环境发布。具体实施时，可以利用将待部署代码修改为修订待部署代码；将修订待部署代码部署到修复测试环境中；在修复测试成功后，将修订待部署代码部署到生产环境中。

或者，在主分支代码应用过程中出现运行不正常的情况下，还可以利用“hotfix测试发布”流水线，对预发布分支代码进行修改，确定预发布分支代码修改后的修订分支代码；将修订分支代码部署到修复测试环境中；在修复测试成功后，将修订分支代码部署到生产环境中。

需要说明的是，修复测试环境发布与集成测试环境发布过程相似，所经历的步骤相同，但是，修复测试环境中的预发布分支代码可以为针对第二镜像对应的预发布分支代码更新后的分支代码。另外，针对“hotfix测试发布”流水线中代码合并部分，检测修订待部署代码在生产环境中是否稳定；若稳定，则将修订待部署代码合并至预发布分支代码以及主分支代码，即，将预发布分支代码合并到release分支或者合并到master分支。

基于上述四条流水线，即“RD构建发布”流水线、“功能测试发布”流水线、“集成测试发布”流水线和“hotfix测试发布”流水线，统一了目标项目从开发到上线过程的发布流程，在便于不熟悉该领域的技术人员学习的同时，无需技术人员手动部署测试环境，节省了人工成本。参见图7所示，其为各流水线运行步骤的示意图。

另外，本公开实施例中针对功能测试环境发布、集成测试环境发布、修复测试环境发布，利用生成的第一镜像和第二镜像部署测试环境，避免待部署代码变更影响测试环境的稳定性，同时减少了待部署代码的拉取、编译、打包过程的时间，提高部署效率；在分支代码部署过程中，通过自动化流水线管理，在提高部署效率以及准确率的同时，还降低了人工管理成本。

实施例二

本公开实施例还提供了一种CD发布系统，包括主业务处理系统和第三方集成系统，第三方集成系统包括目标项目信息平台、Gitlab、kubernetes、Jenkins、镜像仓库。参见图8所示，其为CD发布系统架构示意图。

其中，目标项目信息平台存储目标项目信息，比如目标项目开发技术人员信息，目标项目功能等；第三方集成系统可以通过与Gitlab对接获取目标项目对应的待部署代码、以及目标项目对应的预发布分支代码；第三方集成系统可以通过调用kubernetes接口进行环境的部署；第三方集成系统可以通过调用Jenkins接口进行镜像构建；镜像仓库可以接收Jenkins推送的第一镜像和第二镜像，也可以为kubernetes发送第一镜像和第二镜像。主业务处理系统可以通过第三方集成系统获取第三方集成系统集成的所有信息，具体可以包括一下至少一项：目标项目开发技术人员信息、目标项目功能、目标项目对应的待部署代码、目标项目对应的预发布分支代码、调用kubernetes接口、调用Jenkins接口。

本领域技术人员可以理解，在具体实施方式的上述方法中，各步骤的撰写顺序并不意味着严格的执行顺序而对实施过程构成任何限定，各步骤的具体执行顺序应当以其功能和可能的内在逻辑确定。

基于同一发明构思，本公开实施例中还提供了与项目部署方法对应的项目部署装置，由于本公开实施例中的装置解决问题的原理与本公开实施例上述项目部署方法相似，因此装置的实施可以参见方法的实施，重复之处不再赘述。

实施例三

参照图9所示，为本公开实施例提供的一种项目部署装置的示意图，所述装置包括：获取模块901、测试模块902、部署模块903；其中，

获取模块901，用于获取开发人员上传的待部署代码；

测试模块902，用于基于预先设定的项目部署平台，对所述待部署代码进行测试；其中，所述项目部署平台具有统一的部署流程和部署规范；

部署模块903，用于在测试成功后，将所述待部署代码部署到生产环境中。

一种可选的实施方式中，所述测试模块902，用于将所述待部署代码打包成第一镜像；将所述第一镜像部署到集成测试环境中。

一种可选的实施方式中，所述测试模块，用于在集成测试成功后，将所述第一镜像部署到验收测试环境中。

一种可选的实施方式中，还包括第一合并模块904，用于在部署模块之后，检测所述待部署代码在所述生产环境中是否稳定；若稳定，则将所述待部署代码合并至主分支代码。

一种可选的实施方式中，所述测试模块902，用于将所述待部署代码打包成所述第一镜像；将所述第一镜像部署到功能测试环境中；在功能测试成功后，将所述待部署代码合并至预发布分支代码；将所述预发布分支代码打包成第二镜像；将所述第二镜像部署到集成环境测试中。

一种可选的实施方式中，所述测试模块902，用于在集成测试成功后，将所述第二镜像部署到验收测试环境中。

一种可选的实施方式中，还包括第二合并模块905，用于在部署模块之后，检测所述预发布分支代码在所述生产环境中是否稳定；若稳定，则将所述预发布分支代码合并至主分支代码。

一种可选的实施方式中，还包括修复模块906，用于检测所述主分支代码是否需要进行修复；若是，则将所述待部署代码修改为修订待部署代码；将所述修订待部署代码部署到修复测试环境中；

所述部署模块903，用于在修复测试成功后，将所述修订待部署代码部署到生产环境中。

一种可选的实施方式中，还包括第三合并模块907，用于在部署模块之后，检测所述修订待部署代码在所述生产环境中是否稳定；若稳定，则将所述修订待部署代码合并至所述预发布分支代码以及所述主分支代码。

关于装置中的各模块的处理流程、以及各模块之间的交互流程的描述可以参照上述项目部署方法实施例中的相关说明，这里不再详述。

实施例四

基于同一技术构思，本申请实施例还提供了一种计算机设备。参照图10所示，为本申请实施例提供的计算机设备的结构示意图，包括：

处理器101、存储器102和总线103。其中，存储器102存储有处理器101可执行的机器可读指令，处理器101用于执行存储器102中存储的机器可读指令，所述机器可读指令被处理器101执行时，处理器101执行下述步骤：S101：获取目标项目对应的至少一个第一分支代码；S102：生成每个第一分支代码的镜像文件，并将生成的镜像文件存储在存储部件中；S103：在对目标项目的第二分支代码进行功能测试时，从存储部件中获取镜像文件，并基于获取的镜像文件部署对第二分支代码进行功能测试的功能测试环境。

上述存储器102包括内存1021和外部存储器1022；这里的内存1021也称内存储器，用于暂时存放处理器101中的运算数据，以及与硬盘等外部存储器1022交换的数据，处理器101通过内存1021与外部存储器1022进行数据交换，当计算机设备运行时，处理器101与存储器102之间通过总线103通信，使得处理器101在执行上述方法实施例中所提及的执行指令。

本公开实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述方法实施例中所述的项目部署方法的步骤。其中，该存储介质可以是易失性或非易失的计算机可读取存储介质。

本公开实施例所还提供一种计算机程序产品，该计算机程序产品承载有程序代码，所述程序代码包括的指令可用于执行上述方法实施例中所述的项目部署方法的步骤，具体可参见上述方法实施例，在此不再赘述。

其中，上述计算机程序产品可以具体通过硬件、软件或其结合的方式实现。在一个可选实施例中，所述计算机程序产品具体体现为计算机存储介质，在另一个可选实施例中，计算机程序产品具体体现为软件产品，例如软件开发包(Software Development Kit，SDK)等等。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统和装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。在本公开所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本公开各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本公开的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本公开各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-OnlyMemory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上所述实施例，仅为本公开的具体实施方式，用以说明本公开的技术方案，而非对其限制，本公开的保护范围并不局限于此，尽管参照前述实施例对本公开进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本公开揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本公开实施例技术方案的精神和范围，都应涵盖在本公开的保护范围之内。因此，本公开的保护范围应所述以权利要求的保护范围为准。

Claims (12)

1.一种项目部署方法，其特征在于，包括：

获取开发人员上传的待部署代码；

基于预先设定的项目部署平台，对所述待部署代码进行测试；其中，所述项目部署平台具有统一的部署流程和部署规范；

在测试成功后，将所述待部署代码部署到生产环境中。

2.根据权利要求1所述的项目部署方法，其特征在于，所述基于预先设定的项目部署平台，对所述待部署代码进行测试，包括：

将所述待部署代码打包成第一镜像；

将所述第一镜像部署到集成测试环境中。

3.根据权利要求2所述的项目部署方法，其特征在于，还包括：

在集成测试成功后，将所述第一镜像部署到验收测试环境中。

4.根据权利要求2所述的项目部署方法，其特征在于，在将所述待部署代码部署到生产环境中之后，还包括：

检测所述待部署代码在所述生产环境中是否稳定；

若稳定，则将所述待部署代码合并至主分支代码。

5.根据权利要求1所述的项目部署方法，其特征在于，所述基于预先设定的项目管理平台，对所述待部署代码进行测试，还包括：

将所述待部署代码打包成第一镜像；

将所述第一镜像部署到功能测试环境中；

在功能测试成功后，将所述待部署代码合并至预发布分支代码；

将所述预发布分支代码打包成第二镜像；

将所述第二镜像部署到集成环境测试中。

6.根据权利要求5所述的项目部署方法，其特征在于，还包括：

在集成测试成功后，将所述第二镜像部署到验收测试环境中。

7.根据权利要求5所述的项目部署方法，其特征在于，在将所述待部署代码部署到生产环境中之后，还包括：

检测所述预发布分支代码在所述生产环境中是否稳定；

若稳定，则将所述预发布分支代码合并至主分支代码。

8.根据权利要求4或7所述的项目部署方法，其特征在于，还包括：

检测所述主分支代码是否需要进行修复；

若是，则将所述待部署代码修改为修订待部署代码；

将所述修订待部署代码部署到修复测试环境中；

在修复测试成功后，将所述修订待部署代码部署到生产环境中。

9.根据权利要求8所述的项目部署方法，其特征在于，在将所述修订待部署代码部署到生产环境中之后，所述方法还包括：

检测所述修订待部署代码在所述生产环境中是否稳定；

若稳定，则将所述修订待部署代码合并至预发布分支代码以及所述主分支代码。

10.一种项目部署装置，其特征在于，包括：

获取模块，用于获取开发人员上传的待部署代码；

测试模块，用于基于预先设定的项目部署平台，对所述待部署代码进行测试；其中，所述项目部署平台具有统一的部署流程和部署规范；

部署模块，用于在测试成功后，将所述待部署代码部署到生产环境中。

11.一种计算机设备，其特征在于，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当计算机设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行如权利要求1至9任一项所述的项目部署方法的步骤。

12.一种计算机可读存储介质，其特征在于，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如权利要求1至9任一项所述的项目部署方法的步骤。

Images