CN117055930A - 一种系统升级部署方法和系统 - Google Patents

Abstract

本申请实施例公开了一种系统升级部署方法和系统，该方法包括以下步骤：接收来自代码仓库的json文件，根据所述json文件包含的配置参数，判断是否启用自动构建；在确定启用自动构建的情况下，从所述代码仓库拉取源代码，并对所述源代码进行打包，得到包文件；将所述包文件发送到目标服务器的指定目录，在所述目标服务器上实现系统升级部署。本申请实施例通过从代码仓库拉取源代码并打包，将得到的包文件发送到目标服务器的指定目录，并在目标服务器上实现系统升级部署，从而实现系统升级部署的全流程自动化。

Description

一种系统升级部署方法和系统

技术领域

本申请属于计算机技术领域，具体涉及一种系统升级部署方法和系统。

背景技术

在系统升级部署时，传统技术开发人员的部署方式为：升级需求的代码开发完成后，进行本地打包，然后登录后台服务器，将旧版本的代码进行备份，然后将新版本的代码拷贝到服务器上，然后进行服务重启。如果一个应用涉及到多个服务，需要对这些服务进行一一上述操作。而且涉及到服务的启停，需要在晚间时候，用户量较少的时候进行操作。如果升级业务没有问题，本次升级就算成功；如果测试发现问题，就需要一台一台服务进行回退部署。

发明内容

本申请实施例的目的是提供一种系统升级部署方法和系统，以解决现有技术中的系统升级部署比较繁琐的缺陷。

为了解决上述技术问题，本申请是这样实现的：

第一方面，提供了一种系统升级部署方法，包括以下步骤：

接收来自代码仓库的json文件，根据所述json文件包含的配置参数，判断是否启用自动构建；

在确定启用自动构建的情况下，从所述代码仓库拉取源代码，并对所述源代码进行打包，得到包文件；

将所述包文件发送到目标服务器的指定目录，在所述目标服务器上实现系统升级部署。

第二方面，提供了一种系统升级部署系统，包括：

接收模块，用于接收来自代码仓库的json文件，根据所述json文件包含的配置参数，判断是否启用自动构建；

拉取模块，用于在确定启用自动构建的情况下，从所述代码仓库拉取源代码，并对所述源代码进行打包，得到包文件；

部署模块，用于将所述包文件发送到目标服务器的指定目录，在所述目标服务器上实现系统升级部署。

本申请实施例通过从代码仓库拉取源代码并打包，将得到的包文件发送到目标服务器的指定目录，并在目标服务器上实现系统升级部署，从而实现系统升级部署的全流程自动化。

附图说明

图1是本申请实施例提供的一种系统升级部署方法流程图；

图2是本申请实施例提供的系统升级部署方法的一种具体实现图；

图3是本申请实施例提供的一种系统升级部署系统的结构示意图。

具体实施方式

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

传统的部署方式存在的问题有：（1）技术人员必须在晚间进行操作，留给测试人员及客户验证的时间少，容易出现升级失败；（2）版本升级及版本回退的操作过程比较繁琐，需要频繁的链接服务器，且代码的版本不好控制；（3）客户不能优先体验新版本的业务。

针对上述问题，本申请实施例提供一种基于GIT的系统升级部署方法，首先是模块版本管理模块，选择要部署的系统的功能模块（前端，后端），然后输入代码的版本，代码版本的对应git分支，然后更新的业务描述，然后配置JenkisJob的路径，选择代码打包的方式（手动，自动），然后点击保存实现一键打包；然后是项目往服务器上的推送，选择要推送的服务器信息，点击推送，实现代码的自动备份和自动更新。

下面结合附图，通过具体的实施例及其应用场景对本申请实施例提供的系统升级部署方法进行详细地说明。

如图1所示，为本申请实施例提供的一种系统升级部署方法流程图，该方法包括以下步骤：

步骤101，接收来自代码仓库的json文件，根据所述json文件包含的配置参数，判断是否启用自动构建。

具体地，在研发平台推送代码到代码仓库后，可以接收代码仓库通过设置好的web钩子推送的json文件。

其中，配置参数包括要部署的系统的功能模块、代码的版本，代码版本对应的git分支、更新后的业务描述、JenkisJob的路径，以及代码打包的方式。

