CN110502271A - 基于区块链的应用程序发版方法和系统 - Google Patents

Abstract

本申请涉及研发过程优化技术，特别是涉及一种基于区块链的应用程序发版方法和系统。所述方法包括：第一服务器将与生产系统中各子系统对应的新版本子系统的版本号和新版本子系统的状态数据发送至区块链；第二服务器从区块链上获取状态数据和版本号；第二服务器根据版本号判断是否对生产系统中的子系统进行升级；当确定对生产系统中的子系统进行升级时，第二服务器运行发版脚本，以获取与版本号对应的新版本子系统的安装文件，并确定各安装文件之间的发版顺序，按照发版顺序将安装文件发版到生产系统，根据安装文件对生产系统中对应的子系统进行更新。采用本方法能够提高应用程序的发版效率。

Description

基于区块链的应用程序发版方法和系统

技术领域

本申请涉及研发过程优化技术，特别是涉及一种基于区块链的应用程序发版方法和系统。

背景技术

许多企业为了实现多样化数据业务的需要，部署了包括有多个子系统的软件系统群，其中，软件系统群中的各子系统可以单独完成某个数据业务，或者需要多个子系统相互协作完成某个数据业务。为了提升使用的体验度或支持新增业务，软件系统群中的一个或多个子系统可能需要进行升级，在进行升级的过程中，需要对新开发的子系统进行测试和审批，当测试和审批通过后发版到软件系统群以实现对原有的对应子系统进行更新。

然而，软件系统群中的各子系统在处理数据业务时存在逻辑先后顺序，若发版时未严格按照顺序部署到软件系统群中，例如，为了支持新业务A，需要对子系统a-d进行更新，若新业务A在进行处理时，需要先后流转到子系统a-d中进行处理，在发版新版本子系统时，若对处于流程后面的子系统d先进行更新，可能会对处于流程前面的子系统a、b和c的功能造成破坏，从而会影响软件系统群的正常工作。

发明内容

基于此，有必要针对上述技术问题，提供一种基于区块链的应用程序发版方法和系统，能够避免发版新版子系统时影响软件系统群的正常工作。

一种基于区块链的应用程序发版方法，所述方法包括：

第一服务器将与生产系统中各子系统对应的新版本子系统的版本号和所述新版本子系统的状态数据发送至区块链；

第二服务器从所述区块链上获取所述状态数据和所述版本号；

所述第二服务器根据所述版本号判断是否对所述生产系统中的子系统进行升级；

当确定对所述生产系统中的子系统进行升级时，所述第二服务器运行发版脚本，以获取与所述版本号对应的新版本子系统的安装文件，并确定各所述安装文件之间的发版顺序，按照所述发版顺序将所述安装文件发版到所述生产系统，根据所述安装文件对所述生产系统中对应的子系统进行更新；所述发版脚本中配置有用于判断状态数据是否符合要求的发版条件。

在其中一个实施例中，所述状态数据包括针对所述新版本子系统的测试结果和审批结果；所述方法还包括：

所述第一服务器通过测试系统对所述新版本子系统进行测试得到测试结果，以及，通过审批系统对所述新版本子系统进行审批得到审批结果；

所述第一服务器将所得到的测试结果、审批结果和所述新版本子系统的版本号传送到区块链上。

在其中一个实施例中，所述方法还包括：

所述第一服务器确定各所述新版本子系统之间的关联关系；

所述第一服务器根据所述关联关系确定所述新版本子系统的安装文件在发版到所述生产系统时所遵循的发版顺序；

所述第一服务器将所得到的发版顺序传送到所述区块链上；

所述按照所述发版顺序将所述安装文件发版到所述生产系统包括：

从所述区块链上获取发版顺序，按照所述发版顺序将所述新版本子系统的安装文件发版到所述生产系统。

在其中一个实施例中，所述方法还包括：

当所述新版本子系统的测试结果表示所述新版本子系统通过测试，且所述新版本子系统的审批结果表示所述新版本子系统通过审批时，则所述第二服务器确定所述状态数据符合所述发版脚本中所设置的发版条件，执行所述获取与所述版本号对应的新版本子系统的安装文件的步骤。

在其中一个实施例中，所述方法还包括：

所述第一服务器将新版本子系统，以及所述新版本子系统版本相对上一版本所新增的功能项和/或所解决的问题上传到审批系统进行审批，获得审批结果；

