CN111831325A - 应用中配置文件的更新方法、装置、系统和介质 - Google Patents

Abstract

本公开提供了一种应用中配置文件的更新方法，该方法包括：遍历配置文件，得到配置文件包括的目标配置项；获取目标配置项的结构化属性信息，该结构化属性信息指示目标配置项所针对的目标应用和目标服务；根据目标应用和目标服务，确定目标配置项的取值；以及根据目标配置项的取值，更新配置文件，其中，目标应用包括与应用具有关联关系的应用。本公开还提供了一种应用中配置文件的更新装置、一种计算机系统和一种计算机可读存储介质。

Description

应用中配置文件的更新方法、装置、系统和介质

技术领域

本公开涉及运维技术领域，更具体地，涉及一种应用中配置文件的更新方法、装置、系统和介质。

背景技术

随着信息技术在各行各业的深入应用，基于先进信息技术的软件系统，对行业发展产生了巨大的影响，有效提升了行业效能。

在实现本公开构思的过程中，发明人发现相关技术中至少存在以下问题：大型金融行业由于业务种类多、体系架构复杂，其软件系统一般由多达几百个应用系统有机组合而成。某个应用系统在上线前，必须在测试环境进行功能测试、性能测试、业务验证等，经过充分测试验证后，才能投产到生产环境。通常每发布一个应用版本，都需要重新搭建一个测试环境。测试环境的搭建过程包括服务器申请、基础环境安装配置、数据迁移、应用配置修改、服务启动和冒烟测试等环节。其中，由于应用与其上下游的外围系统有错综复杂的连接关系，这无疑会导致应用配置修改的手工操作步骤繁多，且容易出现配置失误。相关技术中，该应用地配置修改由工作人员根据工作经验在全手工状态下配置，但配置修改环节中需要进行上下游应用的配置沟通、手工配置操作及来回纠错，配置效率低，失误率高。

发明内容

有鉴于此，本公开提供了一种能够自动对配置项的取值进行配置，从而自动更新配置文件的应用中配置文件的更新方法和装置。

本公开一方面提供了一种应用中配置文件的更新方法，包括：遍历配置文件，得到配置文件包括的目标配置项；获取目标配置项的结构化属性信息，该结构化属性信息指示目标配置项所针对的目标应用和目标服务；根据目标应用和目标服务，确定目标配置项的取值；以及根据目标配置项的取值，更新配置文件，其中，目标应用包括与应用具有关联关系的应用。

根据本公开的实施例，上述应用包括多个配置文件；上述应用中配置文件的更新方法还包括：在遍历完当前配置文件的情况下，继续遍历当前配置文件的下一配置文件，直至多个配置文件均被遍历；配置文件包括多个目标配置项，所述应用中配置文件的更新方法还包括：在根据目标配置项的取值更新配置文件后，继续遍历配置文件得到当前目标配置项的下一目标配置项，直至配置文件被遍历完。

根据本公开的实施例，上述应用中配置文件的更新方法还包括：获取应用的版本信息。上述确定目标配置项的取值包括：根据应用的版本信息，从预先存储的应用的环境信息中确定目标应用的版本信息；从预先存储的关系表中确定与目标应用的版本信息和目标服务均具有关联关系的服务器标识，以作为目标配置项的取值。

根据本公开的实施例，确定目标配置项的取值还包括：在预先存储的关系表中没有与目标应用的版本信息和目标服务均具有关联关系的服务器标识的情况下，确定目标配置项的取值为预设的默认值。

根据本公开的实施例，上述应用的环境信息包括应用的版本信息与关联应用的版本信息的关联关系，其中，关联应用包括应用的上游应用和应用的下游应用，且关联应用包括目标应用；关联应用的版本信息为关联应用最新的版本信息。

根据本公开的实施例，上述预先存储的关系表中包括应用的属性信息与应用对应的服务的属性信息之间的关联关系，其中，应用的属性信息包括应用名称和应用的版本信息，应用对应的服务的属性信息包括：服务名称、服务对应的服务器标识和服务部署园区。

根据本公开的实施例，得到配置文件包括的目标配置项包括：确定配置文件中具有预定标识的配置项，得到目标配置项；结构化属性信息包括用Jason格式描述的配置项的属性信息。

本公开的另一方面提供了一种应用中配置文件的更新装置，该装置包括：文件遍历模块，用于遍历配置文件，得到配置文件包括的目标配置项；属性信息获取模块，用于获取目标配置项的结构化属性信息，结构化属性信息指示目标配置项所针对的目标应用和目标服务；取值确定模块，用于根据目标应用和目标服务，确定目标配置项的取值；以及文件更新模块，用于根据目标配置项的取值，更新配置文件。

本公开的另一方面提供了一种计算机系统，包括：一个或多个处理器；以及存储装置，用于存储一个或多个程序，其中，当一个或多个程序被一个或多个处理器执行时，使得一个或多个处理器执行上述的应用中配置文件的更新方法。

