CN103220163B - 配置信息的更新方法和系统 - Google Patents

Abstract

本申请公开了一种配置信息的更新方法和系统，其中，该方法包括：配置管理中心接收开发节点设备提交的配置修改申请单，其中，配置修改申请单中记录有待更新的第一配置项；配置管理中心接收测试节点设备提交的配置修改申请单，其中，该配置修改申请单是测试节点设备将待更新的第二配置项记录在开发节点设备提交的配置修改申请单中得到的配置修改申请单，第二配置项为测试节点设备在进行当前测试时采用的配置项；配置管理中心响应于发布节点设备的请求根据第一配置项和第二配置项对配置管理中心中预设的配置信息进行更新，其中，更新后的配置信息用于线上发布应用。本申请解决配置信息不能实时地同步的问题，实现了多个环境配置信息的同步。

Description

配置信息的更新方法和系统

技术领域

本申请涉及互联网领域，具体而言，涉及一种配置信息的更新方法和系统。

背景技术

在应用的开发、测试以及打包部署等各个环境中，往往都需要相应的环境以及对外部系统的依赖等相关的配置信息，这些配置信息一般是由依赖项标识(key)和依赖项特定环境值(value)组成。在开发环境、测试环境、线上环境以及生产环境中，一般配置信息的key是完全相同的，value的值是各不相同的。同时，在开发和测试过程中，每个环节都有其对应的相关的配置信息。

然而，在开发过程中，对同一个应用，不同的开发团队会做不同的配置项的新增操作或者是修改操作，但是团队之间告知却是滞后的，如果在开发过程中缺少配置信息，往往无法正常启动应用。

进一步的，在开发完毕后提交测试、以及测试完毕后提交发布，都需要传递对配置信息的变更信息，开发团队在对同一应用的配置信息更新时，如果不能及时的相互通知，会导致无法正常编译运行，开发提交测试时或者提交发布时，如果配置信息传递错误，会导致下一任务无法正常执行。

基于上述可以发现，现有技术中，在开发过程中主要存在如下的问题：

1)需要维护多个环境中的配置信息，维护效率低；

2)多个环境中的配置信息不能实时地同步，从而导致在应用发布时出现故障。

发明内容

本申请提供了一种配置信息的更新方法和系统，以至少解决现有技术中多个环境中的配置信息不能实时地同步，从而导致在应用发布时出现故障的问题。

根据本申请的一个方面，提供了一种配置信息的更新方法，该方法包括：配置管理中心接收应用发布过程中的开发节点设备提交的配置修改申请单，其中，配置修改申请单中记录有待更新的第一配置项；配置管理中心接收应用发布过程中的测试节点设备提交的配置修改申请单，其中，测试节点设备提交的配置修改申请单是测试节点设备将待更新的第二配置项记录在从配置管理中心中获取的由开发节点设备提交的配置修改申请单中得到的配置修改申请单，第二配置项为测试节点设备在进行当前测试时采用的配置项；配置管理中心响应于应用发布过程中的发布节点设备的请求根据配置修改申请单中的第一配置项和第二配置项对配置管理中心中预设的配置信息进行更新，其中，更新后的配置信息用于线上发布应用。

优选地，在配置管理中心响应于应用发布过程中的发布节点设备的请求根据配置修改申请单中的第一配置项和第二配置项对配置管理中心中预设的配置信息进行更新之后，配置信息的更新方法还包括：发布节点设备将更新后的配置信息提交给审核节点设备；发布节点设备在接收到审核节点设备返回的用于指示更新的响应消息之后，根据更新后的配置信息对应用进行离线自动测试。

优选地，在根据更新后的配置信息对应用进行离线自动测试之后，配置信息的更新方法还包括：若离线自动测试结果正常，则根据更新后的配置信息对应用进行线上发布。

优选地，通过如下步骤进行当前测试：根据第二配置项搭建测试环境；在搭建的测试环境下，响应于输入的测试命令对应用进行测试。

