CN115756553B - 一种软件服务器更新方法 - Google Patents

Abstract

本申请提供一种软件服务器的更新方法，包含代码提交控制、代码检测、数据库同步、自动打包部署和测试系统等五个步骤，代码提交者权限控制，在约定的时间点关闭代码提交权限，当关闭提交权限后，所有提交者的可提交次数重置为0；在可提交代码的时限内，判断提交者的可提交次数，若可提交次数>0，则允许提交，同时提交成功后其可提交次数减1，若可提交次数=0，则不允许提交；代码检测，通过比对代码DIFF和代码覆盖情况，得到未覆盖代码；在测试数据库同步和生产数据库中进行数据更新，自动打包部署，对目标服务器进行更新；测试系统，检测各个服务器确认是否更新成功。代码提交控制策略让代码提交变得可控，保证代码仓库里的代码都经过了测试。

Description

一种软件服务器更新方法

技术领域

本申请涉及一种软件服务器更新方法。

背景技术

传统的服务器更新方式主要有两种，一种是手动打包，然后上传到服务器；另一种是借助jenkins等持续集成工具自动打包后上传服务器。以java为例，传统的更新方式是，本地打出jar包或者war包，然后上传到服务器后重启tomcat生效，构建Java项目过程中，在执行项目编译时，Maven工具会根据Java项目的pom.xml文件中定义的第三方Jar包的信息到远程Maven仓库拉取这些第三方Jar包至本地Maven仓库，进而才能进行Java项目的项目编译，而从远程Maven仓库下载第三方Jar包单个下载的方式，增加了Java项目的项目构建时间，导致Java项目的项目构建效率低。

使用jenkins的情况下，可以在配置好后，一键打包并且上传，省去了人工打包上传的操作。

以现有的更先进的jenkins更新为例，jenkins只是解决了自动打包发布的问题，无法保证更新时版本库代码的可靠性以及服务器更新发布后系统是否正常，异常情况包括：

①因数据库不同步导致的线上报错

由于传统的软件开发环境一般包括测试数据库和正式数据库，在服务器更新的时候，如果数据库的变动没有及时同步到正式数据库，就会出现线上异常。

②因代码错误导致的线上报错

使用jenkins更新时，会拉取最新的代码进行打包操作，如果在测试人员验证代码后和更新之间，又提交了新的代码，那么就会导致未确认的代码被提交，从而增加线上错误的可能性。

③因某些原因导致的更新异常

由于jenkins更新只是执行了自动打包上传发布的操作，其无法保证更新后系统是否正常，因此在更新后往往需要测试人员进行回归测试。但是如果系统模块众多且复杂，测试人员很容易遗漏那些异常的更新。

发明内容

基于现有技术方案的特点和客观缺陷，本发明申请的目的是提出一种软件服务器的更新方法，最大限度简化更新操作，同时能够保证更新结果的可靠性。

一种软件服务器的更新方法，包含代码提交控制、代码检测、数据库同步、自动打包部署和测试系统等五个步骤，代码提交者权限控制，在约定的时间点关闭代码提交权限，当关闭提交权限后，所有提交者的可提交次数重置为0；在可提交代码的时限内，判断提交者的可提交次数，若可提交次数>0，则允许提交，同时提交成功后其可提交次数减1，若可提交次数=0，则不允许提交；

代码检测，上次发布的时间和当前时间作为比对时间节点，取获这段时间内代码变动的部分，即代码DIFF；以上次发布的时间和当前时间作为比对时间节点，获取代码覆盖情况；通过比对代码DIFF和代码覆盖情况，得到未覆盖代码，某个代码有变动，但是却没有执行过，说明测试上肯定没有覆盖到；根据未覆盖代码情况，测试人员再进行补漏性测试；

数据库同步，确定测试数据库的日志信息；在测试数据库中获取已配置数据库，已配置数据库为源端数据库中预先设置执行同步操作的数据，在已配置数据库中配置数据库生成多个代理作业，分别确定已配置数据库中需要添加或删除或更新的代理作业；

自动打包部署，对目标服务器进行更新；

测试系统，检测各个服务器确认是否更新成功。

