CN111142903B - 一种基于文件对比的配置文件交互式更新方法及装置 - Google Patents

Abstract

本申请公开了一种基于文件对比的配置文件交互式更新方法、装置及系统，包括：对比当前版本的配置文件和上一版本的配置文件，确定当前版本相对上一版本的更新记录，并将更新记录追加至更新历史文件；根据更新历史文件在操作界面显示待配置项，并根据用户在操作界面的操作确定待配置项的实际值；根据待配置项的实际值，对生产环境中的目标配置文件进行更新操作。可见，本申请通过对比当前版本的配置文件和上一版本的配置文件，抽取当前版本的配置文件中进行个性化配置的条目，归并出需要更新的配置项，进而通过交互式的操作界面提示运维人员进行配置，从而避免了人工整理数据及修改配置项带来的错误，提升了配置文件更新效率和系统运维效率。

Description

一种基于文件对比的配置文件交互式更新方法及装置

技术领域

本申请涉及计算机技术领域，特别涉及一种基于文件对比的配置文件交互式更新方法、装置及系统。

背景技术

对于大型App而言，将配置与代码分离是一种常用的架构策略，这样做的好处很多，既避免了某些资源路径(如数据库、FTP服务器)与代码的强耦合，又在某些场景提供了动态调整服务器状态的可能性。同时结合profile使用，允许在App出厂时默认提供多套配置方案以满足各种环境的需要。比如，开发环境希望能打印debug日志，测试环境希望能默认打开远程调试功能，然而生产环境则默认将上述功能全部关闭。

尽管采用配置文件有如上所说的多种优势，仍旧会在某种场景下造成运维人员的困扰，甚至由于各种不可避免的因素，造成应用上线后的运行错误。例如，出于保密或其他原因，出厂时不会直接将配置文件设置为生产环境可用的状态。在实际应用中，根据不同的情况对配置文件进行灵活配置，一般通过文本编辑手段对位于生产环境中的配置文件进行全量更新或增量更新，该更新工作通过人工实现，出错率较高。尤其是增量更新过程，需要人工整理大量分散的数据，进一步增加了出错概率，导致配置文件更新效率较低。

发明内容

本申请的目的是提供一种基于文件对比的配置文件交互式更新方法、装置及系统，用以解决传统配置文件更新方案中，需要人工整理大量分散的数据，导致出错率较高的问题。其具体方案如下：

第一方面，本申请提供了一种基于文件对比的配置文件交互式更新方法，包括：

对比当前版本的配置文件和上一版本的配置文件，确定当前版本相对上一版本的更新记录，并将所述更新记录追加至更新历史文件；

根据所述更新历史文件在操作界面显示待配置项，并根据用户在所述操作界面的操作确定所述待配置项的实际值；

根据所述待配置项的实际值，对生产环境中的目标配置文件进行更新操作。

优选的，所述将所述更新记录追加至更新历史文件；根据所述更新历史文件在操作界面显示待配置项，包括：

将所述更新记录和当前版本号追加至更新历史文件；

通过查询版本文件确定生产环境中目标配置文件的版本号；

根据所述目标配置文件的版本号和所述更新历史文件，在操作界面显示待配置项和所述待配置项的默认值。

优选的，在所述根据所述待配置项的实际值，对生产环境中的目标配置文件进行更新操作之后，还包括：

将所述版本文件中所述目标配置文件的版本号更新为所述当前版本号。

优选的，所述确定当前版本相对上一版本的更新记录，并将所述更新记录追加至更新历史文件，包括：

确定当前版本相对上一版本的更新记录，并将所述更新记录追加至更新历史文件，所述更新记录包括当前版本号、操作类型、更新记录的key值、更新记录的value值。

优选的，所述根据所述更新历史文件在操作界面显示待配置项，包括：

根据所述更新历史文件在操作界面显示待配置项和可选操作项，所述可选操作项包括以下任意一项或多项：拒绝更新、确认更新、确认默认值、修改默认值。

优选的，所述对比当前版本的配置文件和上一版本的配置文件，确定当前版本相对上一版本的更新记录，并将所述更新记录追加至更新历史文件，包括：

在配置设备侧的编译阶段，利用Maven插件对比当前版本的配置文件和上一版本的配置文件，确定当前版本相对上一版本的更新记录，并将所述更新记录追加至更新历史文件；

在配置设备侧的打包阶段，利用Maven插件对所述更新历史文件和所述上一版本的配置文件进行打包，以发送至生产环境侧。