优选地，经第一配置项和第二配置项更新后的配置信息与应用的分支程序对应。

优选地，在根据更新后的配置信息对应用进行线上发布之后，配置信息的更新方法还包括：将更新后的配置信息合并到与应用的主干程序对应的主干配置信息中。

根据本申请的另一方面，提供了一种配置信息的更新系统，包括：开发节点设备，用于在应用发布过程中向配置管理中心提交配置修改申请单，其中，配置修改申请单中记录有待更新的第一配置项；测试节点设备，用于在应用发布过程中从配置管理中心中获取配置修改申请单，将当前测试采用的配置项作为待更新的第二配置项记录在配置修改申请单，并将记录有第一配置项和第二配置项的配置修改申请单提交给配置管理中心；发布节点设备，用于在应用发布过程中根据配置修改申请单中的第一配置项和第二配置项对配置管理中心中预设的配置信息进行更新，其中，更新后的配置信息用于线上发布应用。

优选地，发布节点设备包括：提交单元，用于在对配置管理中心中预设的配置信息进行更新之后，将更新后的配置信息提交给审核节点设备；第一测试单元，用于在接收到审核节点设备返回的用于指示更新的响应消息之后，根据更新后的配置信息对应用进行离线自动测试。

优选地，配置信息的更新系统还包括：审核节点设备；审核节点设备包括：接收单元，用于接收发布节点设备提交的更新后的配置信息；响应单元，用于响应更新后的配置信息向发布节点设备发送指示更新的响应消息。

优选地，配置信息的更新系统还包括：发布节点设备，用于在测试单元根据更新后的配置信息对应用进行离线自动测试之后，当离线自动测试结果正常，根据更新后的配置信息对应用进行线上发布。

优选地，测试节点设备包括：搭建单元，用于根据第二配置项搭建测试环境；第二测试单元，用于在搭建的测试环境下，响应于输入的测试命令对应用进行测试。

优选地，发布节点设备包括：合并单元，用于在根据更新后的配置信息对应用进行线上发布之后，将更新后的配置信息合并到与应用的主干程序对应的主干配置信息中，其中，经第一配置项和第二配置项更新后的配置信息与应用的分支程序对应。

在本申请中，通过配置管理中心对配置项进行统一的管理，解决了现有技术中多个环境中的配置信息不能实时地同步，从而导致在应用发布时出现故障的问题，本申请达到了配置项的统一管理，实现了多个环境配置信息的同步，提高了配置信息的维护效率，降低了应用发布发生故障的概率。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请实施例的配置信息的更新系统的一种优选结构框图；

图2是根据本申请实施例的配置信息的更新系统的另一种优选结构框图；

图3是根据本申请实施例的配置信息的更新系统的又一种优选结构框图；

图4是根据本申请实施例的配置信息的更新系统的又一种优选结构框图；

图5是根据本申请实施例的配置信息的更新方法的一种优选流程图；

图6是根据本申请实施例的配置信息的更新方法的另一种优选流程图；

图7是根据本申请实施例的配置信息的更新方法的又一种优选流程图；

图8是根据本申请实施例的配置信息的更新方法的又一种优选流程图；

图9是根据本申请实施例的配置信息的更新中预合并中配置信息格式的一种优选示意图；

图10是根据本申请实施例的配置信息的更新中预合并的一种优选示意图；

图11是根据本申请实施例的配置信息的更新方法中系统的功能组件的一种优选示意图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本申请。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

在描述本申请的各实施例的进一步细节之前，将参考图1来描述可用于实现本申请的原理的一个合适的计算体系结构。在以下描述中，除非另外指明，否则将参考由一个或多个计算机执行的动作和操作的符号表示来描述本申请的各实施例。由此，可以理解，有时被称为计算机执行的这类动作和操作包括计算机的处理单元对以结构化形式表示数据的电信号的操纵。这一操纵转换了数据或在计算机的存储器系统中的位置上维护它，这以本领域的技术人员都理解的方式重配置或改变了计算机的操作。维护数据的数据结构是具有数据的格式所定义的特定属性的存储器的物理位置。然而，尽管在上述上下文中描述本申请，但它并不意味着限制性的，如本领域的技术人员所理解的，后文所描述的动作和操作的各方面也可用硬件来实现。