进一步，可以根据需要，同时告知提交目的，测试人员根据提交目的进行定向测试。

进一步，进行数据更新时，使用增量同步的方式，仅将上一次同步的时间点至本次同步的时间点之间产生数据改变进行更新。

进一步，数据更新时，获取每个源更新操作中的条件列信息集合和更新列信息集合，条件列信息集合中包含相应的源更新操作中所有的条件列的列名和值，更新列信息集合中包含相应的源更新操作所有的更新列的列名和值。

进一步，获取到的每组需同步的源更新操作中包含一个或多个连续的源更新操作，每个源更新操作对应一个Update语句，每个Update语句中包含一个或多个条件列信息，还包含了一个或多个更新列信息，每个条件列信息包含列名及该列的当前值，每个更新列信息包含列名及该列更新后的值。

进一步，每组需要同步的源更新操作中，所有源更新操作包含的条件列信息的并集为条件列信息集合，所有源更新操作包含的更新列信息的并集为更新列信息集合。

进一步，数据库执行SQL语句时，直接在SQL语句中直接写入对应的值，执行SQL语句时直接使用该值；合并后的SQL语句会包含需同步的源更新操作中所有对应的更新列信息集合和条件列信息集合中的列值为对应行的对应参数赋值。

进一步，将目的更新语句作为目的更新操作提交至测试数据库，使用绑定数据行中的值批量更新目的数据库；测试数据库在执行目的更新语句时调用每条源更新操作对应的绑定数据行中的值，完成多行数据的批量更新。

进一步，选择更新的目标服务器，根据从前端获取的待发布项目信息和待部署的服务器信息生成多个包含配置信息的配置文件，配置文件与待部署的服务器一一对应；获取项目代码并进行编译打包，向目标服务器发布；根据配置文件选定目标服务器，将编译好的代码同步到选定的目标服务器，从代码仓库拉取最新的代码，利用jenkins进行自动生成更新包，根据所使用的远程管理协议分发到目标服务器上。

进一步，经检测各个服务器的状态：维护一个接口池，这个接口池包含了每一个服务器中核心的接口；逐个调用接口池中的接口，获得接口返回结果，若某个服务器的接口都返回正常，则说明服务器更新正常；否则说明更新出现异常，需要排查。

本发明与背景技术相比，具有的有益的效果是： 通过本方案的流程，避免了未经测试的代码外放的风险，可以保证代码仓库代码的可靠性；同时通过数据库比对同步，来确保数据库表结构的同步更新，避免漏同步导致的线上异常；通过jenkins，让打包发布变得简单，更新人员不再需要直接进入服务器进行更新，提高了更新效率，降低了误操作的风险；最后通过测试系统，来快速检测每个服务器的更新结果，有效减少了测试人员回归测试的时间。

附图说明

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

本说明书附图所绘示的结构、比例、大小等，均仅用以配合说明书所揭示的内容，以供熟悉此技术的人士了解与阅读，并非用以限定本申请可实施的限定条件，故不具技术上的实质意义，任何结构的修饰、比例关系的改变或大小的调整，在不影响本申请所能产生的功效及所能达成的目的下，均应仍落在本申请所揭示的技术内容能涵盖的范围内。

图1为本申请软件服务器的更新方法的一种实施例示意图。

具体实施方式

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

基于现有技术方案的特点和客观缺陷，本申请提出一种软件服务器的更新方法，基于开发过程中限制性提交策略结合代码覆盖率检测手段，能最大限度避免测试遗漏；生产环境和开发环境的数据库比对及审批后自动同步策略，能够避免表结构的更新遗漏，同时以更安全的方式同步到生产环境；自动化打包部署结合跑服策略，能高效进行系统全量更新及验证。能最大限度简化更新操作，同时能够保证更新结果的可靠性。

实施例1

如附图1所示，本申请提出的软件服务器的更新方法包括代码提交控制、代码检测、数据库同步、自动打包部署和测试系统等五个步骤。

一、代码提交控制