所述第一服务器将所述审批结果实时传送到区块链上；或者，当所述审批结果表示所述新版本子系统审批通过时，将所述审批结果实时传送到区块链上；

当所述审批结果表示所述新版本子系统审批未通过时，所述第一服务器输出携带有审批意见的提示信息。

在其中一个实施例中，所述方法还包括：

所述第一服务器通过测试系统对所述新版本子系统进行测试，或者，通过测试系统对用于测试的生产系统进行测试，得到测试结果；所述用于测试的生产系统中的子系统根据所述新版本子系统进行了更新；

所述第一服务器将所述测试结果实时传送到区块链上；或者，当所述测试结果表示所述新版本子系统测试通过时，将测试结果实时传送到区块链上；

当所述测试结果表示所述新版本子系统测试未通过时，所述第一服务器输出携带有测试意见的提示信息。

在其中一个实施例中，所述方法还包括：

所述第一服务器实时收集所述生产系统在更新子系统后的用户反馈信息；所述用户反馈信息包括对生产系统的各功能所提出的改进意见和投诉信息；

所述第一服务器对收集的用户反馈信息按照对应的功能进行分类并输出。

一种基于区块链的应用程序发版系统，所述系统包括：第一服务器和第二服务器；其中，

所述第一服务器，用于将与生产系统中各子系统对应的新版本子系统的版本号和所述新版本子系统的状态数据发送至区块链；

所述第二服务器，用于从所述区块链上获取所述状态数据和所述版本号；

所述第二服务器还用于根据所述版本号判断是否对所述生产系统中的子系统进行升级；

所述第二服务器还用于当确定对所述生产系统中的子系统进行升级时，运行发版脚本，以获取与所述版本号对应的新版本子系统的安装文件，并确定各所述安装文件之间的发版顺序，按照所述发版顺序将所述安装文件发版到所述生产系统，根据所述安装文件对所述生产系统中对应的子系统进行更新；所述发版脚本中配置有用于判断状态数据是否符合要求的发版条件。

在其中一个实施例中，所述状态数据包括针对所述新版本子系统的测试结果和审批结果；

所述第一服务器还用于通过测试系统对所述新版本子系统进行测试得到测试结果，以及，通过审批系统对所述新版本子系统进行审批得到审批结果；

所述第一服务器还用于将所得到的测试结果、审批结果和所述新版本子系统的版本号传送到区块链上。

在其中一个实施例中，所述第一服务器还用于确定各所述新版本子系统之间的关联关系；

所述第一服务器还用于根据所述关联关系确定所述新版本子系统的安装文件在发版到所述生产系统时所遵循的发版顺序；

所述第一服务器还用于将所得到的发版顺序传送到所述区块链上；

所述第二服务器还用于从所述区块链上获取发版顺序，按照所述发版顺序将所述新版本子系统的安装文件发版到所述生产系统。

在其中一个实施例中，所述第二服务器还用于当所述新版本子系统的测试结果表示所述新版本子系统通过测试，且所述新版本子系统的审批结果表示所述新版本子系统通过审批时，则确定所述状态数据符合所述发版脚本中所设置的发版条件，执行所述获取与所述版本号对应的新版本子系统的安装文件的步骤。

在其中一个实施例中，所述第一服务器还用于将新版本子系统，以及所述新版本子系统版本相对上一版本所新增的功能项和/或所解决的问题上传到审批系统进行审批，获得审批结果；

所述第一服务器还用于将所述审批结果实时传送到区块链上；或者，当所述审批结果表示所述新版本子系统审批通过时，将所述审批结果实时传送到区块链上；

所述第一服务器还用于当所述审批结果表示所述新版本子系统审批未通过时，所述第一服务器输出携带有审批意见的提示信息。

在其中一个实施例中，所述第一服务器还用于通过测试系统对所述新版本子系统进行测试，或者，通过测试系统对用于测试的生产系统进行测试，得到测试结果；所述用于测试的生产系统中的子系统根据所述新版本子系统进行了更新；

所述第一服务器还用于将所述测试结果实时传送到区块链上；或者，当所述测试结果表示所述新版本子系统测试通过时，将测试结果实时传送到区块链上；

所述第一服务器还用于当所述测试结果表示所述新版本子系统测试未通过时，输出携带有测试意见的提示信息。