转向附图，其中相同的参考标号指代相同的元素，本申请的原理被示为在一个合适的计算环境中实现。以下描述基于所述的本申请的实施例，并且不应认为是关于此处未明确描述的替换实施例而限制本申请。

图1示出了可用于这些设备的一个示例计算机体系结构的示意图。出于描述的目的，所绘的体系结构仅为合适环境的一个示例，并非对本申请的使用范围或功能提出任何局限。也不应将该计算系统解释为对图1所示的任一组件或其组合具有任何依赖或需求。

本申请的原理可以使用其它通用或专用计算或通信环境或配置来操作。适用于本申请的众所周知的计算系统、环境和配置的示例包括但不限于，个人计算机、服务器，多处理器系统、基于微处理的系统、小型机、大型计算机、以及包括任一上述系统或设备的分布式计算环境。

在其最基本的配置中，图1中的配置信息的更新系统100至少包括：一个网站的服务器102以及一个或多个客户端104。服务器102可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置、用于存储数据的存储装置以及与客户端通信的传输装置；客户端104可以包括：微处理器MCU、与服务器通信的传输装置、与用户交互的显示装置。在本说明书和权利要求书中，“系统”也可以被定义为能够执行软件、固件或微码来实现功能的任何硬件组件或硬件组件的组合。配置信息的更新系统100甚至可以是分布式的，以实现分布式功能。

如本申请所使用的，术语“模块”、“组件”或“单元”可以指在配置信息的更新系统100上执行的软件对象或例程。此处所描述的不同组件、模块、单元、引擎和服务可被实现为在配置信息的更新系统100上执行(例如，作为单独的线程)的对象或进程。尽管此处所描述的系统和方法较佳地以软件来实现，但是硬件或软件和硬件的组合的实现也是可能并被构想的。

实施例1

图2是根据本申请实施例配置信息的更新系统的一种优选的结构示意图，优选地，本实施例中的系统位于服务器102上或者客户端104上。

优选地，如图2所示的配置信息的更新系统可以包括：

1)开发节点设备202，用于在应用发布过程中向配置管理中心208提交配置修改申请单，其中，配置修改申请单中记录有待更新的第一配置项；

2)测试节点设备204，用于在应用发布过程中从配置管理中心208中获取配置修改申请单，将当前测试采用的配置项作为待更新的第二配置项记录在配置修改申请单，并将记录有第一配置项和第二配置项的配置修改申请单提交给配置管理中心208；

3)发布节点设备206，用于在应用发布过程中根据配置修改申请单中的第一配置项和第二配置项对配置管理中心208中预设的配置信息进行更新，其中，更新后的配置信息用于线上发布应用。

在上述优选实施方式中，开发节点设备、测试节点设备、以及发布节点设备通过配置管理中心对配置项进行统一的管理，解决了现有技术中多个环境中的配置信息不能实时地同步，从而导致在应用发布时出现故障的问题，本申请达到了配置项的统一管理，实现了多个环境配置信息的同步，提高了配置信息的维护效率，降低了应用发布发生故障的概率。

在实际的应用开发中，一个应用通常是在多团队、多人以及多需求间进行开发的，配置项的修改往往需要提前做出申请，并将这些修改在配置管理中心中预先体现，为了方便合作开发以及对配置信息进行统一管理，每次对配置信息的修改，都以单据的形式进行控制和管理，这些单据就组成了配置修改申请单。