在开发过程中，开发人员提交的代码，都必须经过测试人员测试通过后，才能更新到生产环境，因此，在进行软件服务器更新时，需要确保没有未经测试的代码提交，尤其是在多人协作开发的环境下，十分不可控，所以需要对代码提交进行控制。

首先，在约定的时间点关闭代码提交权限；其次，为了保证依然可以提交代码，提出一种限制性提交策略，即在提交代码时，判断代码提交者的可提交次数，当关闭提交权限后，所有提交者的可提交次数重置为0。若可提交次数>0，则允许提交，同时提交成功后其可提交次数减1；若可提交次数=0，则不允许提交，提交者需要向测试人员申请增加提交次数，同时告知提交目的，方便后续测试人员进行定向测试。此策略可以让代码提交变得可控，保证代码仓库里的代码都经过了测试。

二、代码检测

在更新发布之前，还要再做一次代码检测，来检测测试遗漏的部分。代码检测的方法包括：首先，以上次发布的时间和当前时间作为比对时间节点，获取代码DIFF，即这段时间内代码变动的部分。

代码检测时，获取代码DIFF即修改时间段内代码变动的部分，包括变更参数、操作人员、内容以及修改的时间参数等。具体地，代码提交日志检测时包括：提取待提交代码的日志参数，日志参数用于待提交代码的修改信息，日志参数包括变更号参数、操作人参数、提交内容参数及修改时间参数中的一个或者多个；将日志参数中的每一个参数的参数类型和日志参数中每一个参数的参数信息与预设代码提交规则进行比较；若日志参数的参数类型中包括与预设代码提交规则中的参数类型匹配的参数类型，且日志参数中每一个参数的参数信息符合预设代码提交规则中参数规范，提交待提交代码与预设代码提交规则进行比较，通过hook函数提取日志参数中每一个参数的参数类型和日志参数中每一个参数的参数信息；将日志参数中的每一个参数的参数类型和日志参数中每一个参数的参数信息与预设代码提交规则进行比较；若日志参数中没有包括与预设代码提交规则中的参数类型匹配的参数类型，或者日志参数的参数信息不符合预设代码提交规则中参数规范，则表明代码有变动，需要根据所述预设代码提交规则修改日志参数。

然后，以上次发布的时间和当前时间作为比对时间节点，获取代码覆盖情况，即这段时间内有运行过的代码；最后，通过比对代码DIFF和代码覆盖情况，即可得到未覆盖代码，因为假如某个代码有变动，但是却没有执行过，说明测试上肯定没有覆盖到。根据未覆盖代码情况，测试人员再进行补漏性测试，即可完全杜绝未测试代码更新到生产环境的情况。

三、数据库同步

大多数时候，生产环境数据库是有访问权限控制的，开发人员正常都在测试数据库上进行修改。每一次版本迭代，很大概率都会涉及数据库表结构的变更，如果代码更新到了生产环境，但是生产环境的数据库表结构还是旧的，就会导致两者不匹配，从而出现系统报错。因此，可以对生产数据库和测试数据库进行表结构比对，生成差异结果，由开发人员进行确认，再由项目经理进行审批，审批通过后，可以指定同步的时间，完成数据库的更新。

在进行数据同步时，需要将源端数据库首先同步至测试数据库中。

确定测试数据库的日志信息；在测试数据库中获取已配置数据库，已配置数据库为源端数据库中预先设置执行同步操作的数据，在已配置数据库中配置数据库生成多个代理作业，分别确定已配置数据库中需要添加或删除或更新的代理作业；分别对已配置数据库进行添加或删除或更新已配置数据库中需要添加或删除或更新的代理作业，得到修改后的数据库；对需要添加或删除或更新的代理作业。

本申请进行数据更新时，使用增量同步的方式，仅将上一次同步的时间点至本次同步的时间点之间产生数据改变进行更新。在数据库操作中，源端数据库执行添加、删除和更新操作会造成数据库中的数据改变。因此，进行增量同步时，仅需在目的端数据中重复上一次同步的时间点至本次同步的时间点之间源端数据库进行的添加、删除和更新操作，就可以使测试数据库产生同样的数据改变，完成数据同步。