本公开的另一方面提供了一种计算机可读存储介质，存储有计算机可执行指令，所述指令在被处理器执行时用于执行如上所述的应用中配置文件的更新方法。

本公开的另一方面提供了一种计算机程序，所述计算机程序包括计算机可执行指令，所述指令在被执行时用于实现如上所述的应用中配置文件的更新方法。

根据本公开的实施例，至少可以部分地避免相关技术中因需要手工逐一地修改配置项所导致的配置文件更新效率低、配置项容易被遗漏的技术问题。该实施例的应用中配置文件的更新方法能够根据预维护地指示目标应用和目标服务的结构化属性信息来确定配置项的取值，并自动根据配置项的取值来更新配置文件，可以至少部分地提高配置文件更新效率，及配置文件中配置项的修改准确性。

附图说明

通过以下参照附图对本公开实施例的描述，本公开的上述内容以及其他目的、特征和优点将更为清楚，在附图中：

图1示意性示出了根据本公开实施例的应用中配置文件的更新方法、装置、系统和介质的应用场景；

图2示意性示出了根据本公开实施例的应用中配置文件的更新方法的流程图；

图3示意性示出了根据本公开另一实施例的应用中配置文件的更新方法的流程图；

图4示意性示出了根据本公开又一实施例的应用中配置文件的更新方法的流程图；

图5示意性示出了根据本公开实施例的用于执行应用中配置文件的更新方法的更新系统的结构框图；

图6示意性示出了根据本公开实施例的配置文件管理装置维护全量配置文件的流程图；

图7示意性示出了根据本公开实施例的配置项管理装置确定配置项的取值的流程图；

图8示意性示出了根据本公开实施例的更新系统执行更新方法的流程图；

图9示意性示出了根据本公开实施例的应用中配置文件的更新装置的结构框图；以及

图10示意性示出了本公开实施例的适于执行应用中配置文件的更新方法的计算机系统的结构框图。

具体实施方式

以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。

在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。

在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。

在使用类似于“A、B和C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B和C中至少一个的系统”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的系统等)。

本公开的实施例提供了一种应用中配置文件的更新方法，包括：遍历配置文件，得到配置文件包括的目标配置项；获取目标配置项的结构化属性信息，该结构化属性信息指示目标配置项所针对的目标应用和目标服务；根据目标应用和目标服务，确定目标配置项的取值；以及根据目标配置项的取值，更新配置文件，其中，目标应用包括与应用具有关联关系的应用。

图1示意性示出了根据本公开实施例的应用中配置文件的更新方法、装置、系统和介质的应用场景。需要注意的是，图1所示仅为可以应用本公开实施例的应用场景的示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他设备、系统、环境或场景。

如图1所示，该实施例的应用场景100例如可以包括终端设备110、网络120和多个应用服务器131、132、133。

终端设备110可以是包括显示屏器且安装有各种客户端应用的各种电子设备，包括但不限于智能手机、平板电脑、便携式计算机和台式计算机等。该终端设备110例如可以安装有测试环境搭建应用、应用发布平台、即时通信类应用等。

示例性地，该终端设备110安装的测试环境搭建应用例如可以提供有人机交互界面。用户通过该人机交互界面可以选择待测试的应用，并提交测试环境配置请求。在一实施例中，用户还可以通过该人机交互界面选择应用的测试类型，测试类型例如可以包括性能测试、功能测试、回装测试等。

响应于用户提交的测试环境配置请求，终端设备110例如可以根据用户选择的待测试应用及测试类型，通过网络，在应用包括的服务运行所需的应用服务器131、132、133中配置测试环境。

根据本公开的实施例，为了便于实现测试环境的自动配置，该应用场景中例如还可以包括维护有全量版本的应用、全量的应用间关联关系、全量的配置项的服务器。该服务器维护的全量的信息例如可以由不同职位的工作人员设置后上传至该服务器，并分类存储于服务器的不同存储片区。

根据本公开的实施例，为了便于提高测试环境搭建效率，该实施例的终端设备110例如还可以为表征应用的上下游应用对应的服务器的目标配置项维护结构化属性信息，以根据该结构化属性信息从全量的应用间关联关系中获取到目标配置项的取值，并依据该取值对应用的配置文件及测试环境进行更新，得到能够用于对应用进行测试的测试环境。

根据本公开的实施例，为了便于提高用户体验，终端设备110还可以在配置测试环境的过程中，向用户提供查看配置进度、配置日志、查看配置结果和/或使用户中断配置重新提交配置请求的功能入口。

根据本公开的实施例，该应用场景中例如还可以包括与终端设备110通信连接，且能够响应于终端设备110发送的配置请求进行测试环境配置的服务器。