本申请一个优选实施方式中，如图3所示，配置信息的更新系统还包括：审核节点设备210，发布节点设备206包括：提交单元302，第一测试单元304。审核节点设备210包括：接收单元306，响应单元308。其中，提交单元302用于在对配置管理中心中预设的配置信息进行更新之后，将更新后的配置信息提交给审核节点设备；接收单元306，用于接收发布节点设备提交的更新后的配置信息；响应单元308，用于响应更新后的配置信息向发布节点设备发送指示更新的响应消息；第一测试单元304，用于在接收到审核节点设备返回的用于指示更新的响应消息之后，根据更新后的配置信息对应用进行离线自动测试。在上述优选实施方式中，通过增加审核节点设备，可以有效地判断更新后的配置信息是否合理。

优选地，上述实施例中的离线自动测试包括如下步骤：将与分支程序对应的更新后的配置信息预合并到与主干程序对应的主干配置信息中，并将分支程序与主干程序进行合并，根据合并后的配置信息对合并了分支程序的主干程序进行联合测试。

在本申请一个优选实施方式中，发布节点设备206还用于当离线自动测试结果正常，根据更新后的配置信息对应用进行线上发布。在上述优选实施方式中，在对预设的配置信息进行更新之后，通过审核节点设备对更新的配置信息项进行审核，在审核通过以后，对应用进行测试，在测试成功以后才将更新后的配置信息在线上发布，从而在保证了更新的配置信息不会影响后续的审核和发布的过程的前提下，才将这些更新的配置信息进行线上发布，提高了应用发布后的稳定性，减少了因为更新的配置信息不正确而导致应用开发出错的可能性，减少了配置项传递过程中的错误和产品发布的风险。

在本申请一个优选实施方式中，如图4所示，测试节点设备204包括：搭建单元402，用于根据第二配置项搭建测试环境；第二测试单元404，用于在搭建的测试环境下，响应于输入的测试命令对应用进行测试。

在本申请一个优选实施方式中，发布节点设备206还用于在根据所述更新后的配置信息对所述应用进行线上发布之后，将更新后的配置信息合并到与应用的主干程序对应的主干配置信息中，其中，经第一配置项和第二配置项更新后的配置信息与应用的分支程序对应。在上述优选实施方式中，将主干程序作为一个稳定的、可发布的程序，当需要向该主干程序中增加分支程序时，先对增加的分支程序进行单独检测，当该分支程序独立运行正常后，将该分支程序预合并到主干程序中进行联合测试，如果联合测试的结果正常，再将分支程序合并到主干程序中，并将经过测试的、与分支程序对应的配置信息在应用正式发布之后加入到主干配置信息中，从而保证了程序发布的稳定性，避免了因为分支程序配置的不合理而导致整个主干程序的发布出现问题。

实施例2

在图2-图4所示的系统的基础上，本申请提供了一种优选的配置信息的更新方法。如图5所示，该方法可以包括如下步骤：

S502：配置管理中心接收应用发布过程中的开发节点设备提交的配置修改申请单，其中，配置修改申请单中记录有待更新的第一配置项。也就是说，应用发布过程中的开发节点设备向配置管理中心提交配置修改申请单，其中，配置修改申请单中记录有待更新的第一配置项；

S504：配置管理中心接收应用发布过程中的测试节点设备提交的配置修改申请单，其中，测试节点设备提交的配置修改申请单是测试节点设备将待更新的第二配置项记录在从配置管理中心中获取的由开发节点设备提交的配置修改申请单中得到的配置修改申请单，第二配置项为测试节点设备在进行当前测试时采用的配置项。也就是说，应用发布过程中的测试节点设备从配置管理中心中获取配置修改申请单，将当前测试采用的配置项作为待更新的第二配置项记录在配置修改申请单，并将记录有第一配置项和第二配置项的配置修改申请单提交给配置管理中心；

S506：配置管理中心响应于应用发布过程中的发布节点设备的请求根据配置修改申请单中的第一配置项和第二配置项对配置管理中心中预设的配置信息进行更新，其中，更新后的配置信息用于线上发布应用。也就是说，应用发布过程中的发布节点设备根据配置修改申请单中的第一配置项和第二配置项对配置管理中心中预设的配置信息进行更新，其中，更新后的配置信息用于线上发布应用。