本实施例中，还可以根据所述json文件包含的代码版本对应的git分支，确定所述研发平台推送的代码是否是指定的分支推送的代码，如果是，则确定启用自动构建；否则确定不启动自动构建。

步骤102，在确定启用自动构建的情况下，从所述代码仓库拉取源代码，并对所述源代码进行打包，得到包文件。

步骤103，将所述包文件发送到目标服务器的指定目录，在所述目标服务器上实现系统升级部署。

本实施例中，还可以添加灰度用户，以使所述灰度用户在版本灰度状态下优先体验新版本的升级内容，且除灰度用户之外的其他用户继续使用旧版本的内容；在所述灰度客户使用新版本的功能时没有发现问题的情况下，进行版本的全量灰度，并在所有用户的使用都没有问题，进行全量上线。

本申请实施例通过从代码仓库拉取源代码并打包，将得到的包文件发送到目标服务器的指定目录，并在目标服务器上实现系统升级部署，从而实现系统升级部署的全流程自动化。

在本申请实施例中，可以通过jenkins服务器实现系统升级部署方法，如图2所示，包括以下步骤：

1)、在gogs代码仓库创建webhook（web钩子）用于链接jenkins服务器；

2)、研发push代码到gogs仓库后，gogs仓库会通过设置好的web钩子推送一个json数据到jenkins服务器；

3)、jenkins服务器在接受到这个信息后，根据配置设置的内容进行判断，是否启用自动构建。如：是否是指定的分支push的代码等；

4)、Jenkins通过设置好的判断后，启用自动构建，进行相关的打包操作，jenkins有一个工作区，一般在root/.jenkins/workspace下，里面存放着拉取下来的源代码和打包好的包文件。Jenkins在同一任务重复构建时，是会先清理掉旧的项目文件，所以不用担心垃圾文件越来越多。只有项目越多文件越多；

5)、Jenkins一般是通过ssh将打包好的文件发送到目标服务器（部署服务器）的指定目录；

6)、在Jenkins服务器上的操作，称为“构建”，默认是在当前指定任务的工作目录下进行操作，所以你不会看到cd什么的操作；

7)、当构建后的操作执行完成后，整个构建过程全部完成。

此外，还可以通过提供灰度、全量灰度、回滚、全量上线功能实现发布上线，可以添加一部分的灰度用户，在版本灰度状态下，灰度用户可以优先体验新版本的升级内容，其他用户继续使用旧版本的内容。在客户使用功能没问题的前提下，再进行版本的全量灰度，如果所有用户的使用都没有问题，进行全量上线。如果使用发现问题，可以进行版本的回退。和传统的技术相比，可以通过界面很好的对版本进行控制，还可以让部分用户进行优先体验测试，出现问题可以进行及时的调整。

本申请实施例通过代码的一键打包、构建、测试、推送以及代码版本的灵活控制，能够实现产品上线部署的全流程自动化；通过系统正常版本和灰度版本同时在线，以及灰度用户配置，能够实现正常用户访问正常功能，灰度用户访问新版本，实现版本上线灰度、全量灰度和回滚等功能。

如图3所示，为本申请实施例提供的一种系统升级部署系统的结构示意图，其特征在于，包括：

接收模块310，用于接收来自代码仓库的json文件，根据所述json文件包含的配置参数，判断是否启用自动构建。

具体地，接收模块310，具体用于在研发平台推送代码到代码仓库后，接收代码仓库通过设置好的web钩子推送的json文件。

其中，配置参数包括要部署的系统的功能模块、代码的版本，代码版本对应的git分支、更新后的业务描述、JenkisJob的路径，以及代码打包的方式。

本实施例中，接收模块310，具体用于根据所述json文件包含的代码版本对应的git分支，确定所述研发平台推送的代码是否是指定的分支推送的代码，如果是，则确定启用自动构建；否则确定不启动自动构建。

拉取模块320，用于在确定启用自动构建的情况下，从所述代码仓库拉取源代码，并对所述源代码进行打包，得到包文件；

部署模块330，用于将所述包文件发送到目标服务器的指定目录，在所述目标服务器上实现系统升级部署。

本实施例中，上述系统，还包括：