可以理解的是，本公开实施例的应用中配置文件的更新方法可以由终端设备110执行，或由与该终端设备110通信连接的服务器执行。相应的，本公开实施例的应用中配置文件的更新装置可以设置于终端设备110中，或设置于与终端设备110通信连接的服务器中。

以下将结合图2～图4对本公开实施例的应用中配置文件的更新方法进行详细描述。

如图2所示，该实施例的应用中配置文件的更新方法可以包括操作S210～操作S240。

在操作S210，遍历配置文件，得到配置文件包括的目标配置项。

根据本公开的实施例，考虑到在应用的配置文件中通常包括有端口、线程并发数、上游应用的节点服务器地址、下游应用的节点服务器地址、密码等作为变量的配置项。该些配置项中包括通常变动多、配置繁琐的配置项，例如上游应用的节点服务器地址、下游应用的节点服务器地址。为了避免人工更改该些变动多的配置项导致的测试环境搭建效率低下的问题，本实施例可以将变动多、配置繁琐的配置项作为目标配置项，并由研发人员在配置文件中的目标配置项处添加预定标识。相应地，该操作S210即为从配置文件中获取具有预定标识的配置项作为目标配置项。

示例性地，向目标配置项添加的预定标识例如可以为$#{}。示例性地，对于某添加预定标识的目标配置项，在配置文件中可以表示为：

<property name＝“ip”>

<value>$#{ENV_SYS01_SYS02_SERVICE_URL}＜/value>

</property>

其中，花括号中的内容为目标配置项的名称。

在操作S220，获取目标配置项的结构化属性信息，该结构化属性信息指示目标配置项所针对的目标应用和目标服务。

根据本公开的实施例，为了便于获取各配置项的取值，该实施例中，在企业内的软件系统中例如还可以维护有全量的配置项。针对每个配置项，维护有属性信息。每个配置项的属性信息例如可以包括：配置项名称、配置项描述、配置项的结构化属性信息。其中，确定配置文件中包括的目标配置项时，例如可以根据配置项名称来得到目标配置项。配置项描述例如可以为简单且通俗易懂的配置项字面描述。在一实施例中，某个配置项的配置项描述可以为：配置应用在上海园区的服务A的服务器IP地址。

示例性地，配置项结构化描述例如可以为采用JSON(JavaScript ObjectNotation)格式的方式描述该配置项需要配置的值。在一实施例中，该配置项的结构化属性信息例如可以包括：应用名称、服务名称、服务描述、部署园区等值。其中，应用名称例如可以为该配置项所属的应用的名称。服务名称为设置有该配置项的服务的名称。服务描述为设置有该配置项的服务的简介描述信息。部署园区可以为部属有设置该配置项的服务的园区名称。在一实施例中，某配置项的结构化属性信息例如可以如下所示：

“appName”：F-AAM；(该项为应用名称)

“nodeName”：110000000020577；(该项为服务名称)

“node_param_name”：个人核对节点.非标准应用服务节点.电子银行统一通行证；(该项为服务的简介)

“zone”：外高桥园区。(部属有服务的园区名称)

可以理解的是，上述结构化属性信息包括的内容仅作为示例以利于理解本公开，本公开可以根据不同的配置项定义不同的JSON字段。但每个配置项的结构化属性信息应该指示该配置项所针对的目标应用和目标服务。即结构化属性信息至少应包括上述的“appName”字段和“nodeName”字段。其中，目标应用为与配置文件所属的应用具有关联关系(例如上游关系或下游关系)的应用。

在操作S230，根据目标应用和所述目标服务，确定目标配置项的取值。

根据本公开的实施例，企业内的软件系统中例如可以预先维护有应用包括的服务及服务对应的服务器ID的映射关系表。该操作S230可以是根据结构化属性信息指示的目标应用和目标服务，确定映射关系表中目标应用包括的目标服务所对应的服务器ID，并将该服务器ID作为目标配置项的取值。

根据本公开的实施例，考虑到不同版本的上下游应用所包括的服务、以及服务对应的服务器可能有所不同。因此，该实施例在确定各配置项的取值时，例如可以先确定与应用相关联的上下游应用的版本信息。然后再根据版本信息确定服务所对应的服务器的标识。最后将服务器的标识作为各配置项的取值。此种情况下，操作S230例如可以通过后续图4描述的流程来实现，在此不再赘述。

在操作S240，根据目标配置项的取值，更新所述配置文件。

根据本公开的实施例，在确定了各配置项的取值后，在该操作S240例如可以为将各配置项的取值赋值为配置文件中对应的配置项，得到更新后的配置文件。

综上可知，本公开实施例能够根据预维护地指示目标应用和目标服务的结构化属性信息来确定配置项的取值，并自动根据配置项的取值来更新配置文件，可以至少部分地提高配置文件更新效率，及配置文件中配置项的修改准确性。