在其中一个实施例中，所述第一服务器还用于实时收集所述生产系统在更新子系统后的用户反馈信息；所述用户反馈信息包括对生产系统的各功能所提出的改进意见和投诉信息；

所述第一服务器还用于对收集的用户反馈信息按照对应的功能进行分类并输出。

上述基于区块链的应用程序发版方法和系统，第一服务器将与生产系统中各子系统对应的新版本子系统的版本号和所述新版本子系统的状态数据发送至区块链，可以将版本号和状态数据放在区块链上进行保存，不论是处于近端还是远端的第二服务器均可获取到相同的且未经篡改的版本号和状态数据，保证了数据的同步性和安全性。第二服务器从区块链上获取状态数据和版本号，根据版本号确定需要对生产系统中的子系统进行升级时，确定发版顺序，按照发版顺序将新版本子系统的安装文件发版到生产系统，以对生产系统中对应的子系统进行更新，避免了传统方案中由人工来控制发版操作，从而避免发版新版子系统时影响软件系统群的正常工作，提高发版效率。

附图说明

图1为一个实施例中基于区块链的应用程序发版方法的应用场景图；

图2为一个实施例中基于区块链的应用程序发版方法的流程示意图；

图3为一个实施例中测试和审批新版本子系统，将所得到的测试结果、审批结果和版本号传送到区块链上的步骤的流程示意图；

图4为另一个实施例中基于区块链的应用程序发版系统的结构框图；

图5为一个实施例中第一服务器的结构框图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

本申请提供的基于区块链的应用程序发版方法，可以应用于如图1所示的应用环境中。其中，第一服务器102与第二服务器104通过网络与区块链106进行连接。第一服务器将102与生产系统中各子系统对应的新版本子系统的版本号和新版本子系统的状态数据发送至区块链106，第二服务104器从区块链上获取与新版本子系统对应的状态数据和版本号；第二服务器104判断版本号是否满足对生产系统中的子系统进行升级的升级条件；当满足升级条件时，第二服务器104运行发版脚本，判断状态数据是否符合发版脚本中所设置的发版条件；若符合发版条件时，第二服务器104获取与版本号对应的新版本子系统，确定所获取的新版本子系统的发版顺序，按照发版顺序将新版本子系统的安装文件发版到生产系统，以对生产系统中对应的子系统进行更新。其中，服务器102和服务器104可以是同一个服务器集群中的服务器，也可以分别由多个服务器组成的服务器集群来实现。

在一个实施例中，如图2所示，提供了一种基于区块链的应用程序发版方法，该方法包括以下步骤：

S202，第一服务器将与生产系统中各子系统对应的新版本子系统的版本号和新版本子系统的状态数据发送至区块链。

其中，生产系统指的是软件系统，也即服务器侧的用于处理业务数据的应用程序。生产系统中的子系统指的是构成生产系统、且完成相应业务功能的子系统，在进行某个业务功能时，需要生产系统中的一个或多个子系统协同配合完成。新版本子系统指的是与生产系统中的子系统相对应的系统，该新版本子系统以独立模块的形式存在，并未更新到生产系统。当新版本子系统的版本号高于生产系统中子系统的版本号时，表示该新版本子系统是生产系统中子系统的新版本系统，可以使用该新版本子系统对生产系统中的子系统进行更新(如升级)。

其中，区块链具有共识机制，所有记账节点之间达成共识去认定一个记录的有效性，从而防止篡改的手段。具体来说，只有在控制了全网超过51％的记账节点的情况下，才有可能伪造出一条不存在的记录，由于加入区块链的节点足够多，基本上是不可能控制了全网超过51％的记账节点，从而杜绝了造假的可能。因此，将新版本子系统的版本号和对应的状态数据发送至区块链，从而不论是处于近端还是远端的第二服务器均可获取到相同的且未经篡改的版本号和状态数据，保证了数据的同步性和安全性。

在一个实施例中，第一服务器确定与生产系统中各子系统对应的新版本子系统，并获取该新版本子系统的版本号以及对应的状态数据，然后将获取到的版本号和状态数据发送至区块链上，以便区块链对版本号和状态数据进行维护。