优选的，所述对比当前版本的配置文件和上一版本的配置文件，确定当前版本相对上一版本的更新记录，并将所述更新记录追加至更新历史文件，包括：

获取当前版本的配置文件；

判断本地是否记录有上一版本的配置文件；

若是，则获取上一版本的配置文件，对比所述当前版本的配置文件和所述上一版本的配置文件，确定当前版本相对上一版本的更新记录，并将所述更新记录追加至更新历史文件；

若否，则将所述当前版本的配置文件作为更新记录存储至更新历史文件。

第二方面，本申请提供了一种基于文件对比的配置文件交互式更新装置，包括：

对比模块：用于对比当前版本的配置文件和上一版本的配置文件，确定当前版本相对上一版本的更新记录，并将所述更新记录追加至更新历史文件；

配置模块：用于根据所述更新历史文件在操作界面显示待配置项，并根据用户在所述操作界面的操作确定所述待配置项的实际值；

更新模块：用于根据所述待配置项的实际值，对生产环境中的目标配置文件进行更新操作。

第三方面，本申请提供了一种基于文件对比的配置文件交互式更新系统，包括：配置设备和生产环境中的服务器；

其中，所述配置设备用于对比当前版本的配置文件和上一版本的配置文件，确定当前版本相对上一版本的更新记录，并将所述更新记录追加至更新历史文件；

所述服务器用于根据所述更新历史文件在操作界面显示待配置项，并根据用户在所述操作界面的操作确定所述待配置项的实际值；根据所述待配置项的实际值，对本地的目标配置文件进行更新操作。

本申请所提供的一种基于文件对比的配置文件交互式更新方法，包括：对比当前版本的配置文件和上一版本的配置文件，确定当前版本相对上一版本的更新记录，并将更新记录追加至更新历史文件；根据更新历史文件在操作界面显示待配置项，并根据用户在操作界面的操作确定所述待配置项的实际值；根据待配置项的实际值，对生产环境中的目标配置文件进行更新操作。可见，该方法通过对比当前版本的配置文件和上一版本的配置文件，抽取当前版本的配置文件中进行个性化配置的条目，归并出需要更新的配置项，进而通过交互式的操作界面提示运维人员进行配置，从而避免了人工整理数据及修改配置项带来的错误，提升了配置文件更新效率和系统运维效率。

此外，本申请还提供了一种基于文件对比的配置文件交互式更新装置及系统，其技术效果与上述方法的技术效果相对应，这里不再赘述。

附图说明

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

图1为本申请所提供的一种基于文件对比的配置文件交互式更新方法实施例一的实现流程图；

图2为本申请所提供的一种基于文件对比的配置文件交互式更新方法实施例一中全量更新的编译打包过程的实现流程图；

图3为本申请所提供的一种基于文件对比的配置文件交互式更新方法实施例一中全量更新的部署过程的实现流程图；

图4为本申请所提供的一种基于文件对比的配置文件交互式更新方法实施例一中增量更新的编译打包过程的实现流程图；

图5为本申请所提供的一种基于文件对比的配置文件交互式更新方法实施例一中增量更新的部署过程的实现流程图；

图6为本申请所提供的一种基于文件对比的配置文件交互式更新方法实施例二中更新历史文件生成过程的实现流程图；

图7为本申请所提供的一种基于文件对比的配置文件交互式更新方法实施例二中配置文件部署过程的实现流程图；

图8为本申请所提供的一种基于文件对比的配置文件交互式更新装置实施例的功能框。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面结合附图和具体实施方式对本申请作进一步的详细说明。显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

对于使用配置文件来进行应用程序动态启动/运行的情况考虑下述场景：目标部署服务器处于客户涉密机房中，初次部署时需要进行关联数据库、缓存、zookeeper集群配置，以及debug功能的关闭，日志路径等的打印。假设开发时采用了配置文件application.properties来存放当前运行的WebApp的配置文件，由于客户较多、环境多或者保密等其他原因，无法在出厂时将此配置文件配置为生产环境可用的状态。很多情况下，此文件都是在生产环境现场，根据不同的情况，灵活配置完成，配置过程不外乎通过不同的文本编辑手段(文本编辑器+SCP，直接在服务器上nano/vi/vim编辑)。