根据本公开的实施例，考虑到应用包括的配置文件可能有多个，此种情况下，在通过操作S210～操作S240更新完多个配置文件中的某个配置文件后，该应用中配置文件的更新方法可以针对该某个配置文件的下一配置文件执行操作S210～操作S240，以对该下一配置文件进行更新。即应用中配置文件的更新方法还包括在遍历完当前配置文件的情况下，继续遍历当前配置文件的下一配置文件，直至多个配置文件均被遍历。

根据本公开的实施例，考虑到应用可能与其他应用具有较为复杂的关联关系，则配置文件中包括的目标配置项可能为多个。此种情况下，在通过操作S210～操作S230得到配置文件中的某个配置项的取值并更新配置文件后，该应用中配置文件的更新方法可以针对该某个配置项的下一配置项执行操作S210～操作S240，以得到下一配置项的取值并再次更新配置文件。即应用中配置文件的更新方法还包括在确定当前目标配置项的取值之后，继续遍历配置文件得到当前目标配置项的下一目标配置项及其取值，直至配置文件被遍历完后更新配置文件。

在一实施例中，应用中配置文件的更新方法例如可以通过图3描述的流程来实现。

图3示意性示出了根据本公开另一实施例的应用中配置文件的更新方法的流程图。

如图3所示，该实施例的应用中配置文件的更新方法除了操作S210～操作S240外，还可以包括操作S350～操作S360。操作S350和操作S360均在操作S240之后执行。

在操作S350，判断当前配置文件中的所有目标配置项是否被遍历完。该操作S350可以是根据当前遍历位置开始，确定当前配置文件中是否还有预定标识，若还有预定标识，则说明当前配置文件中的所有目标配置项未被遍历完，返回继续执行操作S210，以从当前遍历位置开始，继续对配置文件进行遍历。若已没有预定标识，则说明当前配置文件中的所有目标配置项均被遍历完，执行操作S360。

在操作S360，判断应用包括的所有配置文件是否均被遍历完，若是，则结束应用中配置文件的更新操作。若还有配置文件未被遍历，则针对未被遍历的配置文件，返回执行操作S210。其中，例如可以根据配置文件的最新维护日期确定是否还存在未被遍历且未被更新的配置文件。或者，为了便于确定，可以在更新配置文件时，将目标配置项的预定标识删除。该操作S360可以根据配置文件中是否包括预定标识来确定是否还存在未被遍历且未被更新的配置文件。

图4示意性示出了根据本公开又一实施例的应用中配置文件的更新方法的流程图。

如图4所示，该实施例的应用中配置文件的更新方法除了操作S210～操作S240外，还可以包括操作S450，相应地，操作S230可以通过操作S431～操作S434来实现。其中，操作S450可以在操作S210～操作S220执行的任意时机来执行。

在操作S450，获取应用的版本信息。

根据本公开的实施例，应用的版本信息例如可以由终端设备110响应于用户的输入操作得到的测试环境的配置信息中得到。根据本公开的实施例，配置信息除了应用的版本信息外，例如还可以包括应用名称、测试环境配置方式等信息。

在操作S431，根据应用的版本信息，从预先存储的应用的环境信息中确定目标应用的版本信息。

根据本公开的实施例，企业内的软件系统例如可以维护有各应用的版本投产时间点，该投产时间点是判断应用间环境连接关系的根本。再者，软件系统可以根据应用的投产时间点维护有各应用的环境信息。

示例性地，环境信息例如可以通过以下方式维护得到：对于应用SYS01，与其具有上下游连接关系的应用包括SYS02和SYS03。假定软件系统已维护的应用SYS01是2020年2月5日投产的版本，已维护的应用SYS02是2020年2月10日投产的版本，已维护的应用SYS03是2020年2月15日投产的版本。在研发人员正在进行X需求的应用开发时，应用SYS01和应用SYS02应用均有修改，且X需求的应用将于2020年3月15日投产。则软件系统中将会有应用SYS01和应用SYS02在2020年3月15日投产的版本，且应用SYS01和SYS02会在各自2020年3月15日的版本对应的测试环境中进行测试。在一实施例中，若在X需求的应用开发投产之前，应用SYS03连接了一个Y需求的应用开发，且Y需求的应用需要在2020年3月12日投产，则软件系统中会有应用SYS03在2020年3月12日投产的版本。因此，应用SYS01在2020年3月15日投产的版本的环境信息如下：与应用SYS02在2020年3月15日投产的版本建立有连接，与应用SYS03在2020年3月12日投产的版本建立有连接。在一实施例中，若应用SYS03连接的Y需求的应用是在2020年3月16日投产的，即晚于X需求的应用的投产日期，则应用SYS01在2020年3月15日投产的版本的环境信息如下：与应用SYS02在2020年3月15日投产的版本建立有连接，与应用SYS03在2020年2月15日投产的版本建立有连接。