在上述优选实施方式中，开发节点设备、测试节点设备、以及发布节点设备通过配置管理中心对配置项进行统一的管理，解决了现有技术中多个环境中的配置信息不能实时地同步，从而导致在应用发布时出现故障的问题，本申请达到了配置项的统一管理，实现了多个环境配置信息的同步，提高了配置信息的维护效率，降低了应用发布发生故障的概率。

在本申请一个优选实施方式中，可以通过如图6所示的步骤进行当前测试，具体包括：

S602：根据第二配置项搭建测试环境；

S604：在搭建的测试环境下，响应于输入的测试命令对应用进行测试。

在上述优选实施方式中，通过第二配置项搭建测试环境，可以有效判断配置项的配置是否合理。

在本申请一个优选实施方式中，在应用发布过程中的发布节点设备根据配置修改申请单中的第一配置项和第二配置项对配置管理中心中预设的配置信息进行更新之后(即，在所述配置管理中心响应于所述应用发布过程中的发布节点设备的请求根据所述配置修改申请单中的所述第一配置项和所述第二配置项对所述配置管理中心中预设的配置信息进行更新之后)，如图7所示，本实施例中的配置信息的更新方法还可以包括：

S702：发布节点设备将更新后的配置信息提交给审核节点设备；

S704：发布节点设备在接收到审核节点设备返回的用于指示更新的响应消息之后，根据更新后的配置信息对应用进行离线自动测试；

S706：当所述离线自动测试结果正常后，根据所述更新后的配置信息对所述应用进行线上发布。

在上述优选实施方式中，在对预设的配置信息进行更新之后，通过审核节点设备对更新的配置信息项进行审核，在审核通过以后，对应用进行测试，在测试成功以后才将更新后的配置信息在线上发布，从而在保证了更新的配置信息不会影响后续的审核和发布的过程的前提下，才将这些更新的配置信息进行线上发布，提高了应用发布后的稳定性，减少了因为更新的配置信息不正确而导致应用开发出错的可能性，减少了配置项传递过程中的错误和产品发布的风险。

优选地，上述实施例中的离线自动测试包括如下步骤：将与分支程序对应的更新后的配置信息预合并到与主干程序对应的主干配置信息中，并将分支程序与主干程序进行合并，根据合并后的配置信息对合并了分支程序的主干程序进行联合测试。

在本申请一个优选实施方式中，经第一配置项和第二配置项更新后的配置信息与应用的分支程序是对应关系，在根据更新后的配置信息对应用进行线上发布之后，再将更新后的配置信息合并到与应用的主干程序对应的主干配置信息中。

在上述优选实施方式中，将主干程序作为一个稳定的、可发布的程序，当需要向该主干程序中增加分支程序时，先对增加的分支程序进行单独检测，当该分支程序独立运行正常后，将该分支程序预合并到主干程序中进行联合测试，如果联合测试的结果正常，再将分支程序合并到主干程序中，并将经过测试的、与分支程序对应的配置信息在应用正式发布之后加入到主干配置信息中，从而保证了程序发布的稳定性，避免了因为分支程序配置的不合理而导致整个主干程序的发布出现问题。

实施例3

本申请提供了一种优选的实施例来进一步对本申请进行解释，但是值得注意的是，该优选实施例只是为了更好的描述本申请，并不构成对本申请不当的限定。

应用的开发一般包括：开发阶段、测试阶段、审核阶段以及发布阶段4个阶段，如图8所示，这4个阶段的配置项信息的更新的步骤包括：

1)开发阶段主要包括：

S802：开发节点设备创建一个应用，并创建配置修改申请单，其中，配置修改申请单是应用配置信息的一个具体实现，代表某次修改的配置信息片段，一次项目或者是一次小的应用需求对应一份配置修改申请单。