获取每个源更新操作中的条件列信息集合和更新列信息集合，条件列信息集合中包含相应的源更新操作中所有的条件列的列名和值，更新列信息集合中包含相应的源更新操作所有的更新列的列名和值。

获取到的每组需同步的源更新操作中包含一个或多个连续的源更新操作，每个源更新操作对应一个Update语句，每个Update语句中包含一个或多个条件列信息，还包含了一个或多个更新列信息，每个条件列信息包含列名及该列的当前值，每个更新列信息包含列名及该列更新后的值。每组需要同步的源更新操作中，所有源更新操作包含的条件列信息的并集为条件列信息集合，所有源更新操作包含的更新列信息的并集为更新列信息集合。

根据所有源更新操作的条件列信息集合和更新列信息集合，生成用于同步的目的更新语句。

在本实施例提供的方法中，为了保证合并后仅产生一条SQL语句，同时保证操作执行顺序正确，因此仅将连续的更新操作进行合并。 数据库执行SQL语句时，可以直接在SQL语句中直接写入对应的值，执行SQL语句时直接使用该值；合并后的SQL语句会包含需同步的源更新操作中所有的更新列和所有的条件列，可以使用每个源更新操作对应的更新列信息集合和条件列信息集合中的列值为对应行的对应参数赋值。将目的更新语句作为目的更新操作提交至测试数据库，使用绑定数据行中的值批量更新目的数据库。

测试数据库在执行目的更新语句时调用每条源更新操作对应的绑定数据行中的值，完成多行数据的批量更新，实现了减少操作提交次数和SQL语句数量，降低测试数据库的同步延迟的效果。

由于测试数据库中所有的操作都记录在测试数据库日志中，可以根据源端数据库日志中的操作记录，获取源端数据库上一次同步至本次同步之间的每组连续的更新操作，作为需要同步的源更新操作。在后续的步骤中，会将每组连续的更新操作合并为一个目的更新语句，该组连续的更新操作与合并后的目的更新语句执行完成后，在测试数据库产生的数据变化与源端数据库的数据变化一致，在保证数据同步准确性的基础上，达到减少操作数量，降低同步延迟的效果。

在测试服务器的测试数据库测试通过后，再升级部署各套线上正式数据库。为避免线上环境的更改，也可以在测试数据库和正式数据库之间进行差异检测，生成新的差异同步脚本后再进行升级。

四、自动打包部署

在微服务架构或者集群环境中，每一次更新都会涉及大量服务器的同步更新。首先选择更新的目标服务器，根据从前端获取的待发布项目信息和待部署的服务器信息生成多个包含配置信息的配置文件，配置文件与待部署的服务器一一对应；获取项目代码并进行编译打包，准备向目标服务器发布；根据配置文件选定目标服务器，将编译好的代码同步到选定的目标服务器，其中：对于系统中的每个服务器集群预配置了用于支持文件传输、远程命令执行的远程管理协议，在代码同步之前首先确定选定的目标服务器所在集群使用的远程管理协议；然后从代码仓库拉取最新的代码，利用jenkins进行自动生成更新包，然后根据所使用的远程管理协议分发到目标服务器上。

五、测试系统

经过自动打包部署后，还是无法确认是否更新成功，因此需要一个测试系统来检测各个服务器的状态。首先，维护一个接口池，这个接口池包含了每一个服务器中核心的接口；然后，逐个调用接口池中的接口，获得接口返回结果，若某个服务器的接口都返回正常，则说明服务器更新正常，否则说明更新出现异常，需要排查。

通过本方案的流程，避免了未经测试的代码外放的风险，可以保证代码仓库代码的可靠性；同时通过数据库比对同步，来确保数据库表结构的同步更新，避免漏同步导致的线上异常，减少操作数量，降低同步延迟；通过jenkins，让打包发布变得简单，更新人员不再需要直接进入服务器进行更新，提高了更新效率，降低了误操作的风险；最后通过测试系统，来快速检测每个服务器的更新结果，有效减少了测试人员回归测试的时间。

本说明书中各个实施例采用递进、或并列、或递进和并列结合的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