通过该软件系统维护的信息，操作S431可以根据应用版本信息，从应用等环境信息中定位得到与具有该应用版本信息的应用具有连接的其他应用的版本信息。然后从其他应用的版本信息中查找得到目标应用的版本信息。

根据本公开的实施例，应用的环境信息包括应用的版本信息与关联应用的版本信息的关联关系，其中，关联应用包括应用的上游应用和应用的下游应用，且关联应用包括目标应用；关联应用的版本信息为关联应用最新的版本信息。

在操作S432，判断预先存储的关系表中是否包括具有关联关系的服务器标识。

根据本公开的实施例，企业内的软件系统例如可以预先存储有全量的应用基础信息。该基础信息包括应用名称、应用的版本信息、应用包括的服务的中文名称、应用包括的各服务对应的服务器IP、应用包括的服务所部署的园区名称等。由于不同版本的应用的基础信息不同，因此同一版本的基础信息中各信息的存储方式可以为关系表形式，以与版本信息一一对应的建立有关联关系。

相应地，所述预先存储的关系表中包括应用的属性信息与应用包括的服务的属性信息之间的关联关系。其中，应用的属性信息包括应用名称和应用的版本信息，应用包括的服务的属性信息包括：服务名称、服务对应的服务器标识和服务部署园区。

示例性地，操作S432可以是先根据目标应用的版本信息查找得到目标应用的基础信息。然后确定基础信息是否能够查找得到目标服务对应的服务器标识。在能够查找得到目标服务对应的服务器标识的情况下，确定预先存储的关系表中包括具有关联关系的服务器标识。在未能查找得到目标服务对应的服务器标识的情况下，确定预先存储的关系表中不包括具有关联关系的服务器标识。其中，具有关联关系是指与目标应用的版本信息和目标服务均具有关联关系。

若预先存储的应用的环境信息中包括具有关联关系的目标应用的版本信息，则执行操作S433，将具有关联关系的服务器标识作为目标配置项的取值。

若预先存储的应用的环境信息中包括具有关联关系的目标应用的版本信息，则执行操作S434，确定目标配置项的取值为预设的默认值。该默认值例如可以为用户通过终端设备110输入的值。

以下将结合图5～图8对本公开实施例中能够执行应用中配置文件的更新方法的更新系统进行描述。

图5示意性示出了根据本公开实施例的用于执行应用中配置文件的更新方法的更新系统的结构框图。

如图5所示，该实施例的更新系统500包括配置文件管理装置510、配置项管理装置520、环境管理装置530、版本管理装置540和配置项修改装置550。

配置文件管理装置510由配置文件维护单元和配置文件变量标识单元组成。配置文件维护单元用于维护每个应用的每个版本包括的全量的配置文件。配置文件变量标识单元用于标识每个配置文件里需要修改的目标配置项。示例性地，该配置文件管理装置具体例如可以通过后续图6描述的流程来维护全量的配置文件，在此不再赘述。

配置项管理装置520由配置项维护管理单元、配置项属性定义单元、配置项取值获取单元组成。配置项维护管理单元用于维护每个应用系统每个版本的全量变量。配置项属性定义单元用于定义每个配置项包含的属性。每个配置项例如可以用配置项名、配置项描述、配置项默认值、配置项结构化属性信息4种属性来定义。配置项取值获取单元，用于根据配置项结构化属性信息获取配置项的取值。示例性地，配置项管理装置520例如可以通过图7描述的流程来确定配置项的取值，在此不再赘述。

环境管理装置530由应用管理单元和测试环境定义单元组成。应用管理单元维护了全量的应用基础信息。主要包含应用名称、应用包括的服务对应的服务器标识(服务器IP)、应用包括的服务的名称、服务部署园区等。测试环境定义单元用于对测试环境进行定义。

示例性地，该环境管理装置530可以先从企业内的应用管理平台中同步数据，例如可以通过HTTP接口定时对数据进行同步。同步周期可以根据实际需求进行设定。数据的同步也可以通过手工触发。通过数据同步，可以获取到全量的应用基础信息。随后对应用的测试环境进行定义，每个测试环境例如可以包括应用名、应用版本信息、环境类型、应用包括的服务的部署园区等。其中投应用版本信息定义了此测试环境对应的是应用的哪个版本，是配置项的取值自动获取的一个关键要素。环境类型指的是同版本但是不同类型的测试环境，比如功能环境、性能环境、回装环境等。无特殊情况下，应用间的环境连接，都是同类型的环境。最后，在测试环境搭建完成后登记应用的每个服务对应的服务器IP。

版本管理装置540定义了每个应用的所有的版本信息(包括投产时间点)。

配置项修改装置550由配置文件遍历单元和配置项替换单元组成。配置文件遍历单元用于遍历应用的配置目录下的所有配置文件。配置项替换单元用于对具有预定标识的配置项进行全量替换。该配置项修改装置550具体例如可以用于联合配置项管理装置520，完成图3描述的流程。