S804：开发节点设备将待更新的配置项添加到配置信息修改申请单中，配置项包括：配置项标识和配置项的值，其中，一个配置项值对应一个配置项标识，配置项标识在开发阶段、测试阶段、审核阶段和发布阶段是相同的，而配置项值根据阶段的不同对应多个不同的值。

S806：开发节点设备将携带有待更新的配置项的配置修改申请单提交到配置管理中心，其中，配置项是配置修改申请单中某一项对应的配置信息，优选地，配置管理中心的配置修改申请单信息是被测试阶段的测试节点设备、开发阶段的开发节点设备以及发布阶段的发布节点设备所共享的。

2)测试阶段主要包括：

S808：测试节点设备开发提测，开发阶段接收后提交测试阶段进行测试；

S810：测试节点设备修改测试环境配置信息，并从配置管理中心获取配置修改申请单，并将本次测试依赖的测试环境值作为待更新的配置项记录在配置修改申请单中，这时，配置修改申请单中有开发节点设备待更新的配置项以及测试节点设备待更新的配置项；

S812：测试节点设备搭建测试环境。

3)审核阶段主要包括：

S814：测试结束后，审核节点设备提交预发布。

S816：审核节点设备从配置管理中心获取有开发节点设备和测试节点设备待更新的配置项的配置信息，应用管理员对更新后的配置信息中的配置项以及配置项的值进行审核。

S818：测试应用管理员审核，主要审核自动化测试环境值及配置项，在审核通过后，审核节点设备向发布节点设备返回用于指示的更新响应消息。

4)发布阶段主要包括：

S820：发布节点设备响应于该更新响应消息，进行预发布打包并配置发布包，根据配置修改申请单中的开发节点设备的待更新的配置项和测试节点设备的待更新的配置项对配置管理中心中预设的配置信息进行更新，优选地，这个过程可以称作预合并，预设的配置信息是主干配置信息的一个备份配置信息。因为应用在新版本的开发过程中，对配置信息的变更需要一份变更后的配置信息清单，然而在开发和测试等环节中，这些配置信息都不是稳定和最终的版本的配置信息，因此需要将历史的主干配置信息同目前修改的信息做预合并，从而生成临时的配置信息分支。

下面对预合并做具体的描述，值得注意的是，这只是为了更好的说明本申请，并不构成对本申请不当的限定。优选地，配置项修改申请单中对配置信息中配置项更新的标识为：新增标志为A、修改标志为M、删除标志为D，主干配置信息配置项标志为T。可以通过如下步骤实现预合并：

S1-1：获取本次预合并的目标配置项修改申请单，如图9所示，也就是图9中的配置项修改申请单，其中记录有配置项标识(KEY SEGMENT)，以及开发环境、测试环境以及线上环境对应的配置项值(VALUE AEGMENT)，也就是有测试节点设备和开发节点设备待更新配置项的配置项修改申请单。

S1-2：获取本次预合并的目标主干配置信息，也就是图9所示的主干配置信息，其中记录有配置项标识(KEY TRUNK)，以及开发环境、测试环境以及线上环境对应的配置项值(VALUE TRUNK)，如图9所示，主干信息中的开发环境的配置项值就是开发时共享应用配置信息清单，测试环境的配置项值就是测试自动化环境配置信息清单，线上环境配置项值就是线上环境配置信息清单，优选地，可以基于REST风格的配置资源标识方式，例如，应用在新需求开发、测试时，产生配置信息修改，需要获取配置项修改申请单中配置信息同原有配置信息合并后的配置信息时，开发环境对应：http://www.XXX.com/config/dev/appname/formid；测试环境对应：http://www.XXX.com/config/test/appname/formid；线上环境对应：http://www.XXX.com/config/online/appname/formid。以此主干配置信息在内存中建立临时配置信息清单。