对于初次部署，尤其是涉及数据库IP地址、集群地址等配置时，这是必须的过程，但是由于首次部署运行成功后会进行全量的功能校验，因此由配置文件输入错误导致问题的概率较小。问题出在对此环境进行增量升级时，由于新功能的添加，原有的配置文件项有不同程度的增减，对于同一个配置文件，现在有效的信息存在于三个位置：上次部署后未修改过的配置项和值，存储于项目路径中；上次部署后修改(包含新增)过的配置项与默认值，存储于升级包的配置文件中；修改的配置中，根据生产环境需要修改的值，由运维人员掌握。

每次升级过程中，都要把上述三部分信息有机整合在一起。然而实际上，由于传统方式基于手工操作，且需要整理的内容比较分散，加之部分情况下，画面信息通过跳板机/堡垒机的转发后比较模糊，增加了配置文件出错的概率，且一般情况下，由于增量升级原则上仅验证本次升级中受影响的部分，而配置文件出错部分可能并不在需要验证的内容中，导致系统上线运行时发生错误。

针对上述问题，本申请提供了一种基于文件对比的配置文件交互式更新方法、装置及系统，通过对比当前版本的配置文件和上一版本的配置文件，归并出需要更新的配置项，进而通过交互式的操作界面提示运维人员进行配置，避免了人工整理数据及修改配置项带来的错误，提升了配置文件更新效率和系统运维效率。

下面对本申请提供的一种基于文件对比的配置文件交互式更新方法实施例一进行介绍，参见图1，实施例一包括：

S101、对比当前版本的配置文件和上一版本的配置文件，确定当前版本相对上一版本的更新记录，并将所述更新记录追加至更新历史文件；

S102、根据所述更新历史文件在操作界面显示待配置项，并根据用户在所述操作界面的操作确定所述待配置项的实际值；

S103、根据所述待配置项的实际值，对生产环境中的目标配置文件进行更新操作。

本实施例在配置设备一侧设置有更新历史文件，更新历史文件内部包含了对应配置文件所有相关子项的更新历史，在实际应用中，可以使用一行来存储单个配置项的一次更新记录。为了后续在生产环境的效率和有效性，单条更新记录应该至少包含以下几部分信息：

版本号：这是本配置文件第几次更改，决定了在生产环境上，是从何处开始进行本次更新；

操作类型：标识本次操作是增加、修改还是删除，决定了在生产环境上如何进行配置；

更新记录的key值：本更新记录对应的key值；

更新记录的value值：本更新记录对应的value值；

key长度：对于更通用的情况，无论定义什么分割符都无法完全避免此分隔符在key中出现，因此，需要记录key的长度来决定key和value的边界。

相应的，在生产环境一侧可以设置版本文件，用以记录生产环境中目标配置文件的版本号。在对目标配置文件进行更新之前，首先读取其版本号，并在更新后，修改版本文件中记录的目标配置文件的版本号。

可以理解的是，更新历史文件作为沟通打包过程和更新过程的桥梁，需要在打包过程中进行生成，并通过打包及部署过程带出。对于同一个安装包的不同部署目的，更新历史文件应该是一致的。版本则不然，该文件只跟实际生产环境已部署的版本有关。

本实施例依据处理流程将配置文件更新过程划分为三个阶段，即编译阶段、打包阶段和部署阶段；并依据更新时机将配置文件更新过程分为两类，即全量更新和增量更新。下面分别对全量更新的三个阶段、增量更新的三个阶段进行说明。

全量更新的编译过程和打包过程如图2所示，在项目初始化时，由于第一次部署时源码部分还没有更新历史文件，所以要在编译过程中生成。该过程具体如下：在配置设备侧，创建更新历史文件，利用Maven插件将当前版本的配置文件的所有配置项作为更新记录写入更新历史文件，此时更新记录中的操作类型为“ADD”(增加)；利用Maven插件对更新历史文件进行打包，此时可以同时打包当前版本的配置文件。

全量更新的部署过程如图3所示，在项目第一次部署时，此时更新历史文件中包含了全量的配置文件，但是生产环境还没有版本文件，因此生产环境判定当前为初次部署。将更新历史文件或配置文件全文拷贝到生产环境中，得到初始的目标配置文件，并创建版本文件，将版本文件中记录的目标配置文件的版本号设置为更新历史文件中最大的版本号。

增量更新的编译过程和打包过程如图4所示，在配置设备侧，首先获取上一版本的配置文件，并利用Maven插件对比上一版本的配置文件与当前版本的配置文件，确定当前版本相对于上一版本更改项，将更改项、该更改项的操作类型、当前版本号等信息作为更新记录，追加至更新历史文件中。最后，利用Maven插件对更新历史文件进行打包。