在一个实施例中，状态数据可以包括新版本子系统的测试结果。第一服务器通过测试系统对新版本子系统进行测试，或者，通过测试系统对用于测试的生产系统进行测试，得到测试结果；第一服务器将测试结果实时传送到区块链上。或者，当测试结果表示新版本子系统测试通过时，第一服务器将测试结果实时传送到区块链上；当测试结果表示新版本子系统测试未通过时，第一服务器输出携带有测试意见的提示信息。

其中，测试结果包括测试通过和测试不通过两种结果，测试通过和不通过可以使用标志位进行标识，如测试通过可以用标志位Y1表示，测试不通过可以用N1表示。

在一个实施例中，第一服务器利用测试系统对所获取的新版本子系统单独进行测试；或者也可以先将新版本子系统更新到用于测试的生产系统中，然后对用于测试的生产系统进行测试，生成测试报告，测试报告中携带有测试结果。第一服务器从测试报告中提取测试结果，第一服务器将测试结果实时传送到区块链上；或者，当测试结果表示测试通过时，将测试结果实时传送到区块链上；当测试结果表示测试不通过时，则输出测试失败的提示信息。

在一个实施例中，状态数据可以包括新版本子系统的审批结果。第一服务器将新版本子系统，以及新版本子系统版本相对上一版本所新增的功能项和/或所解决的问题上传到审批系统进行审批，获得审批结果；第一服务器将审批结果实时传送到区块链上；或者，当审批结果表示新版本子系统审批通过时，将审批结果实时传送到区块链上；当审批结果表示新版本子系统审批未通过时，第一服务器输出携带有审批意见的提示信息。

其中，审批结果包括审批通过和审批不通过两种结果，审批通过可以用标志位Y2表示，审批不通过可以用N2表示。

例如，第一服务器将所获取的新版本子系统A，以及该新版本子系统A的第i个版本相对第i-1个版本所新增的功能项和/或克服的问题，上传到审批系统以便进行审批。在审批完成后，获取审批结果，当审批结果表示审批通过时，将审批结果实时传送到区块链上；当审批结果表示审批不通过时，则输出审批失败的提示信息以及对应的审批意见。

在一个实施例中，第一服务器还可以将测试结果以及测试报告上传到审批系统，与新版本子系统以及新版本子系统版本相对上一版本所新增的功能项和/或所解决的问题一起进行审批。

在一个实施例中，第一服务器将每个新版本子系统的安装文件及其测试系统的安装文件作为一个单位放在区块链上；此外，将审批系统的安装文件作为一个单位放到关联的区块链上，以便将信息同步到区块链上。因此，第二服务器可以按照版本号从区块链上获取新版本子系统的安装文件，然后进行后续的发版操作。

S204，第二服务器从区块链上获取状态数据和版本号。

在一个实施例中，状态数据包括测试结果和审批结果。第二服务器检测用于启动发版的触发事件，当检测到触发事件时，从区块链上获取与新版本子系统对应的测试结果、审批结果和版本号。其中，该触发事件可以是预设的发版时间，或者是由开发人员发起的发版请求。按照预设的发版时间触发的发版操作，这样可以避免在白天工作时间对新版本子系统进行发版，从而避免发版时影响正常的业务处理。

S206，第二服务器根据版本号判断是否对生产系统中的子系统进行升级。

具体地，当所获取的版本号高于生产系统中对应子系统的版本号时，表示新版本子系统的版本高于生产系统中对应子系统的版本，则生产系统中的子系统满足升级条件，即需要进行升级，然后执行S208。当所获取的版本号等于或低于生产系统中对应子系统的版本号时，表示新版本子系统的版本低于生产系统中对应子系统的版本，或与生产系统中对应子系统的版本一致，则生产系统中的子系统不满足升级条件，继续等待下一个触发事件，然后执行S204。

S208，当确定对生产系统中的子系统进行升级时，第二服务器运行发版脚本，以获取与版本号对应的新版本子系统的安装文件，并确定各安装文件之间的发版顺序，按照发版顺序将安装文件发版到生产系统，根据安装文件对生产系统中对应的子系统进行更新；发版脚本中配置有用于判断状态数据是否符合要求的发版条件。

其中，所述发版脚本中配置有用于判断状态数据是否符合要求的发版条件。

在一个实施例中，第二服务器运行发版脚本时，判断状态数据是否符合发版脚本中所设置的发版条件。

在一个实施例中，发版条件为：新版本子系统的测试结果为测试通过、且新版本子系统的审批结果为审批通过。当所获取的测试结果和审批结果符合发版条件时，则执行获取与版本号对应的新版本子系统的安装文件的步骤，以进行后续的发版操作。