图6示意性示出了根据本公开实施例的配置文件管理装置维护全量配置文件的流程图。

如图6所示，配置文件管理装置维护全量配置文件的流程例如可以包括操作S601～操作S605。

在操作S601，继承该应用的最新一个版本的全量的配置文件。

在操作S602，判断该版本的应用是否有增加或删除配置文件。该操作S602可以是确定与搭建系统通信连接的开发系统是否接收到响应于用户操作生成的配置文件新增指令或配置文件删除指令。若是，则执行操作S603，否则跳转至操作S604。

在操作S603，响应于配置文件新增指令或配置文件删除指令对配置文件进行新增或删除。即根据实际情况新增或删除该版本的应用的配置文件。

在操作S604，生成此版本的应用的最新全量配置文件。按版本目录结构进行管理，如：

“-SYS1 V1.1.1.2.zip/APP/appConfigs/sys1.war/WEB-INF/config/con-tributions/common

|app-modules.xml

|xxx.xml”。

在操作S605，用预定标识(例如“$#{}”)标识配置文件里需要修改的配置项，作为目标配置项。配置文件里的取值会随环境不同而变动的配置项用$#{}进行标识，大部分情况配置项为对环境敏感、变动最多、配置最繁琐的是上下游应用系统的节点服务器地址。其他变化不大的值，比如端口，或者是需要根据测试运行过程中实际情况进行调整的，比如线程并发数目，或者需要由安全管理员进行手工配置的密码等，这些主要采用变量默认值或者由运维管理员进行调整。

图7示意性示出了根据本公开实施例的配置项管理装置确定配置项的取值的流程图。

如图7所示，配置项管理装置确定配置项的取值的流程例如可以包括操作S701～操作S709。

在操作S701，继承上一版本的全量配置项。

在操作S702，判断该版本的应用是否有需要新增或删除的配置项。该操作S702可以是确定与搭建系统通信连接的开发系统是否接收到响应于用户操作生成的配置项新增指令或配置项删除指令。若是，则执行操作S703，否则跳转至操作S704。

在操作S703，响应于配置项新增指令或配置项删除指令对配置项进行新增或删除。

在操作S704，生成该版本的应用的全量配置项。

在操作S705，定义配置项属性信息。该操作S705可以是响应于用户操作，分别定义得到配置项的配置项名称、配置项默认值、配置项描述和配置项结构化属性信息。其中，配置项名称是从配置文件中抽取出来的需要修改的配置项的名称。配置项默认值为在通过前述操作S431～操作S433未得到配置项的取值时，为配置项分配的默认值。配置项描述和配置项结构化属性信息如前文所述，在此不再赘述。

在操作S706，根据配置项的结构化属性信息，确定配置项对应的服务和应用。

在操作S707，从版本管理单元维护的应用的版本信息中，获取配置项对应的应用的版本信息，并根据应用的版本信息和对应的服务从环境管理装置中确定服务对应的服务器IP，以该服务器IP作为配置项的取值。

在操作S708，判断是否从环境管理单元中获取到配置项的取值。在获取到的情况下，执行操作S709。在未获取到的情况下，执行操作S710。

在操作S709，使用获取到的服务器IP作为配置项的取值。

在操作S710，采用默认值或人工设定的值作为配置项的取值。

图8示意性示出了根据本公开实施例的更新系统执行更新方法的流程图。

如图8所示，该实施例的更新系统执行更新方法例如可以包括S801～S810。

在操作S801，在版本管理装置维护所有版本的应用的投产时间(版本信息)。通过此信息来获取每个应用间的测试环境关系。

在操作S802，环境管理装置维护每个版本的应用的环境信息。为每个应用的服务映射具体的服务器IP地址。

在操作S803，在配置文件管理装置里维护好每个版本的应用的全量配置文件。

在操作S804，在配置文件管理装置里对配置文件里需要修改的配置项进行特殊标识，如采用$#{}标识，花括号里填写自定义的配置项名。

在操作S805，在配置项管理装置里维护该版本的应用中从配置文件标识出来的所有配置项，为每个配置项用4个元素进行定义，配置项名、配置项描述、配置项默认值、配置项结构化属性信息。

在操作S806，在配置变量管理装置里用JSON格式对配置项进行配置项结构化属性信息的定义。

在操作S807，在配置项管理装置根据配置项结构化属性信息及环境管理装置里的环境信息获取到配置项的取值。

在操作S808，在配置项修改装置遍历全量配置文件中具有标识的配置项，从配置项管理装置获取具体的取值进行替换。

在操作S809，判断是否包括需要人工维护的配置项。如无则完成配置项修改。该操作S809即确定是否存在未获取到取值的目标配置项。

在操作S810，对于部分不能由系统指定的变量，则由系统运维人员在配置项管理装置进行人工指定，或者采用前述配置项元素中的默认值。

在一实施例中，该用于执行应用中配置文件的更新方法的更新系统的基本工作流程可以如下所示：

首先，项目管理人员在版本管理装置维护负责应用的所有版本的投产时间点；其次系统运维人员在环境管理系统装置维护每个应用的每个版本的环境信息，为每个应用包括的每个服务映射具体的服务器IP。随后研发人员在配置文件管理装置里维护好每个版本的每个应用的全量的配置文件，对配置文件里需要修改的变量进行标识。然后研发人员在配置项管理装置里维护该版本从配置文件标识出来的配置项，对配置项进行结构化属性信息的定义。之后经由配置变量管理装置根据配置项的结构化属性信息解析配置项是连接哪个应用，根据版本管理装置得出是连接哪个版本的应用，最后从环境管理装置获取具体的服务对应的服务器IP，完成所有的含结构化属性信息的配置项替换。对于密码、调优等需要根据实际情况来配置的配置项参数，则由系统运维人员进行人工维护。最后在配置项修改装置里，系统自动遍历所有的配置文件，从配置项管理装置获取具体取值来替换配置文件里标识的配置项。完成整个应用的版本环境用到的所有配置文件的准确配置。

图9示意性示出了根据本公开实施例的应用中配置文件的更新装置的结构框图。

如图9所示，该实施例的应用中配置文件的更新装置900例如可以包括文件遍历模块910、属性信息获取模块920、取值确定模块930和文件更新模块940。

文件遍历模块910用于遍历配置文件，得到配置文件包括的目标配置项。在一实施例中，文件遍历模块910用于执行图2描述的操作S210，在此不再赘述。

属性信息获取模块920用于获取目标配置项的结构化属性信息，结构化属性信息指示目标配置项所针对的目标应用和目标服务。在一实施例中，属性信息获取模块920用于执行图2描述的操作S220，在此不再赘述。

取值确定模块930用于根据目标应用和所述目标服务，确定目标配置项的取值。在一实施例中，取值确定模块930用于执行图2描述的操作S230，在此不再赘述。

文件更新模块940用于根据目标配置项的取值，更新配置文件。在一实施例中，文件更新模块940用于执行图2描述的操作S230，在此不再赘述。

根据本公开的实施例，应用包括多个配置文件，文件遍历模块910还用于在遍历完当前配置文件的情况下，继续遍历当前配置文件的下一配置文件，直至多个配置文件均被遍历。并且/或者，配置文件包括多个目标配置项，文件遍历模块910还用于在根据目标配置项的取值更新配置文件后，继续遍历配置文件得到当前目标配置项的下一目标配置项的取值，直至配置文件被遍历完。

根据本公开的实施例，上述应用中配置文件的更新装置900还可以包括版本信息获取模块，用于获取应用的版本信息。取值确定模块930例如可以用于执行前述图4描述的操作S431～操作S434，在此不再赘述。

根据本公开的实施例，文件遍历模块910例如可以用于确定配置文件中具有预定标识的配置项，得到目标配置项。结构化属性信息包括用Jason格式描述的配置项的属性信息。

根据本公开的实施例的模块、子模块、单元、子单元中的任意多个、或其中任意多个的至少部分功能可以在一个模块中实现。根据本公开实施例的模块、子模块、单元、子单元中的任意一个或多个可以被拆分成多个模块来实现。根据本公开实施例的模块、子模块、单元、子单元中的任意一个或多个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上系统、基板上的系统、封装上的系统、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式的硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，根据本公开实施例的模块、子模块、单元、子单元中的一个或多个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

图10示意性示出了本公开实施例的适于执行应用中配置文件的更新方法的计算机系统的结构框图。

如图10所示，根据本公开实施例的计算机系统1000包括处理器1001，其可以根据存储在只读存储器(ROM)1002中的程序或者从存储部分1008加载到随机访问存储器(RAM)1003中的程序而执行各种适当的动作和处理。处理器1001例如可以包括通用微处理器(例如CPU)、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(ASIC))，等等。处理器1001还可以包括用于缓存用途的板载存储器。处理器1001可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。