增量更新的部署过程如图5所示，在生产环境中，更新脚本检测到更新历史文件，识别当前生产环境中目标配置文件的版本号，然后查找更新历史文件，如果更新历史文件中有版本号更大的更新记录，则汇总更新记录后，通过操作界面向运维人员展示待配置项、待配置项的默认值和可选操作项，所述可选操作项包括以下任意一项或多项：拒绝更新、确认更新、确认默认值、修改默认值。最终，根据运维人员的操作对待配置项的增删改，得到待配置项的实际值。更新过程中，依据各个待配置项的实际值对目标配置文件进行更新操作，并在更新操作完成后，更新版本文件中记录的目标配置文件的版本号。

最后，值得一提的是，本申请的实施过程基于以下背景实现：

Apache Maven是Apache下的一个纯Java开发的开源项目，基于项目对象模型(POM)概念，通过解析POM中的信息，来自动化完成编译、构建、打包等过程。Maven本身其实并不提供任何直接的依赖或者构建工具，Maven本身只是提供了一个插件运行框架，实际运行时，通过解析pom.xml(及其指定的依赖树中的所有依赖)，定位相应的插件，再根据配置从远程仓库或者本地仓库加载插件，再运行插件。同时，Maven通过灵活的配置与配置注入，大大加强了插件的通用性。本申请通过一个自定义的插件，并将插件附着到Maven的package过程，来生成仅存在于最终输出的打包环境的文本编辑记录，以备生产阶段的脚本使用。

Linux目前是使用量最大的服务端操作系统，虽然理论上Linux仅仅是一个内核，但是对于大部分实际使用的Linux发行版(如RedHat、CentOS、Fedora、Debian)来说，均提供了对于shell脚本的操作，同时提供了grep、awk等工具来进行文本流的读取筛选和操作，这为构建一个Linux通用的脚本提供了环境基础。

本申请通过结合上述的环境和工具，设置了一套通用的文本操作工具，通过加载打包阶段生成的diff信息以及目标更新环境的信息，完成配置文件信息的识别于筛选，结合shell提供的交互式操作方法，将易出错的配置过程自动化。

综上，本实施例所提供一种基于文件对比的配置文件交互式更新方法，通过对比当前版本的配置文件和上一版本的配置文件，抽取当前版本的配置文件中进行个性化配置的条目，归并出需要更新的配置项，进而通过交互式的操作界面提示运维人员进行配置，从而避免了人工整理数据及修改配置项带来的错误，提升了配置文件更新效率和系统运维效率。

下面开始详细介绍本申请提供的一种基于文件对比的配置文件交互式更新方法实施例二，实施例二基于前述实施例一实现，并在实施例一的基础上进行了一定程度上的拓展。

配置文件更新过程包括两部分，分别为编译打包过程和部署过程，连接此两部分过程的文件为更新历史文件，更新历史文件由Maven插件在编译过程中生成，属于源代码的一部分存入代码仓库，同时随打包过程一起存入产出的压缩包中。

更新历史文件的具体生成流程如图6所示。为完成上述过程，需要定义一个Maven插件，并实现Maven插件对象，Maven插件对象对配置文件的操作有以下几个步骤：

S61、读取项目的pom.xml的配置，结合插件本身的约定，确定要处理的配置文件的位置，举例如下：

S62、遍历每一个配置文件，执行S63-S65；

S63、读取配置文件，解析成key-value对的数组，并且key不重复，一般情况下可选用哈希表来存储，定义为当前配置；

S64、判断此配置文件是否已经有对应的更新历史文件，如果还没有对应的更新历史文件，则将当前配置中所有项标识为增加，并写入更新历史中，版本号为初始版本号。更新文件处理结束，跳过S65。如果已有对应的更新历史文件，执行S65。

S65、汇总上一步查找到的更新历史文件，将每个key-value对对应的操作汇总后，形成一个key-value对数组，与S63相似推荐使用哈希表存储，定义为原配置。以key为基准比对原配置和当前配置，对于每个key，可能产生下面3种情况：

a)原配置中有，当前配置中没有：追加一条删除记录到更新历史文件；

b)原配置中value与当前配置不一致：追加一条修改记录到更新历史文件；

c)原配置中没有，当前配置中有：追加一条增加记录到更新历史文件。