需要说明的是，在本申请的描述中，需要理解的是，术语“上”、“下”、“顶”、“底”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本申请和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本申请的限制。当一个组件被认为是“连接”另一个组件，它可以是直接连接到另一个组件或者可能同时存在居中设置的组件。

还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括上述要素的物品或者设备中还存在另外的相同要素。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (5)

1.一种软件服务器的更新方法，包含代码提交控制、代码检测、数据库同步、自动打包部署和测试系统等五个步骤，其特征在于，代码提交者权限控制，在约定的时间点关闭代码提交权限，当关闭提交权限后，所有提交者的可提交次数重置为0；在可提交代码的时限内，判断提交者的可提交次数，若可提交次数>0，则允许提交，同时提交成功后其可提交次数减1，若可提交次数=0，则不允许提交；

代码检测，上次发布的时间和当前时间作为比对时间节点，取获这段时间内代码变动的部分，即代码DIFF；以上次发布的时间和当前时间作为比对时间节点，获取代码覆盖情况；通过比对代码DIFF和代码覆盖情况，得到未覆盖代码，某个代码有变动，但是却没有执行过，说明测试上肯定没有覆盖到；根据未覆盖代码情况，测试人员再进行补漏性测试；

数据库同步，确定测试数据库的日志信息；在测试数据库中获取已配置数据库，已配置数据库为源端数据库中预先设置执行同步操作的数据，在已配置数据库中配置数据库生成多个代理作业，分别确定已配置数据库中需要添加或删除或更新的代理作业；

自动打包部署，对目标服务器进行更新；

测试系统，检测各个服务器确认是否更新成功；

进行数据更新时，使用增量同步的方式，仅将上一次同步的时间点至本次同步的时间点之间产生数据改变进行更新；

数据更新时，获取每个源更新操作中的条件列信息集合和更新列信息集合，条件列信息集合中包含相应的源更新操作中所有的条件列的列名和值，更新列信息集合中包含相应的源更新操作所有的更新列的列名和值；

获取到的每组需同步的源更新操作中包含一个或多个连续的源更新操作，每个源更新操作对应一个Update语句，每个Update语句中包含一个或多个条件列信息，还包含了一个或多个更新列信息，每个条件列信息包含列名及该列的当前值，每个更新列信息包含列名及该列更新后的值；

每组需要同步的源更新操作中，所有源更新操作包含的条件列信息的并集为条件列信息集合，所有源更新操作包含的更新列信息的并集为更新列信息集合；

数据库执行SQL语句时，直接在SQL语句中直接写入对应的值，执行SQL语句时直接使用该值；合并后的SQL语句会包含需同步的源更新操作中所有对应的更新列信息集合和条件列信息集合中的列值为对应行的对应参数赋值。

2.根据权利要求1所述的一种软件服务器的更新方法，其特征在于，代码提交者可以根据需要向测试人员申请增加提交次数，同时告知提交目的，测试人员根据提交目的进行定向测试。

3.根据权利要求1所述的一种软件服务器的更新方法，其特征在于，将目的更新语句作为目的更新操作提交至测试数据库，使用绑定数据行中的值批量更新目的数据库；测试数据库在执行目的更新语句时调用每条源更新操作对应的绑定数据行中的值，完成多行数据的批量更新。

4.根据权利要求1所述的一种软件服务器的更新方法，其特征在于，选择更新的目标服务器，根据从前端获取的待发布项目信息和待部署的服务器信息生成多个包含配置信息的配置文件，配置文件与待部署的服务器一一对应；获取项目代码并进行编译打包，向目标服务器发布；根据配置文件选定目标服务器，将编译好的代码同步到选定的目标服务器，从代码仓库拉取最新的代码，利用jenkins进行自动生成更新包，根据所使用的远程管理协议分发到目标服务器上。

5.根据权利要求1所述的一种软件服务器的更新方法，其特征在于，经检测各个服务器的状态：维护一个接口池，这个接口池包含了每一个服务器中核心的接口；逐个调用接口池中的接口，获得接口返回结果，若某个服务器的接口都返回正常，则说明服务器更新正常；否则说明更新出现异常，需要排查。

Images