在一个实施例中，新版本子系统的安装文件可以保存于区块链上，也可以保存于非区块链上，如将安装文件保存于普通的存储服务器。

在一个实施例中，第二服务器通过运行后的发版脚本，以便从区块链上获取与版本号对应的新版本子系统；或者，从存储生产系统的服务器中获取与版本号对应的新版本子系统。

生产系统中各子系统在处理业务时，在流程上可能会有先后顺序，例如，若要完成新业务A的处理时，需要先后流转到子系统a-d中进行处理，在发版新版本子系统时，若对处于流程后面的子系统d先进行更新，会对处于流程前面的子系统a、b和c的功能造成破坏。在一个实施例中，第一服务器可以预先确定新版本子系统的发版顺序，也即对应安装文件的发版顺序，然后将发版顺序发送到区块链。因此，确定各安装文件之间的发版顺序的步骤，具体可以包括：第二服务器从区块链上获取发版顺序，将获取的发版顺序确定为新版本子系统对应安装文件的发版顺序。

在一个实施例中，第二服务器中存储有注册信息，注册信息包括：生产系统中个子系统的版本号、发版时间以及当前版本相对上个版本所新增或克服的问题等。当按照获取的发版顺序将对应的安装文件发版到生产系统之后，服务器按照该安装文件更新存储的注册信息。

在一个实施例中，第一服务器实时收集生产系统在更新子系统后的用户反馈信息；用户反馈信息包括对生产系统的各功能所提出的改进意见和投诉信息；第一服务器对收集的用户反馈信息按照对应的功能进行分类并输出。

在一个实施例中，第一服务器实时收集生产系统在更新子系统后的用户反馈信息，并且对用户反馈信息进行分类整理。当用户反馈信息中针对业务系统的功能提出改进建议的数量较多时，将该改进建议进行输出，以提示开发人员按照改进建议开发新的新版本子系统。

作为一个示例，对于一个金融系统群有a、b、c、d和e五个子系统；为了支持新增业务，需要对其中的a、c、d和e四个子系统进行升级，由于它们升级的顺序是有要求的，发版顺序必须是a→c|d→e，如果不遵守此发版顺序，先升级后面的子系统e，会对流程前面的子系统a、c和d的功能造成破坏。因此，在对新版本子系统进行发版时，按照对应的发版顺序将新版本子系统发版到生产系统。

上述实施例中，第一服务器将与生产系统中各子系统对应的新版本子系统的版本号和所述新版本子系统的状态数据发送至区块链，可以将版本号和状态数据放在区块链上进行保存，不论是处于近端还是远端的第二服务器均可获取到相同的且未经篡改的版本号和状态数据，保证了数据的同步性和安全性。第二服务器从区块链上获取状态数据和版本号，根据版本号确定需要对生产系统中的子系统进行升级时，确定发版顺序，按照发版顺序将新版本子系统的安装文件发版到生产系统，以对生产系统中对应的子系统进行更新，避免了传统方案中由人工来控制发版操作，从而避免发版新版子系统时影响软件系统群的正常工作，提高发版效率。

在一个实施例中，如图3所示，状态数据包括针对新版本子系统的测试结果和审批结果；该方法还包括：

S302，第一服务器确定与生产系统中各子系统对应的新版本子系统和新版本子系统的版本号。

在一个实施例中，当开发人员开发出新版本子系统时，将新版本子系统进行保存和对应的版本号，以及相关数据进行保存，然后触发测试操作。第一服务器响应该发测试操作，从对应的存储器中获取与生产系统中各子系统对应的新版本子系统的安装文件，以及新版本子系统的版本号。

S304，第一服务器通过测试系统对新版本子系统进行测试得到测试结果，以及，通过审批系统对新版本子系统进行审批得到审批结果。

在一个实施例中，第一服务器利用测试系统对所获取的新版本子系统单独进行测试，或者也可以先将新版本子系统更新到用于测试的生产系统中，然后对用于测试的生产系统进行测试，生成测试报告，测试报告中携带有测试结果。第一服务器从测试报告中提取测试结果，当测试结果表示测试通过时，将测试结果实时传送到区块链上；当测试结果表示测试不通过时，则输出测试失败的提示信息。