一个典型的更新历史文件内容如下所示：

1,A,1,a,netscape

2,A,5,debug,true

2,A,2,db,192.168.0.1

2,A,6,switch,true

3,A,3,ddd,acz

4,M,3,ddd,ecd

5,D,5,debug,-

该更新历史文件中，以“,”作为分割符，从前到后分别为版本号、操作Flag，key长度，key和默认value。

至此一个配置文件处理完成，对每一个配置文件执行S63-S65来生成所有的更新历史文件后，通过Maven的打包资源配置，可以指定将配置文件打包进最后发布的包中。至此，打包过程完成。

在生产环境中，需要用到两个文件，一个是上述打包过程中生成的更新历史文件，另外一个是存储在生产环境的记录目标配置文件的版本号的版本文件。整个处理过程如图7所示，完成配置文件部署过程，选用shell脚本中相关支持的文本处理工具来实施，具体过程如下所示：

S71、通过配置文件文件名和指定的后缀在更新目标目录中查找版本号文件，如果没有，直接将更新包中的配置文件拷贝到目标目录中；

S72、如果有版本号文件，通过cat读取版本号，定义为当前版本号；

S73、通过cat和grep工具，查找配置文件对应的更新历史中，版本号比当前版本号大的行，顺序读取成为一个字符串数组；

S74、定义三个空的key-value对数组，分别存储增加、修改、删除的配置项，按顺序处理字符串数组的每一项，按定义的更新记录条目格式进行拆分，根据拆分出的动作标识，在对应的数组中进行处理；

S75、对上一步生成的每一个增加、修改、删除的条目，提示运维人员进行确认或者修改，运维人员可以选择执行操作、修改默认值或者不执行操作，将运维人员的选择存储并进行汇总；

S76、将上一步汇总的结果回写到目的配置文件中，并增加版本标识号。

综上，一方面，传统的生产环境配置文件更新方式容易出错，采用本实施例的基于文件对比的配置文件交互式更新方法后，大大降低出错概率。另一方面，传统的生产环境依赖于文本编辑器及其提供的文本查询/跳转功能，在使用低性能堡垒机/跳板机的环境下，使用体验较差，采用本实施例的方法后，不需要处理文本搜索与跳转，提高了使用体验。

下面对本申请实施例提供的一种基于文件对比的配置文件交互式更新装置进行介绍，下文描述的一种基于文件对比的配置文件交互式更新装置与上文描述的一种基于文件对比的配置文件交互式更新方法可相互对应参照。

如图8所示，本实施例的装置包括：

对比模块801：用于对比当前版本的配置文件和上一版本的配置文件，确定当前版本相对上一版本的更新记录，并将所述更新记录追加至更新历史文件；

配置模块802：用于根据所述更新历史文件在操作界面显示待配置项，并根据用户在所述操作界面的操作确定所述待配置项的实际值；

更新模块803：用于根据所述待配置项的实际值，对生产环境中的目标配置文件进行更新操作。

本实施例的基于文件对比的配置文件交互式更新装置用于实现前述的基于文件对比的配置文件交互式更新方法，因此该装置中的具体实施方式可见前文中的基于文件对比的配置文件交互式更新方法的实施例部分，例如，对比模块801、配置模块802、更新模块803，分别用于实现上述基于文件对比的配置文件交互式更新方法中步骤S101，S102，S103。所以，其具体实施方式可以参照相应的各个部分实施例的描述，在此不再展开介绍。

另外，由于本实施例的基于文件对比的配置文件交互式更新装置用于实现前述的基于文件对比的配置文件交互式更新方法，因此其作用与上述方法的作用相对应，这里不再赘述。

最后，本申请还提供了一种基于文件对比的配置文件交互式更新系统，包括：配置设备和生产环境中的服务器；

其中，所述配置设备用于对比当前版本的配置文件和上一版本的配置文件，确定当前版本相对上一版本的更新记录，并将所述更新记录追加至更新历史文件；

所述服务器用于根据所述更新历史文件在操作界面显示待配置项，并根据用户在所述操作界面的操作确定所述待配置项的实际值；根据所述待配置项的实际值，对本地的目标配置文件进行更新操作。

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

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

以上对本申请所提供的方案进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (8)

1.一种基于文件对比的配置文件交互式更新方法，其特征在于，包括：

对比当前版本的配置文件和上一版本的配置文件，确定当前版本相对上一版本的更新记录，并将所述更新记录追加至更新历史文件；