S1-3：遍历目标配置项修改申请单对临时配置信息清单进行更新，如图10所示，如果配置项标识对应的标志为A，则将配置信息加入临时配置信息清单中，如果标志为D，则查找临时配置信息清单若发现则将其移除，如果标志为M，则查找并替换临时配置信息清单。

S1-4：输出临时配置清单为动态分支，动态分支是预合并的结果，是主干配置信息同配置项修改申请单临时合并的结果，是动态生成的并且还没有持久化。

S822：发布节点设备根据更新后的配置信息中测试环境的配置信息对应用进行离线自动测试；优选地，也可以是审核节点设备通过配置中心获取实时可用的配置信息，自动搭建环境定时跑自动化测试。

S824：当离线自动测试结果为正常时，发布节点设备对应用进行正式发布，根据更新后的配置信息将应用正式部署到生产环境中。

S826：发布节点设备将开发节点设备和测试节点设备待更新的配置项中通过审核和测试的配置信息合并到主干配置信息中。

在本申请各个实施方式中，如图11所示，一个企业级的应用的功能组件根据环境的不同、版本的不同有多份应用配置信息管理，以及流程控制和系统管理。

其中，流程控制包括：审批流程控制，用于控制配置项修改的审批流程；审批人设置，用于设置流程环节审批人。

系统管理包括：权限控制和用户管理。

配置信息管理包括但不限于以下至少之一：

1)应用管理，用于维护拉入系统管理的企业应用信息，包括：应用名称、应用标识、以及应用的描述信息等；

2)配置项管理，用于维护对应用的管理所对应的配置项信息，包括：配置项名称、配置项标识，配置项描述信息、开发环境下的配置项的具体值、测试环境下的配置项的具体值以及线上环境下的配置项的具体值等，其中，每个配置项信息对应一个配置项标识，无论在哪种环境下配置项标识都是系统，从而有利于统一维护和管理，每个配置项标识对应多个配置项的具体值。

3)配置信息版本控制，维护配置信息的版本信息、新增、修改、删除日志，并提供配置项信息的版本合并、回滚功能。

4)开放接口，提供统一对外服务的配置信息获取接口，以及同外部系统对接的接口，例如流程信息、配置版本信息等。

通过以上的描述可知，本申请具有以下优势：

1)通过共性配置项的维护，解决了相关技术中对配置信息的修改的不能及时被开发的其他环节所获知，当数据库链接的维护，cache等中间件地址的维护等共性的信息发生变更时，需要各个环节进行单独的维护的问题，本申请中开发环境、测试环境、线上环境只需维护一次便可以达到全局共享，提升了工作效率，减少了环境搭建工作量。

2)开发环境、测试环境以及线上环境通过统一的配置项标识对配置项进行维护，从而减少了不同环境间配置信息项的传递带来的偏差。

3)流程化管理配置信息，从配置信息在开发阶段中产生，到测试过程中验证正确性，最后到发布过程中上线发布，都是基于配置修改申请单的形式在开发、测试、发布等各个环节中流动，并结合相关人员的审批环节，保证配置清单的正确性。减少了手工传递的差错，避免了因无统一的管理人员而造成的配置信息泛滥的局面。

4)通过配置管理中心对配置信息的共享，可以为其他内部系统提供相关的配置信息，比如，为自动化测试系统提供环境搭建所需的配置信息，为持续集成自动构件系统提供配置信息等。

显然，本领域的技术人员应该明白，上述的本申请的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请不限制于任何特定的硬件和软件结合。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (12)

1.一种配置信息的更新方法，其特征在于，包括：

配置管理中心接收应用发布过程中的开发节点设备提交的配置修改申请单，其中，所述配置修改申请单中记录有待更新的第一配置项；

所述配置管理中心接收所述应用发布过程中的测试节点设备提交的配置修改申请单，其中，所述测试节点设备提交的配置修改申请单是所述测试节点设备将待更新的第二配置项记录在从所述配置管理中心中获取的由所述开发节点设备提交的所述配置修改申请单中得到的配置修改申请单，所述第二配置项为所述测试节点设备在进行当前测试时采用的配置项；