在RAM 1003中，存储有计算机系统1000操作所需的各种程序和数据。处理器1001、ROM 1002以及RAM 1003通过总线1004彼此相连。处理器1001通过执行ROM 1002和/或RAM1003中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意，所述程序也可以存储在除ROM 1002和RAM 1003以外的一个或多个存储器中。处理器1001也可以通过执行存储在所述一个或多个存储器中的程序来执行根据本公开实施例的方法流程的各种操作。

根据本公开的实施例，计算机系统1000还可以包括输入/输出(I/O)接口1005，输入/输出(I/O)接口1005也连接至总线1004。计算机系统1000还可以包括连接至I/O接口1005的以下部件中的一项或多项：包括键盘、鼠标等的输入部分1006；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分1007；包括硬盘等的存储部分1008；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分1009。通信部分1009经由诸如因特网的网络执行通信处理。驱动器1010也根据需要连接至I/O接口1005。可拆卸介质1011，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1010上，以便于从其上读出的计算机程序根据需要被安装入存储部分1008。

根据本公开的实施例，根据本公开实施例的方法流程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读存储介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分1009从网络上被下载和安装，和/或从可拆卸介质1011被安装。在该计算机程序被处理器1001执行时，执行本公开实施例的计算机系统中限定的上述功能。根据本公开的实施例，上文描述的系统、设备、装置、模块、单元等可以通过计算机程序模块来实现。

