本发明涉及通信技术领域，尤其涉及一种web(worldwideweb，全球广域网)系统版本部署方法、设备和存储介质。
背景技术
目前，在互联网中存在大量的web系统，以便为海量用户提供服务。在针对web系统进行新版本发布时，现有的做法都是运维人员通过手动操作线上的机器来完成的，但是，这种人工部署web系统版本的方式，工作量大，人工成本高，而且由于系统文件的配置过程复杂，部署效率低，人工操作容易出现低级错误，部署成功率低。
技术实现要素：
本发明的主要目的在于提出一种web系统版本部署方法、设备和存储介质，旨在解决人工部署web系统版本效率低且成功率低的问题。
为了解决上述技术问题，本发明是通过以下技术方案来解决的：
本发明提供了一种全球广域网web系统版本部署方法，包括：为web系统配置待部署配置文件；在预设的版本仓库中，获取所述web系统对应的系统文件；使用所述待部署配置文件覆盖所述系统文件中的配置文件，形成新版本的系统文件并将所述新版本的系统文件部署到所述web系统。
可选地，在获取所述web系统对应的系统文件之后，在使用所述待部署配置文件覆盖所述系统文件中的配置文件之前，还包括：根据所述系统文件中的配置文件的格式，对所述待部署配置文件进行格式转换。
可选地，在使用所述待部署配置文件覆盖所述系统文件中的配置文件之前，还包括：将所述待部署配置文件和所述系统文件中的配置文件进行比较；如果所述待部署配置文件的属性数量和所述配置文件的属性数量相同，并且所述待部署配置文件的参数名称和所述配置文件的参数名称都相同，则使用所述待部署配置文件覆盖所述配置文件。
可选地，为web系统配置待部署配置文件，包括：针对所述web系统配置多个功能模块；分别为每个所述功能模块配置业务参数信息；根据为每个所述功能模块配置的业务参数信息，生成待部署配置文件。
可选地，为web系统配置待部署配置文件，包括：针对所述web系统配置多个功能模块；分别为每个所述功能模块配置运行环境和业务参数信息；根据为每个所述功能模块配置的运行环境和业务参数信息，生成待部署配置文件。
可选地，分别为每个所述功能模块配置运行环境和业务参数信息，包括：分别为每个所述功能模块配置多个运行环境以及与每个所述运行环境对应的业务参数信息；根据为每个所述功能模块配置的运行环境和业务参数信息，生成待部署配置文件，包括：针对每个运行环境，根据为每个所述功能模块配置的与所述运行环境对应的业务参数信息，生成与所述运行环境对应的待部署配置文件。
可选地，所述方法还包括：预先备份所述web系统当前运行的系统文件；在将所述新版本的系统文件部署到所述web系统的过程中，如果版本部署失败，则根据备份的所述系统文件执行回滚操作。
可选地，所述方法还包括：预先设置校验地址；在将所述新版本的系统文件部署到所述web系统的过程中，访问所述校验地址，如果访问失败，则判定版本部署失败。
本发明还提供了一种web系统版本部署设备，所述web系统版本部署设备包括处理器、存储器；所述处理器用于执行所述存储器中存储的web系统版本部署程序，以实现上述的web系统版本部署方法。
本发明又提供了一种存储介质，所述存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现上述的web系统版本部署方法。
本发明提出的web系统版本部署方法、设备和存储介质，具有以下技术效果：
本发明将系统文件中的系统代码和配置文件分离，配置新版本的配置文件，使用新版本的配置文件覆盖系统文件中旧版本的配置文件，进而形成新版本的系统文件，通过本发明可以实现自动部署web系统版本的目的，能够提高web系统版本发布的效率以及成功率，节省人工成本，避免人工操作出现的低级错误。
附图说明
图1为根据本发明第一实施例的web系统版本部署方法的流程图；
图2为根据本发明第二实施例的配置待部署配置文件的步骤流程图；
图3为根据本发明第三实施例的配置待部署配置文件的示意图；
图4为根据本发明第三实施例的配置待部署配置文件的步骤流程图；
图5为根据本发明第四实施例的形成新版本的系统文件的步骤流程图；
图6为根据本发明第五实施例的部署新版本的系统文件的步骤流程图；
图7为根据本发明第六实施例的web系统版本部署方法的示意图；
图8为根据本发明第七实施例的web系统版本部署设备的结构图。
本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。
具体实施方式
应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
现在将参考附图描述实现本发明各个实施例的移动终端。在后续的描述中，使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本发明的说明，其本身并没有特定的意义。因此，"模块"与"部件"可以混合地使用。
以下结合附图以及实施例，对本发明进行进一步详细说明。本领域技术人员应当理解的是，此处所描述的具体实施例仅仅用以解释本发明，并不限定本发明。
实施例一
本发明实施例提供一种web系统版本部署方法。该方法可以应用于自动部署web系统版本的后台系统中。如图1所示，为根据本发明第一实施例的web系统版本部署方法的流程图。
步骤s110，为web系统配置待部署配置文件。
web系统为选定的目标web系统，在该目标web系统进行版本发布。
待部署配置文件即是需要部署在目标web系统中的配置文件。
具体的，可以根据需求设置配置规则，根据配置规则实现待部署配置文件的配置；也可以为用户提供用户界面，用户可以在该用户界面中选择目标web系统并且配置待部署配置文件中的属性和参数。其中，用户可以是开发人员、测试人员、产品经理、项目经理等。
步骤s120，在预设的版本仓库中，获取所述web系统对应的系统文件。
版本仓库，用于存储web系统的系统文件。在形成新版本的系统文件之后，可以将新版本的系统文件压缩成war包并存储到预设的版本仓库中，以便在后续进行web系统版本部署时使用。
系统文件，包括：系统代码和配置文件。
在本实施例中，版本仓库中的系统文件为war包。解压缩war包，可以得到系统文件中的系统代码和配置文件。
在本实施例中，系统文件分成系统代码和配置文件两个部分。将系统代码和配置文件分开管理，在部署web系统版本时，按照新的需求配置新的配置文件即可，从而促进了系统解耦。
步骤s130，使用所述待部署配置文件覆盖所述系统文件中的配置文件，形成新版本的系统文件并将所述新版本的系统文件部署到所述web系统。
在使用所述待部署配置文件覆盖所述系统文件中的配置文件之前，还包括：将所述待部署配置文件和所述系统文件中的配置文件进行比较；如果所述待部署配置文件的属性数量和所述配置文件的属性数量相同，并且所述待部署配置文件的参数名称和所述配置文件的参数名称都相同，则使用所述待部署配置文件覆盖所述配置文件。进一步地，如果待部署配置文件和配置文件的格式不统一，可以在转换所述待部署配置文件的格式之后，将所述待部署配置文件和所述系统文件中的配置文件进行比较；如果所述待部署配置文件的属性数量和所述配置文件的属性数量相同，并且所述待部署配置文件的参数名称和所述配置文件的参数名称都相同，则使用所述待部署配置文件覆盖所述配置文件。
在本实施例中，为了保证系统能够安全、稳定运行，可以预先备份所述web系统当前运行的系统文件；在将所述新版本的系统文件部署到所述web系统的过程中，如果版本部署失败，则根据备份的所述系统文件执行回滚操作。进一步地，可以预先设置校验地址；在将所述新版本的系统文件部署到所述web系统的过程中，访问所述校验地址，如果访问失败，则判定版本部署失败。校验地址可以是用于校验的url(uniformresourcelocato，统一资源定位符)地址。
本实施例提供了一套自动部署web系统版本的方案，将系统代码和配置文件分离管理，在需要部署web系统版本时，配置新版本的配置文件，使用新版本的配置文件覆盖系统文件中旧版本的配置文件，进而形成新版本的系统文件，通过本实施例可以实现自动部署web系统版本的目的，能够提高web系统版本发布的效率以及成功率，节省人工成本，避免人工操作出现的低级错误。
实施例二
下面对配置待部署配置文件的步骤进行进一步的描述。图2为根据本发明第二实施例的配置待部署配置文件的步骤流程图。
步骤s210，为所述web系统创建版本部署项目。
创建版本部署项目，包括但不限于：配置版本目录，输入新的版本号，选定目标web系统所在机器的ip地址(internetprotocoladdress，互联网协议地址)和端口号，设置用户角色和权限，配置功能模块，配置运行环境，配置业务参数信息。
业务参数信息包括多个业务参数。
在本实施例中，可以根据用户职责的不同，为每个用户设置角色和权限，使不同用户具有不同的分工。例如：为开发人员设置配置权限，为项目经理设置审批权限。这样可以细化用户的分工，增加版本部署的安全性。
在本实施例中，用户将版本部署按照项目进行管理，这样用户可以同时管理多个版本部署项目，从而可以实现不同的版本部署目的，并且使版本部署全流程更加清晰，有条理。
步骤s220，在所述版本部署项目下，针对所述web系统配置多个功能模块。
将web系统分割为不同的功能(功能代码)，每个所述功能模块对应web系统的一个或多个功能。例如：第一功能模块对应web系统的搜索功能，第二功能模块对应web系统的排行榜功能。
步骤s230，分别为每个所述功能模块配置业务参数信息。
在需要重新部署web系统版本时，根据当前配置的功能模块所对应的web系统功能，配置该功能模块的业务参数信息。
步骤s240，根据为每个所述功能模块配置的业务参数信息，生成待部署配置文件。
换言之，由于每个功能模块对应web系统的一部分，所以汇总为多个功能模块配置的所有业务参数信息，可以生成整个web系统的待部署配置文件。
在本实施例中，针对web系统配置多个功能模块，实现了将web系统进行划分，这样可以针对每个功能模块配置业务参数信息，在版本部署过程中，如果其中一个功能模块的业务参数信息出现问题，仅调整该出现问题的功能模块的业务参数信息即可，不会对其他功能模块造成影响，降低了版本部署难度，而且进一步促进了系统解耦。
实施例三
下面结合图3所示的配置待部署配置文件的示意图，对配置待部署配置文件的步骤进行进一步的描述。根据图3可知，本实施例可以为web版本部署配置运行环境(如测试环境和正式环境)，具体如下：
图4是根据本发明第三实施例的配置待部署配置文件的步骤流程图。
步骤s410，为所述web系统创建版本部署项目。
步骤s420，在所述版本部署项目下，针对所述web系统配置多个功能模块。
步骤s430，分别为每个所述功能模块配置运行环境和业务参数信息。
运行环境，包括：测试环境、正式运行环境等。
由于同一功能模块在不同的运行环境下，需要配置不同的业务参数信息，因此，在为同一功能模块配置运行环境和业务参数信息时，需要根据为功能模块配置的运行环境配置对应的业务参数信息。
在本实施例中，可以为版本部署指定多个运行环境。
具体的，可以为同一功能模块配置多个运行环境，并且针对该功能模块，为每个运行环境对应配置业务参数信息。还可以分别为每个所述功能模块配置多个运行环境以及与每个所述运行环境对应的业务参数信息。进一步地，可以根据待部署的多个运行环境，为每个功能模块配置种类相同的多个运行环境和数量相同的多个业务参数信息，其中，为功能模块的每个运行环境对应一个业务参数信息。
在为功能模块配置运行环境时，可以通过配置环境参数信息来体现运行环境。进一步地，为每个功能模块配置环境参数信息以及与环境参数信息对应的业务参数信息。
环境参数信息包括但不限于：运行环境对应的数据库地址、账号和密码。
步骤s440，根据为每个所述功能模块配置的运行环境和业务参数信息，生成待部署配置文件。
如果为每个功能模块配置了多个运行环境，那么针对每种运行环境，根据为每个所述功能模块配置的与所述运行环境对应的业务参数信息，生成与所述运行环境对应的待部署配置文件，进而可以获得多个待部署配置文件，且每个待部署配置文件对应一种运行环境。即，获取多个功能模块在同一运行环境下的业务参数信息，根据该同一运行环境对应的所有待部署配置文件，生成该同一运行环境对应的待部署配置文件；再获取多个功能模块在另一运行环境下的业务参数信息，根据该另一运行环境对应的所有待部署配置文件，生成该另一运行环境对应的待部署配置文件；以此类推，直到所有运行环境对应的待部署配置配件都生成为止。
进一步地，可以针对多个功能模块，获取对应相同环境参数信息的业务参数信息，根据多个功能模块对应相同环境参数信息的业务参数信息，生成该相同运行环境对应的待部署配置文件。
例如：为第一功能模块配置运行环境1以及与运行环境1对应的业务参数信息a、运行环境2以及与运行环境2对应的业务参数信息b，为第二功能模块配置运行环境1以及与运行环境1对应的业务参数信息c、运行环境2以及与运行环境2对应的业务参数信息d；根据业务参数信息a和业务参数信息c，生成运行环境1对应的待部署配置文件；根据业务参数信息b和业务参数信息d，生成运行环境2对应的待部署配置文件。
在本实施例中，用户可以针对管理多个项目，可以针对项目配置版本目录，配置多个功能模块，配置多个(正式、测试、自定义等)运行环境。配置多个运行环境，只需提供与运行环境对应的业务参数信息即可。版本目录可以与自动化构建方法相结合，做到自动化构建和自动化部署的双重效果。
实施例四
在将新版本的系统文件部署到目标web系统之前，需要通过配置的待部署配置文件和系统文件，形成新版本的系统文件。如图5所示，为根据本发明第四实施例的形成新版本的系统文件的步骤流程图。
步骤s510，备份web系统当前正在运行的系统文件。
为了避免在部署web系统版本的过程出现版本部署失败的问题，备份web系统当前正在运行的系统文件，如果版本部署失败，则可以利用备份的系统文件进行回退。
当然，备份web系统当前正在运行的系统文件，也可以在其他时间点执行，只要在将新版本的系统文件复制到web系统之前执行即可。
步骤s520，解压缩从版本仓库中获取的与该web系统对应的系统文件。
由于web系统在运行系统文件的过程中，系统文件的属性和参数可能会发生改变，所以在进行版本部署时，需要在形成新版本的系统文件之后，先将新版本的系统文件压缩为war包，存储到版本仓库，在需要重新部署web系统版本时，解压缩版本仓库中与该web系统对应的war包，基于解压缩后得到的系统文件，形成新的系统文件。
步骤s530，在解压缩后的系统文件中，获取配置文件，并将待部署配置文件和该配置文件进行比较。
步骤s540，判断待部署配置文件的属性数量和配置文件的属性数量是否相同；如果是，则执行步骤s550；如果否，则执行步骤s570。
步骤s550，判断待部署配置文件中的参数名称和配置文件中的参数名称是否都相同；如果是，则执行步骤s560；如果否，则执行步骤s570。
也就是说，如果所述待部署配置文件的属性数量和所述配置文件的属性数量相同，并且所述待部署配置文件的参数名称和所述配置文件的参数名称都相同，则使用所述待部署配置文件覆盖所述配置文件。
步骤s560，使用待部署配置文件覆盖所述配置文件，形成新版本的系统文件。
使用待部署配置文件覆盖解压缩后的系统文件中的配置文件，可以使待部署配置文件和系统代码结合，得到一个新版本的系统文件。
该新版本的系统文件与待部署配置文件对应的运行环境对应。进一步地，系统代码只有一套，如果系统代码与测试环境对应的待部署配置文件结合，则可以得到测试版本的系统文件，如果系统代码与正式运行环境对应的待部署配置结合，则可以得到正式运行版本的系统文件。
在得到新版本的系统文件时，触发将新版本的系统文件部署到web系统。此时，可以根据该触发事件生成操作日志。
在形成新版本的系统文件之后，可以对新版本的系统文件进行压缩，得到war包，并将该新版本的系统文件的war包存储到版本仓库中。
步骤s570，提示版本部署失败，根据备份的系统文件执行回滚操作。
执行回滚操作，可以使web系统运行备份的系统文件，基于备份的系统文件提供服务，避免服务中断。
在本实施例中，可以在获取所述web系统对应的系统文件之后，在使用所述待部署配置文件覆盖所述系统文件中的配置文件之前，还包括：根据所述系统文件中的配置文件的格式，对所述待部署配置文件进行格式转换。进一步地，系统文件中的配置文件的格式，能够被web系统识别，因此在使用待部署配置文件替换系统文件中的配置文件之前，将待部署配置文件的格式转换为web系统能够识别的格式。
为了方便web系统识别和替换配置文件，本发明为web系统配置的待部署配置文件可以是使用通配符格式定义的配置属性集，对于属性值可以使用通配符@％xx％@来定义。如果待部署的运行环境为多个，则可以通过不同的通配符来定义不同运行环境对应的属性。
例如：待部署配置文件common.properties的格式如下：
ip＝@％property_ip％@(该行代码描述web系统的ip地址)；
port＝@％property_port％@(该行代码描述web系统的端口号)；
username＝@％property_username％@(该行代码描述web系统的账号)；
password＝@％property_password％@(该行代码描述web系统的密码)；
待部署配置文件common.properties如下：
ip＝@％192.168.1.1％@；
port＝@％8080％@；
username＝@％root％@；
password＝@％root％@；
将待部署配置文件的格式转换为系统文件中配置文件的格式，经过转换后的待部署配置文件common.properties如下：
ip＝192.168.1.1；
port＝8080；
username＝root；
password＝root。
针对待部署的运行环境为多个的情况，可以使用不同的通配符来区分不同运行环境对应的业务参数信息。
本实施例之所以需要经历格式转换步骤，存在几下几点考虑：
(1)代码和配置文件分离，代码开发者不需要关注不同运行环境下不同值的差异，这样可以避免不同运行环境下的配置差异导致的潜在问题。
(2)提高信息安全性，正式环境的地址、账号和密码都属于敏感信息，不应该被广泛传播，通过这样的转换机制，能把敏感信息在web系统中保护起来，代码开发者无法看到。
(3)对于不同运行环境通用的属性、或者是无需保护的属性信息，可以不用通配符标识，直接填写真实值。在转换过程中不会产生干扰，保证了开发的灵活性。
实施例五
下面对将新版本的系统文件部署到web系统的具体步骤进行进一步地描述。图6是根据本发明第五实施例的部署新版本的系统文件的步骤流程图。
步骤s601，检查web系统当前运行的系统文件和新版本的系统文件的版本号是否相同；如果是，则退出版本部署流程；如果否，则执行步骤s620。
由于在创建版本部署项目时，输入了版本号，所以系统文件的版本号可以在配置文件中查询到。
如果当前运行的系统文件和新版本的系统文件的版本号相同，则说明没有新版本需要部署，这时可以退出版本部署流程；如果当前运行的系统文件和新版本的系统文件的版本号不同，则可以进行新版本的系统文件的部署。
步骤s602，检查web系统所在的主机状态是否正常；如果是，则执行步骤s603；如果否，则执行退出版本部署流程。
例如：检测web系统的cpu(centralprocessingunit，中央处理器)利用率，如果cpu利用率大于预设的阈值，则判定为主机状态异常，这时退出版本部署流程。
步骤s603，从slb(serverloadbalancing，服务器负载均衡)设备上移除该主机，停止外对服务。
步骤s604，从该主机所在的反向代理服务器nginx上移除web系统对应的web应用服务器。
步骤s605，备份web系统当前正在运行的系统文件。
对当前版本的系统文件进行备份，以便在回退时使用。在本实施例中，备份操作在复制新版本的系统文件之前执行。
步骤s606，复制新版本的系统文件到预设存储位置。
该预设存储位置位于web应用服务器的版本目录下。
步骤s607，重启web系统对应的web应用服务器。
步骤s608，访问预设的校验地址check-url，并判断是否访问成功；如果是，则执行步骤s609；如果否，则执行步骤s611。
通过检查check-url是否能够访问，可以确认本次版本部署是否成功，如果访问成功，则说明版本部署成功，如果访问识别，则说明版本部署失败。由于已经将新版本的系统文件复制到预设存储位置，如果版本部署失败，则需要进行回滚操作，避免web系统无法正常提供服务。
步骤s609，将web系统对应的web应用服务器重新添加到nginx，恢复web应用服务器对外服务。
步骤s610，将web系统所在的主机重新挂载到slb，恢复主机对外服务。
步骤s611，根据备份的系统文件执行回滚操作。
执行回滚操作的目的在于恢复/回退到原来的网络状态，仍旧运行备份版本的系统文件。
通过本实施例的web系统版本部署方法，可以有效释放大量人力，经过试验，单个项目可以释放运维人力30％左右，并且极少出现版本部署过程中的低级失误。
本实施例可以自动识别版本部署过程中的各种异常，并对版本部署结果进行检查，如果版本部署失败，自动回退版本，保证版本部署成功或者版本部署失败都不会影响外部使用。
实施例六
下面给出一个较为具体的实施例，来对本发明的web系统版本部署方法进行较为详细的描述。
如图7所述为根据本发明第六实施例的web系统版本部署方法的示意图。
步骤1，通过持续集成服务器(ci-jekins)构建新版本的配置文件(待部署配置文件)，并上传到版本仓库，按照规范目录归档。
待部署配置文件包括版本二进制，以及包含releasenote、分支等信息的说明文件。
目录中保护项目名称、版本号，便于后续查找。
步骤2，版本仓库在系统文件的配置文件的版本发生变化时，由预设的监控脚本触发通知，扫描目录变化以及说明文件，通过有效性服务器(valid-jekins)通知版本信息数据库进行版本更新。
在版本信息数据库中存储有配置文件的版本信息，如目录信息和说明文件；在生成新版本的配置文件之后，版本仓库可以通过valid-jekins通知版本数据库进行版本更新。在该通知消息中可以携带新版本的配置文件。
步骤3，版本信息数据库收到版本变化的通知后，对新版本信息更新入库。
步骤4，用户登录中控台(中控台是一个web系统，用于管理配置信息、提供用户交互)，通过查询版本信息数据库查看版本信息。
步骤5，在中控台读取版本仓库中存储的测试报告。
版本仓库除了存储系统文件，还可以存储系统文件的测试报告，所以，中控台还可以从版本仓库中读取测试报告，并查看测试报告。
步骤6，在中控台触发部署新版本的系统文件。
在本实施例中，有两个操作用例可以触发部署。一个是中控台的项目管理人员按需要执行部署，另外一个是步骤7，由测试人员在valid-jekins执行测试环境的版本部署，用于测试。
步骤7，在valid-jekins触发部署新版本的系统文件。步骤6和步骤7任选一种触发方式即可。在本实施例中，选择在中控台触发部署。
步骤8，部署机从版本信息数据库读取该新版本的配置文件，检查是否重复部署，信息是否完整且合法。
部署机是一台linux服务器，是一个代理人，中控台触发部署新版本的系统，发出部署命令后，由部署机执行部署。
部署机具有各个运行环境、各台机器的免密sudo访问权限，这样才能执行文件拷贝、命令执行动作。
步骤8，部署机查询敏感配置仓库，在新版本的配置文件中存在敏感配置信息的情况下，执行待部署配置文件的格式转换。
其中，对于敏感配置信息，可以从预设的敏感配置仓库中读取。
敏感配置信息例如是不希望在web系统中被随意查看的配置信息。
敏感配置信息可以由运维工程师维护。
步骤9，部署机从版本仓库下载旧版本的系统文件，使用格式转换后的配置文件替换旧版本系统文件中的配置文件，形成新版本的系统文件，并将新版本的系统文件上传至版本仓库。
步骤10，执行部署脚本，将新版本的系统文件部署到用户测试服务器(prod-svr)。
实施例七
本实施例提供一种web系统版本部署设备。如图8所示，为根据本发明第七实施例的web系统版本部署设备的结构图。
在本实施例中，所述web系统版本部署设备800，包括但不限于：处理器810、存储器820。
所述处理器810用于执行存储器820中存储的web系统版本部署程序，以实现实施例一～实施例六所述的web系统版本部署方法。
具体而言，所述处理器810用于执行存储器820中存储的web系统版本部署程序，以实现以下步骤：为web系统配置待部署配置文件；在预设的版本仓库中，获取所述web系统对应的系统文件；使用所述待部署配置文件覆盖所述系统文件中的配置文件，形成新版本的系统文件并将所述新版本的系统文件部署到所述web系统。
可选地，所述处理器810还用于执行存储器820中存储的web系统版本部署程序，以实现以下步骤：在获取所述web系统对应的系统文件之后，在使用所述待部署配置文件覆盖所述系统文件中的配置文件之前，还包括：根据所述系统文件中的配置文件的格式，对所述待部署配置文件进行格式转换。
可选地，所述处理器810还用于执行存储器820中存储的web系统版本部署程序，以实现以下步骤：在使用所述待部署配置文件覆盖所述系统文件中的配置文件之前，将所述待部署配置文件和所述系统文件中的配置文件进行比较；如果所述待部署配置文件的属性数量和所述配置文件的属性数量相同，并且所述待部署配置文件的参数名称和所述配置文件的参数名称都相同，则使用所述待部署配置文件覆盖所述配置文件。
可选地，所述处理器810还用于执行存储器820中存储的web系统版本部署程序，以实现以下步骤：针对所述web系统配置多个功能模块；分别为每个所述功能模块配置业务参数信息；根据为每个所述功能模块配置的业务参数信息，生成待部署配置文件。
可选地，所述处理器810还用于执行存储器820中存储的web系统版本部署程序，以实现以下步骤：针对所述web系统配置多个功能模块；分别为每个所述功能模块配置运行环境和业务参数信息；根据为每个所述功能模块配置的运行环境和业务参数信息，生成待部署配置文件。
可选地，所述处理器810还用于执行存储器820中存储的web系统版本部署程序，以实现以下步骤：分别为每个所述功能模块配置多个运行环境以及与每个所述运行环境对应的业务参数信息；针对每个运行环境，根据为每个所述功能模块配置的与所述运行环境对应的业务参数信息，生成与所述运行环境对应的待部署配置文件。
可选地，所述处理器810还用于执行存储器820中存储的web系统版本部署程序，以实现以下步骤：预先备份所述web系统当前运行的系统文件；在将所述新版本的系统文件部署到所述web系统的过程中，如果版本部署失败，则根据备份的所述系统文件执行回滚操作。
可选地，所述处理器810还用于执行存储器820中存储的web系统版本部署程序，以实现以下步骤：预先设置校验地址；在将所述新版本的系统文件部署到所述web系统的过程中，访问所述校验地址，如果访问失败，则判定部署失败。
本发明将系统文件中的系统代码和配置文件分离，配置新版本的配置文件，使用新版本的配置文件覆盖系统文件中旧版本的配置文件，进而形成新版本的系统文件，通过本发明可以实现自动部署web系统版本的目的，能够提高web系统版本发布的效率以及成功率，节省人工成本，避免人工操作出现的低级错误。
实施例八
本发明实施例还提供了一种存储介质。这里的存储介质存储有一个或者多个程序。其中，存储介质可以包括易失性存储器，例如随机存取存储器；存储器也可以包括非易失性存储器，例如只读存储器、快闪存储器、硬盘或固态硬盘；存储器还可以包括上述种类的存储器的组合。
当存储介质中一个或者多个程序可被一个或者多个处理器执行，以实现上述的web系统版本部署方法。
具体而言，所述处理器用于执行存储器中存储的web系统版本部署程序，以实现以下步骤：为web系统配置待部署配置文件；在预设的版本仓库中，获取所述web系统对应的系统文件；使用所述待部署配置文件覆盖所述系统文件中的配置文件，形成新版本的系统文件并将所述新版本的系统文件部署到所述web系统。
可选地，在获取所述web系统对应的系统文件之后，在使用所述待部署配置文件覆盖所述系统文件中的配置文件之前，还包括：根据所述系统文件中的配置文件的格式，对所述待部署配置文件进行格式转换。
可选地，在使用所述待部署配置文件覆盖所述系统文件中的配置文件之前，还包括：将所述待部署配置文件和所述系统文件中的配置文件进行比较；如果所述待部署配置文件的属性数量和所述配置文件的属性数量相同，并且所述待部署配置文件的参数名称和所述配置文件的参数名称都相同，则使用所述待部署配置文件覆盖所述配置文件。
可选地，为web系统配置待部署配置文件，包括：针对所述web系统配置多个功能模块；分别为每个所述功能模块配置业务参数信息；根据为每个所述功能模块配置的业务参数信息，生成待部署配置文件。
可选地，为web系统配置待部署配置文件，包括：针对所述web系统配置多个功能模块；分别为每个所述功能模块配置运行环境和业务参数信息；根据为每个所述功能模块配置的运行环境和业务参数信息，生成待部署配置文件。
可选地，分别为每个所述功能模块配置运行环境和业务参数信息，包括：分别为每个所述功能模块配置多个运行环境以及与每个所述运行环境对应的业务参数信息；根据为每个所述功能模块配置的运行环境和业务参数信息，生成待部署配置文件，包括：针对每个运行环境，根据为每个所述功能模块配置的与所述运行环境对应的业务参数信息，生成与所述运行环境对应的待部署配置文件。
可选地，所述方法还包括：预先备份所述web系统当前运行的系统文件；在将所述新版本的系统文件部署到所述web系统的过程中，如果版本部署失败，则根据备份的所述系统文件执行回滚操作。
可选地，所述方法还包括：预先设置校验地址；在将所述新版本的系统文件部署到所述web系统的过程中，访问所述校验地址，如果访问失败，则判定部署失败。
本发明将系统文件中的系统代码和配置文件分离，配置新版本的配置文件，使用新版本的配置文件覆盖系统文件中旧版本的配置文件，进而形成新版本的系统文件，通过本发明可以实现自动部署web系统版本的目的，能够提高web系统版本发布的效率以及成功率，节省人工成本，避免人工操作出现的低级错误。
需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。
上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。
以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。