在一个实施例中，第一服务器将新版本子系统，以及该新版本子系统版本相对上个版本所新增的功能项和/或克服的问题，上传到审批系统以便进行审批。在审批完成后，获取审批结果，当审批结果表示审批通过时，将审批结果实时传送到区块链上；当审批结果表示审批不通过时，则输出审批失败的提示信息以及审批意见。

S306，第一服务器将所得到的测试结果、审批结果和新版本子系统的版本号传送到区块链上。

在一个实施例中，第一服务器确定各新版本子系统之间的关联关系；第一服务器根据关联关系确定新版本子系统的安装文件在发版到生产系统时所遵循的发版顺序；第一服务器将所得到的发版顺序传送到区块链上，以便第二服务器从区块链上获取发版顺序，按照发版顺序将新版本子系统的安装文件发版到生产系统。

在一个实施例中，对于各新版本子系统之间的关联关系的确定，可以采用以下方法：第一服务器获取用于测试新版本子系统的业务数据，确定业务数据在生产系统中的各子系统之间的流转顺序。例如执行业务A时，若生产系统中的子系统a处理业务数据x1得到业务数据x2和业务数据x3，然后子系统b和子系统c分别处理业务数据x2和业务数据x3，处理完后并可完成业务A的处理。然后，第一服务器按照流转顺序来确定新版本子系统之间所存在的关联关系。

S308，第二服务器从区块链上获取与新版本子系统对应的测试结果、审批结果和版本号。

在一个实施例中，第二服务器检测用于启动发版的触发事件，当检测到触发事件时，从区块链上获取与新版本子系统对应的测试结果、审批结果和版本号。其中，该触发事件可以是预设的发版时间，或者是由开发人员发起的发版请求。按照预设的发版时间触发的发版操作，这样可以避免在白天工作时间对新版本子系统进行发版，从而避免发版时影响正常的业务处理。

S310，第二服务器根据版本号判断是否对生产系统中的子系统进行升级。

S312，当确定对子系统进行升级时，第二服务器运行发版脚本，判断测试结果、审批结果是否符合发版脚本中所设置的发版条件。

S314，若符合发版条件时，第二服务器获取与版本号对应新版本子系统的安装文件，确定该安装文件的发版顺序，按照发版顺序将安装文件发版到生产系统，以对生产系统中对应的子系统进行更新。

对于S310至S314的步骤可以参考上述S206至S208中的内容，这里不再进行赘述。

上述实施例中，将新版本子系统的测试结果和审批结果作为状态数据上传到区块链上，可以将测试结果和审批结果放在区块链上进行保存，不论是处于近端还是远端的第二服务器均可获取到相同的且未经篡改的测试结果和审批结果，保证了数据的同步性和安全性，同时也可以确保不论是远端还是近端的第二服务器均可以按照相同的测试结果和审批结果进行后续的发版操作。

应该理解的是，虽然图2-3的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图2-3中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中，如图4所示，提供了一种基于区块链的应用程序发版系统，包括：第一服务器410和第二服务器420；第一服务器410包括发送模块4102；第二服务器420包括获取模块4202、判断模块4204和发版模块4206；其中，

发送模块4102，用于将与生产系统中各子系统对应的新版本子系统的版本号和新版本子系统的状态数据发送至区块链；

获取模块4202，用于从区块链上获取与新版本子系统对应的状态数据和版本号；

判断模块4204，用于根据版本号判断是否对生产系统中的子系统进行升级；

发版模块4206，用于当确定对生产系统中的子系统进行升级时，第二服务器运行发版脚本，以获取与版本号对应的新版本子系统的安装文件，并确定各安装文件之间的发版顺序，按照发版顺序将安装文件发版到生产系统，根据安装文件对生产系统中对应的子系统进行更新；发版脚本中配置有用于判断状态数据是否符合要求的发版条件。

上述实施例中，第一服务器将与生产系统中各子系统对应的新版本子系统的版本号和新版本子系统的状态数据发送至区块链，可以将版本号和状态数据放在区块链上进行保存，不论是处于近端还是远端的第二服务器均可获取到相同的且未经篡改的版本号和状态数据，保证了数据的同步性和安全性。第二服务器从区块链上获取状态数据和版本号，根据版本号确定需要对生产系统中的子系统进行升级时，确定发版顺序，按照发版顺序将新版本子系统的安装文件发版到生产系统，以对生产系统中对应的子系统进行更新，避免了传统方案中由人工来控制发版操作，从而避免发版新版子系统时影响软件系统群的正常工作，提高发版效率。