本公开还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的；也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。

根据本公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质，例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。例如，根据本公开的实施例，计算机可读存储介质可以包括上文描述的ROM 1002和/或RAM 1003和/或ROM 1002和RAM 1003以外的一个或多个存储器。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合，即使这样的组合或结合没有明确记载于本公开中。特别地，在不脱离本公开精神和教导的情况下，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合。所有这些组合和/或结合均落入本公开的范围。

以上对本公开的实施例进行了描述。但是，这些实施例仅仅是为了说明的目的，而并非为了限制本公开的范围。尽管在以上分别描述了各实施例，但是这并不意味着各个实施例中的措施不能有利地结合使用。本公开的范围由所附权利要求及其等同物限定。不脱离本公开的范围，本领域技术人员可以做出多种替代和修改，这些替代和修改都应落在本公开的范围之内。

Claims (10)

1.一种应用中配置文件的更新方法，包括：

遍历所述配置文件，得到所述配置文件包括的目标配置项；

获取所述目标配置项的结构化属性信息，所述结构化属性信息指示所述目标配置项所针对的目标应用和目标服务；

根据所述目标应用和所述目标服务，确定所述目标配置项的取值；以及

根据所述目标配置项的取值，更新所述配置文件，

其中，所述目标应用包括与所述应用具有关联关系的应用。

2.根据权利要求1所述的方法，其中：

所述应用包括多个配置文件；所述方法还包括：在遍历完当前配置文件的情况下，继续遍历所述当前配置文件的下一配置文件，直至所述多个配置文件均被遍历；

所述配置文件包括多个目标配置项，所述方法还包括：在根据所述目标配置项的取值更新所述配置文件后，继续遍历所述配置文件得到当前目标配置项的下一目标配置项的取值，直至所述配置文件被遍历完。

3.根据权利要求1或2所述的方法，其中，

所述方法还包括：获取所述应用的版本信息；

确定所述目标配置项的取值包括：

根据所述应用的版本信息，从预先存储的所述应用的环境信息中确定所述目标应用的版本信息；

从预先存储的关系表中确定与所述目标应用的版本信息和所述目标服务均具有关联关系的服务器标识，以作为所述目标配置项的取值。

4.根据权利要求3所述的方法，其中，确定所述目标配置项的取值还包括：

在所述预先存储的关系表中没有与所述目标应用的版本信息和所述目标服务均具有关联关系的服务器标识的情况下，确定所述目标配置项的取值为预设的默认值。

5.根据权利要求3所述的方法，其中：

所述应用的环境信息包括所述应用的版本信息与关联应用的版本信息的关联关系，

其中，所述关联应用包括所述应用的上游应用和所述应用的下游应用，且所述关联应用包括所述目标应用；所述关联应用的版本信息为所述关联应用最新的版本信息。

6.根据权利要求3所述的方法，其中：

所述预先存储的关系表中包括应用的属性信息与所述应用包括的服务的属性信息之间的关联关系，

其中，所述应用的属性信息包括应用名称和应用的版本信息，所述应用包括的服务的属性信息包括：服务名称、服务对应的服务器标识和服务部署园区。

7.根据权利要求1所述的方法，其中：

得到所述配置文件包括的目标配置项包括：确定所述配置文件中具有预定标识的配置项，得到所述目标配置项；

所述结构化属性信息包括用Jason格式描述的配置项的属性信息。

8.一种应用中配置文件的更新装置，包括：

文件遍历模块，用于遍历所述配置文件，得到所述配置文件包括的目标配置项；

属性信息获取模块，用于获取所述目标配置项的结构化属性信息，所述结构化属性信息指示所述目标配置项所针对的目标应用和目标服务；

取值确定模块，用于根据所述目标应用和所述目标服务，确定所述目标配置项的取值；以及

文件更新模块，用于根据所述目标配置项的取值，更新所述配置文件。

9.一种计算机系统，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器执行根据权利要求1～7中任一项所述的方法。

10.一种计算机可读存储介质，其上存储有可执行指令，该指令被处理器执行时使处理器执行根据权利要求1～7中任一项所述的方法。

Images