所述配置管理中心响应于所述应用发布过程中的发布节点设备的请求根据所述配置修改申请单中的所述第一配置项和所述第二配置项对所述配置管理中心中预设的配置信息进行更新，其中，更新后的配置信息用于线上发布所述应用。

2.根据权利要求1所述的方法，其特征在于，在所述配置管理中心响应于所述应用发布过程中的发布节点设备的请求根据所述配置修改申请单中的所述第一配置项和所述第二配置项对所述配置管理中心中预设的配置信息进行更新之后，还包括：

所述发布节点设备将所述更新后的配置信息提交给审核节点设备；

所述发布节点设备在接收到所述审核节点设备返回的用于指示更新的响应消息之后，根据所述更新后的配置信息对所述应用进行离线自动测试。

3.根据权利要求2所述的方法，其特征在于，在根据所述更新后的配置信息对所述应用进行离线自动测试之后，还包括：

若所述离线自动测试结果正常，则根据所述更新后的配置信息对所述应用进行线上发布。

4.根据权利要求1所述的方法，其特征在于，通过如下步骤进行所述当前测试：

根据所述第二配置项搭建测试环境；

在搭建的所述测试环境下，响应于输入的测试命令对所述应用进行测试。

5.根据权利要求1至4中任一项所述的方法，其特征在于，经所述第一配置项和所述第二配置项更新后的配置信息与所述应用的分支程序对应。

6.根据权利要求5所述的方法，其特征在于，在根据所述更新后的配置信息对所述应用进行线上发布之后，还包括：

将所述更新后的配置信息合并到与所述应用的主干程序对应的主干配置信息中。

7.一种配置信息的更新系统，其特征在于，包括：

开发节点设备，用于在应用发布过程中向配置管理中心提交配置修改申请单，其中，所述配置修改申请单中记录有待更新的第一配置项；

测试节点设备，用于在所述应用发布过程中从所述配置管理中心中获取所述配置修改申请单，将当前测试采用的配置项作为待更新的第二配置项记录在所述配置修改申请单，并将记录有所述第一配置项和所述第二配置项的所述配置修改申请单提交给所述配置管理中心；

发布节点设备，用于在所述应用发布过程中根据所述配置修改申请单中的所述第一配置项和所述第二配置项对所述配置管理中心中预设的配置信息进行更新，其中，更新后的配置信息用于线上发布所述应用。

8.根据权利要求7所述的系统，其特征在于，所述发布节点设备包括：

提交单元，用于在对所述配置管理中心中预设的配置信息进行更新之后，将更新后的配置信息提交给审核节点设备；

第一测试单元，用于在接收到所述审核节点设备返回的用于指示更新的响应消息之后，根据所述更新后的配置信息对所述应用进行离线自动测试。

9.根据权利要求8所述的系统，其特征在于，还包括：所述审核节点设备；

所述审核节点设备包括：

接收单元，用于接收所述发布节点设备提交的更新后的配置信息；

响应单元，用于响应所述更新后的配置信息向所述发布节点设备发送指示更新的响应消息。

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

发布节点设备，还用于在所述测试单元根据所述更新后的配置信息对所述应用进行离线自动测试之后，当所述离线自动测试结果正常，根据所述更新后的配置信息对所述应用进行线上发布。

11.根据权利要求7所述的系统，其特征在于，所述测试节点设备包括：

搭建单元，用于根据所述第二配置项搭建测试环境；

第二测试单元，用于在搭建的所述测试环境下，响应于输入的测试命令对所述应用进行测试。

12.根据权利要求10所述的系统，其特征在于，所述发布节点设备包括：

合并单元，用于在根据所述更新后的配置信息对所述应用进行线上发布之后，将所述更新后的配置信息合并到与所述应用的主干程序对应的主干配置信息中，其中，经所述第一配置项和所述第二配置项更新后的配置信息与所述应用的分支程序对应。