在其中一个实施例中，状态数据包括针对新版本子系统的测试结果和审批结果；如图5所示，第一服务器410还可以包括：测试模块4104；其中，

测试模块4104，用于通过测试系统对新版本子系统进行测试得到测试结果，以及，通过审批系统对新版本子系统进行审批得到审批结果；

发送模块4102还用于将所得到的测试结果、审批结果和新版本子系统的版本号传送到区块链上。

在其中一个实施例中，如图5所示，第一服务器410还可以包括：发版顺序确定模块4106；其中，

发版顺序确定模块4106，用于确定各新版本子系统之间的关联关系；根据关联关系确定新版本子系统的安装文件在发版到生产系统时所遵循的发版顺序；

发送模块4102还用于将所得到的发版顺序传送到区块链上；

发版模块4206还用于从区块链上获取发版顺序，按照发版顺序将新版本子系统的安装文件发版到生产系统。

在其中一个实施例中，判断模块4204还用于当新版本子系统的测试结果表示新版本子系统通过测试，且新版本子系统的审批结果表示新版本子系统通过审批时，则确定状态数据符合发版脚本中所设置的发版条件，执行获取与版本号对应的新版本子系统的安装文件的步骤。

在其中一个实施例中，如图5所示，第一服务器410还可以包括：输出模块4108；其中，

测试模块4104还用于将新版本子系统，以及新版本子系统版本相对上一版本所新增的功能项和/或所解决的问题上传到审批系统进行审批，获得审批结果；

发送模块4102还用于将审批结果实时传送到区块链上；或者，当审批结果表示新版本子系统审批通过时，将审批结果实时传送到区块链上；

输出模块4108，用于当审批结果表示新版本子系统审批未通过时，第一服务器输出携带有审批意见的提示信息。

在其中一个实施例中，测试模块4104还用于通过测试系统对新版本子系统进行测试，或者，通过测试系统对用于测试的生产系统进行测试，得到测试结果；用于测试的生产系统中的子系统根据新版本子系统进行了更新；

发送模块4102还用于将测试结果实时传送到区块链上；或者，当测试结果表示新版本子系统测试通过时，将测试结果实时传送到区块链上；

输出模块4108还用于当测试结果表示新版本子系统测试未通过时，输出携带有测试意见的提示信息。

在其中一个实施例中，如图5所示，第一服务器410还可以包括：收集模块4110；其中，

收集模块4110，用于实时收集生产系统在更新子系统后的用户反馈信息；用户反馈信息包括对生产系统的各功能所提出的改进意见和投诉信息；

输出模块4108还用于对收集的用户反馈信息按照对应的功能进行分类并输出。

上述实施例中，将新版本子系统的测试结果和审批结果作为状态数据上传到区块链上，可以将测试结果和审批结果放在区块链上进行保存，不论是处于近端还是远端的第二服务器均可获取到相同的且未经篡改的测试结果和审批结果，保证了数据的同步性和安全性，同时也可以确保不论是远端还是近端的第二服务器均可以按照相同的测试结果和审批结果进行后续的发版操作。

本领域技术人员可以理解，图4、5中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种基于区块链的应用程序发版方法，所述方法包括：

第一服务器将与生产系统中各子系统对应的新版本子系统的版本号和所述新版本子系统的状态数据发送至区块链；

第二服务器从所述区块链上获取所述状态数据和所述版本号；

所述第二服务器根据所述版本号判断是否对所述生产系统中的子系统进行升级；

当确定对所述生产系统中的子系统进行升级时，所述第二服务器运行发版脚本，以获取与所述版本号对应的新版本子系统的安装文件，并确定各所述安装文件之间的发版顺序，按照所述发版顺序将所述安装文件发版到所述生产系统，根据所述安装文件对所述生产系统中对应的子系统进行更新；所述发版脚本中配置有用于判断状态数据是否符合要求的发版条件。

2.根据权利要求1所述的方法，其特征在于，所述状态数据包括针对所述新版本子系统的测试结果和审批结果；所述方法还包括：

所述第一服务器通过测试系统对所述新版本子系统进行测试得到测试结果，以及，通过审批系统对所述新版本子系统进行审批得到审批结果；