添加模块，用于添加灰度用户，以使所述灰度用户在版本灰度状态下优先体验新版本的升级内容，且除灰度用户之外的其他用户继续使用旧版本的内容；在所述灰度客户使用新版本的功能时没有发现问题的情况下，进行版本的全量灰度，并在所有用户的使用都没有问题，进行全量上线。

本申请实施例通过从代码仓库拉取源代码并打包，将得到的包文件发送到目标服务器的指定目录，并在目标服务器上实现系统升级部署，从而实现系统升级部署的全流程自动化。

本申请实施例还提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述系统升级部署方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。其中，所述的计算机可读存储介质，如只读存储器（Read-Only Memory，简称ROM）、随机存取存储器（RandomAccess Memory， 简称RAM）、磁碟或者光盘等。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质（如ROM/RAM、磁碟、光盘）中，包括若干指令用以使得一台终端（可以是手机，计算机，服务器，空调器，或者网络设备等）执行本申请各个实施例所述的方法。

上面结合附图对本申请的实施例进行了描述，但是本申请并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本申请的启示下，在不脱离本申请宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本申请的保护之内。

Claims (10)

1.一种系统升级部署方法，其特征在于，包括以下步骤：

接收来自代码仓库的json文件，根据所述json文件包含的配置参数，判断是否启用自动构建；

在确定启用自动构建的情况下，从所述代码仓库拉取源代码，并对所述源代码进行打包，得到包文件；

将所述包文件发送到目标服务器的指定目录，在所述目标服务器上实现系统升级部署。

2.根据权利要求1所述的方法，其特征在于，所述配置参数包括要部署的系统的功能模块、代码的版本，代码版本对应的git分支、更新后的业务描述、JenkisJob的路径，以及代码打包的方式。

3.根据权利要求1所述的方法，其特征在于，所述接收来自代码仓库的json文件，具体包括：

在研发平台推送代码到代码仓库后，接收代码仓库通过设置好的web钩子推送的json文件。

4.根据权利要求3所述的方法，其特征在于，所述根据所述json文件包含的配置参数，判断是否启用自动构建，具体包括：

根据所述json文件包含的代码版本对应的git分支，确定所述研发平台推送的代码是否是指定的分支推送的代码，如果是，则确定启用自动构建；否则确定不启动自动构建。

5.根据权利要求1所述的方法，其特征在于，还包括：

添加灰度用户，以使所述灰度用户在版本灰度状态下优先体验新版本的升级内容，且除灰度用户之外的其他用户继续使用旧版本的内容；

在所述灰度客户使用新版本的功能时没有发现问题的情况下，进行版本的全量灰度，并在所有用户的使用都没有问题，进行全量上线。

6.一种系统升级部署系统，其特征在于，包括：

接收模块，用于接收来自代码仓库的json文件，根据所述json文件包含的配置参数，判断是否启用自动构建；

拉取模块，用于在确定启用自动构建的情况下，从所述代码仓库拉取源代码，并对所述源代码进行打包，得到包文件；

部署模块，用于将所述包文件发送到目标服务器的指定目录，在所述目标服务器上实现系统升级部署。

7.根据权利要求6所述的系统，其特征在于，所述配置参数包括要部署的系统的功能模块、代码的版本，代码版本对应的git分支、更新后的业务描述、JenkisJob的路径，以及代码打包的方式。

8.根据权利要求6所述的系统，其特征在于，

所述接收模块，具体用于在研发平台推送代码到代码仓库后，接收代码仓库通过设置好的web钩子推送的json文件。

9.根据权利要求8所述的系统，其特征在于，

所述接收模块，具体用于根据所述json文件包含的代码版本对应的git分支，确定所述研发平台推送的代码是否是指定的分支推送的代码，如果是，则确定启用自动构建；否则确定不启动自动构建。

10.根据权利要求6所述的系统，其特征在于，还包括：

添加模块，用于添加灰度用户，以使所述灰度用户在版本灰度状态下优先体验新版本的升级内容，且除灰度用户之外的其他用户继续使用旧版本的内容；在所述灰度客户使用新版本的功能时没有发现问题的情况下，进行版本的全量灰度，并在所有用户的使用都没有问题，进行全量上线。