根据所述更新历史文件在操作界面显示待配置项，并根据用户在所述操作界面的操作确定所述待配置项的实际值；

根据所述待配置项的实际值，对生产环境中的目标配置文件进行更新操作；

其中，所述对比当前版本的配置文件和上一版本的配置文件，确定当前版本相对上一版本的更新记录，并将所述更新记录追加至更新历史文件，包括：

在配置设备侧的编译阶段，利用Maven插件对比当前版本的配置文件和上一版本的配置文件，确定当前版本相对上一版本的更新记录，并将所述更新记录追加至更新历史文件；

在配置设备侧的打包阶段，利用Maven插件对所述更新历史文件和所述上一版本的配置文件进行打包，以发送至生产环境侧。

2.如权利要求1所述的方法，其特征在于，所述将所述更新记录追加至更新历史文件；根据所述更新历史文件在操作界面显示待配置项，包括：

将所述更新记录和当前版本号追加至更新历史文件；

通过查询版本文件确定生产环境中目标配置文件的版本号；

根据所述目标配置文件的版本号和所述更新历史文件，在操作界面显示待配置项和所述待配置项的默认值。

3.如权利要求2所述的方法，其特征在于，在所述根据所述待配置项的实际值，对生产环境中的目标配置文件进行更新操作之后，还包括：

将所述版本文件中所述目标配置文件的版本号更新为所述当前版本号。

4.如权利要求3所述的方法，其特征在于，所述确定当前版本相对上一版本的更新记录，并将所述更新记录追加至更新历史文件，包括：

确定当前版本相对上一版本的更新记录，并将所述更新记录追加至更新历史文件，所述更新记录包括当前版本号、操作类型、更新记录的key值、更新记录的value值。

5.如权利要求1所述的方法，其特征在于，所述根据所述更新历史文件在操作界面显示待配置项，包括：

根据所述更新历史文件在操作界面显示待配置项和可选操作项，所述可选操作项包括以下任意一项或多项：拒绝更新、确认更新、确认默认值、修改默认值。

6.如权利要求1所述的方法，其特征在于，所述对比当前版本的配置文件和上一版本的配置文件，确定当前版本相对上一版本的更新记录，并将所述更新记录追加至更新历史文件，包括：

获取当前版本的配置文件；

判断本地是否记录有上一版本的配置文件；

若是，则获取上一版本的配置文件，对比所述当前版本的配置文件和所述上一版本的配置文件，确定当前版本相对上一版本的更新记录，并将所述更新记录追加至更新历史文件；

若否，则将所述当前版本的配置文件作为更新记录存储至更新历史文件。

7.一种基于文件对比的配置文件交互式更新装置，其特征在于，包括：

对比模块：用于对比当前版本的配置文件和上一版本的配置文件，确定当前版本相对上一版本的更新记录，并将所述更新记录追加至更新历史文件；

配置模块：用于根据所述更新历史文件在操作界面显示待配置项，并根据用户在所述操作界面的操作确定所述待配置项的实际值；

更新模块：用于根据所述待配置项的实际值，对生产环境中的目标配置文件进行更新操作；

其中，所述对比模块：具体用于在配置设备侧的编译阶段，利用Maven插件对比当前版本的配置文件和上一版本的配置文件，确定当前版本相对上一版本的更新记录，并将所述更新记录追加至更新历史文件；

在配置设备侧的打包阶段，利用Maven插件对所述更新历史文件和所述上一版本的配置文件进行打包，以发送至生产环境侧。

8.一种基于文件对比的配置文件交互式更新系统，其特征在于，包括：配置设备和生产环境中的服务器；

其中，所述配置设备用于对比当前版本的配置文件和上一版本的配置文件，确定当前版本相对上一版本的更新记录，并将所述更新记录追加至更新历史文件；

所述服务器用于根据所述更新历史文件在操作界面显示待配置项，并根据用户在所述操作界面的操作确定所述待配置项的实际值；根据所述待配置项的实际值，对本地的目标配置文件进行更新操作；

其中，所述配置设备具体用于在配置设备侧的编译阶段，利用Maven插件对比当前版本的配置文件和上一版本的配置文件，确定当前版本相对上一版本的更新记录，并将所述更新记录追加至更新历史文件；

在配置设备侧的打包阶段，利用Maven插件对所述更新历史文件和所述上一版本的配置文件进行打包，以发送至生产环境侧。