所述第一服务器将所得到的测试结果、审批结果和所述新版本子系统的版本号传送到区块链上。

3.根据权利要求2所述的方法，其特征在于，所述方法还包括：

所述第一服务器确定各所述新版本子系统之间的关联关系；

所述第一服务器根据所述关联关系确定所述新版本子系统的安装文件在发版到所述生产系统时所遵循的发版顺序；

所述第一服务器将所得到的发版顺序传送到所述区块链上；

所述按照所述发版顺序将所述安装文件发版到所述生产系统包括：

从所述区块链上获取发版顺序，按照所述发版顺序将所述新版本子系统的安装文件发版到所述生产系统。

4.根据权利要求2所述的方法，其特征在于，所述方法还包括：

当所述新版本子系统的测试结果表示所述新版本子系统通过测试，且所述新版本子系统的审批结果表示所述新版本子系统通过审批时，则所述第二服务器确定所述状态数据符合所述发版脚本中所设置的发版条件，执行所述获取与所述版本号对应的新版本子系统的安装文件的步骤。

5.根据权利要求1所述的方法，其特征在于，所述方法还包括：

所述第一服务器将新版本子系统，以及所述新版本子系统版本相对上一版本所新增的功能项和/或所解决的问题上传到审批系统进行审批，获得审批结果；

所述第一服务器将所述审批结果实时传送到区块链上；或者，当所述审批结果表示所述新版本子系统审批通过时，将所述审批结果实时传送到区块链上；

当所述审批结果表示所述新版本子系统审批未通过时，所述第一服务器输出携带有审批意见的提示信息。

6.根据权利要求1所述的方法，其特征在于，所述方法还包括：

所述第一服务器通过测试系统对所述新版本子系统进行测试，或者，通过测试系统对用于测试的生产系统进行测试，得到测试结果；所述用于测试的生产系统中的子系统根据所述新版本子系统进行了更新；

所述第一服务器将所述测试结果实时传送到区块链上；或者，当所述测试结果表示所述新版本子系统测试通过时，将测试结果实时传送到区块链上；

当所述测试结果表示所述新版本子系统测试未通过时，所述第一服务器输出携带有测试意见的提示信息。

7.根据权利要求1至6任一项所述的方法，其特征在于，所述方法还包括：

所述第一服务器实时收集所述生产系统在更新子系统后的用户反馈信息；所述用户反馈信息包括对生产系统的各功能所提出的改进意见和投诉信息；

所述第一服务器对收集的用户反馈信息按照对应的功能进行分类并输出。

8.一种基于区块链的应用程序发版系统，其特征在于，所述系统包括：第一服务器和第二服务器；其中，

所述第一服务器，用于第一服务器将与生产系统中各子系统对应的新版本子系统的版本号和所述新版本子系统的状态数据发送至区块链；

所述第二服务器，用于从所述区块链上获取与所述新版本子系统对应的所述状态数据和所述版本号；

所述第二服务器还用于根据所述版本号判断是否对所述生产系统中的子系统进行升级；

所述第二服务器还用于当确定对所述生产系统中的子系统进行升级时，所述第二服务器运行发版脚本，以获取与所述版本号对应的新版本子系统的安装文件，并确定各所述安装文件之间的发版顺序，按照所述发版顺序将所述安装文件发版到所述生产系统，根据所述安装文件对所述生产系统中对应的子系统进行更新；所述发版脚本中配置有用于判断状态数据是否符合要求的发版条件。

9.根据权利要求8所述的系统，其特征在于，所述状态数据包括针对所述新版本子系统的测试结果和审批结果；

所述第一服务器还用于通过测试系统对所述新版本子系统进行测试得到测试结果，以及，通过审批系统对所述新版本子系统进行审批得到审批结果；

所述第一服务器还用于将所得到的测试结果、审批结果和所述新版本子系统的版本号传送到区块链上。

10.根据权利要求9所述的系统，其特征在于，所述第一服务器还用于确定各所述新版本子系统之间的关联关系；

所述第一服务器还用于根据所述关联关系确定所述新版本子系统的安装文件在发版到所述生产系统时所遵循的发版顺序；

所述第一服务器还用于将所得到的发版顺序传送到所述区块链上；

所述第二服务器还用于从所述区块链上获取发版顺序，按照所述发版顺序将所述新版本子系统的安装文件发版到所述生产系统。