CN112230985B - 静态文件流程、小程序版本管理方法、装置及计算机设备 - Google Patents

静态文件流程、小程序版本管理方法、装置及计算机设备 Download PDF

Info

Publication number
CN112230985B
CN112230985B CN202011153227.1A CN202011153227A CN112230985B CN 112230985 B CN112230985 B CN 112230985B CN 202011153227 A CN202011153227 A CN 202011153227A CN 112230985 B CN112230985 B CN 112230985B
Authority
CN
China
Prior art keywords
static
version
applet
stage
static file
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202011153227.1A
Other languages
English (en)
Other versions
CN112230985A (zh
Inventor
赵熙明
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Weimin Insurance Agency Co Ltd
Original Assignee
Weimin Insurance Agency Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Weimin Insurance Agency Co Ltd filed Critical Weimin Insurance Agency Co Ltd
Priority to CN202011153227.1A priority Critical patent/CN112230985B/zh
Publication of CN112230985A publication Critical patent/CN112230985A/zh
Application granted granted Critical
Publication of CN112230985B publication Critical patent/CN112230985B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/368—Test management for test version control, e.g. updating test cases to a new software version
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/16—File or folder operations, e.g. details of user interfaces specifically adapted to file systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Human Computer Interaction (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本申请实施例涉及一种静态文件流程、小程序版本管理方法、装置及计算机设备，该方法包括：获取静态文件在第一阶段已被调整的通知消息，其中，通知消息包括与第一阶段对应的静态文件调整动态；根据调整动态，分别对预构建的数据库以及云服务器中存在的，且与第一阶段对应的静态文件进行调整。整个调整过程中，都是根据静态文件调整动态完成自动调整。包括对于静态文件的上传、修改和删除等调整过程。通过该方式，省略工作人员手动上传静态文件的流程，提升工作效率，同时也避免了由于手动上传静态文件所带来的潜在线上问题。

Description

静态文件流程、小程序版本管理方法、装置及计算机设备
技术领域
本申请实施例涉及计算机技术领域，尤其涉及一种静态文件流程、小程序版本管理方法、装置及计算机设备。
背景技术
现有技术中，在开发阶段进行产品迭代时，会将小程序使用的静态文件手动传输到分布式静态资源内容存储服务器上的开发（development，简称DEV）目录，同时本地保留一份静态文件。当开发完成后，需要给测试人员测试，发布系统整合测试（SystemIntegrate Test，简称SIT）环境时，需要测试人员手动将本地此次迭代使用的静态文件再向分布式静态资源内容存储服务器的SIT目录上传一份。以此类推，在发布用户验收测试（User Acceptance Test，简称UAT）阶段、产品正式生产阶段（production，简称PRD）阶段，都需要手动上传第i阶段对应的静态文件至分布式静态资源内容存储服务器的相应目录中。具体参见图1所示，图1示出了现有技术中通过手动上传静态文件的操作过程示意图。
在该过程中，开发人员需要至少4次手动上传静态文件，流程复杂，效率低下，还容易存在潜在的线上问题。
发明内容
鉴于此，为解决现有技术中上述技术问题，本申请实施例提供一种静态文件流程、小程序版本管理方法、装置及计算机设备。
本申请实施例提供一种静态文件流程管理方法，该方法包括：
获取静态文件在第一阶段已被调整的通知消息，其中，通知消息包括与第一阶段对应的静态文件调整动态；
根据调整动态，分别对预构建的数据库以及云服务器中存在的，且与第一阶段对应的静态文件进行调整，其中，第一阶段为小程序从开发到发布过程中的任一个阶段。
本申请实施例提供一种小程序版本管理方法，该方法包括：
获取第n版本小程序进入发布阶段的通知指令；
根据通知指令，从预构建的数据库中，获取与第n版本小程序对应的静态文件，静态文件为与发布阶段对应的静态文件；
当第n版本小程序为初始版本小程序时，直接建立第n版本小程序与第n版本小程序对应的静态文件之间的绑定关系；
或，当第n版本小程序并非为初始版本小程序，且n大于预设阈值时，将第n版本小程序对应的静态文件与最低版本静态文件夹中的静态文件进行对比，获取区别内容，最低版本静态文件夹为云服务器中存储的至少一个静态文件夹中的一个；
将区别内容同步至最低版本静态文件夹中的静态文件中，并建立第n版本小程序与最低版本静态文件夹中经修改后的静态文件之间的绑定关系，其中n为正整数。
本申请实施例提供一种静态文件流程管理装置，该装置包括：
获取单元，用于获取静态文件在第一阶段已被调整的通知消息，其中，通知消息包括与第一阶段对应的静态文件调整动态；
处理单元，用于根据调整动态，分别对预构建的数据库以及云服务器中存在的，且与第一阶段对应的静态文件进行调整，其中，第一阶段为小程序从开发到发布过程中的任一个阶段。
本申请实施例提供一种小程序版本管理装置，该装置包括：
获取单元，用于获取第n版本小程序进入发布阶段的通知指令；根据通知指令，从预构建的数据库中，获取与第n版本小程序对应的静态文件，静态文件为与发布阶段对应的静态文件；
比较单元，用于当第n版本小程序为初始版本小程序时，直接建立第n版本小程序与第n版本小程序对应的静态文件之间的绑定关系；
或，当第n版本小程序并非为初始版本小程序，且n大于预设阈值时，将第n版本小程序对应的静态文件与最低版本静态文件夹中的静态文件进行对比，获取区别内容，最低版本静态文件夹为云服务器中存储的至少一个静态文件夹中的一个；
处理单元，用于将区别内容同步至最低版本静态文件夹中的静态文件中，并建立第n版本小程序与最低版本静态文件夹中经修改后的静态文件之间的绑定关系，其中n为正整数。
本申请实施例提供一种计算机设备，该计算机设备包括：至少一个处理器和存储器；
处理器用于执行存储器中存储的静态文件管理程序，以实现如上任一实施方式所介绍的静态文件管理方法；或者，处理器用于执行存储器中存储的小程序版本管理程序，以实现如上任一实施方式所介绍的小程序版本管理方法。
本申请实施例提供一种计算机存储介质，该计算机存储介质存储有一个或者多个程序，一个或者多个程序可被计算机设备执行，以实现如上任一实施方式所介绍的静态文件管理方法；或者，以实现如上任一实施方式所介绍的小程序版本管理方法。
本申请实施例提供的一种静态文件流程管理方法，首先获取静态文件在第一阶段已被调整的通知消息。根据通知消息，获取与第一阶段对应的静态文件调整动态，进而根据调整动态，分别对预构建的数据库以及云服务器中存在的，且与第一阶段对应的静态文件进行调整。整个调整过程中，都是根据静态文件调整动态完成自动调整。包括对于静态文件的上传、修改和删除等调整过程。通过该方式，省略工作人员手动上传静态文件的流程，提升工作效率，同时也避免了由于手动上传静态文件所带来的潜在线上问题。
本申请实施例提供的一种小程序版本管理方法，当第n版本小程序进入发布阶段，就说明第n版本小程序对应的静态文件已采用如第一方面所介绍的静态文件管理方法完成在发布阶段之前的所有阶段的静态文件管理操作。此后，建立每一个版本小程序和对应版本静态文件之间的绑定关系。由此实现不论发布哪个版本静态文件时，都会自动上传至云服务器中与该版本小程序对应的静态文件夹中。不会再发生新版本的静态文件强制覆盖旧版本静态文件，并展示给用户查看的情况。当n大于预设阈值时，建立第n版本小程序与最低版本静态文件夹中经修改后的静态文件之间的绑定关系，是为了控制云服务器文件夹数量，使得固定数量的文件夹中的静态文件循环更新，以此实现节省存储空间，以及减少每次发版所要同步文件的数量。而且，每次更新的内容也仅仅是当前版本静态文件和最低版本静态文件之间的区别内容，而相同内容则不再重复上传，以提升工作效率，达到负载均衡。
附图说明
图1为现有技术中手动上传静态文件的操作过程示意图；
图2为本申请实施例提供的一种静态文件流程管理方法流程示意图；
图3为本申请提供的静态文件调整流程示意图；
图4为本申请提供的验收阶段同步至发布阶段的示意框图；
图5为本申请提供静态文件单个子文件，或全部子文件进行替换的示意图；
图6为本申请提供的一种小程序版本管理方法流程示意图；
图7为本申请实施例提供的应用于小程序发布场景中，利用验收阶段的静态文件替换最低小程序版本静态文件的流程示意图；
图8为本申请实施例提供的一种静态文件流程管理装置结构示意图；
图9为本申请实施例提供的一种小程序版本管理装置结构示意图；
图10为本申请实施例提供一种计算机设备结构示意图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
为便于对本申请实施例的理解，下面将结合附图以具体实施例做进一步的解释说明，实施例并不构成对本申请实施例的限定。
图2为本申请实施例提供的一种静态文件流程管理方法流程示意图。在介绍本申请实施例提供的静态文件管理方法流程之前，首先介绍本申请实施例所应用的系统架构中存在各执行主体以及各自对应的功能。
在系统架构中，包括各个阶段测试环境对应的系统，例如静态文件流程管理阶段可以包括开发阶段DEV、测试阶段SIT、验收阶段UAT以及发布阶段PRD。不同的阶段，都有不同的测试环境对该阶段的小程序进行测试。比如，在开发阶段，工作人员对小程序进行测试，如果没有问题，那么进入测试阶段，如果有问题，调整后，再进入测试阶段。在测试阶段进一步对小程序进行测试。类似道理，一步步进入验收阶段以及最终的发布阶段。
系统架构中还包括：发布小程序的工具或者是承载最终小程序的平台，例如微信平台。用于发布小程序最终版本，该平台也可以存在回退按钮，当小程序发布后的版本存在问题时，可以一键回退。
系统架构中还包括分布式版本控制系统Git以及Node服务器。具体的，工作人员可以事先配置静态文件分布式版本控制系统Git，然后利用Git hook（能在Git特定的重要动作发生时触发的自定义脚本）与Node服务器进行关联。
Git用于存储程序代码和工作人员在不同阶段上传的静态文件。程序代码，就是上文所提及的工作人员在不同阶段测试小程序的程序代码。
在每一个阶段测试成功后，相应阶段的静态文件都会上传至Git。如果新增或者修改，也会上传至Git。
Git检测到某个阶段的静态文件包括新增（例如，增加某个图片，或在该阶段上传静态文件等都可以理解为新增操作）、修改和删除等操作后，会告知Node服务器在该阶段有新增、修改或删除的动作，并告知在静态文件中的具体调整位置。
上述操作后，Node服务器会获取到静态文件在不同阶段的调整动态，以便根据调整动态做出具体调整操作。也即是本申请中在下文将要介绍的静态文件管理方法流程，具体参见如下：
如图2所示，该方法包括：
步骤310，获取静态文件在第一阶段已被调整的通知消息。
具体的，静态文件发布至任意阶段后，Git都会以通知消息的形式告知Node服务器。其中，通知消息包括与第一阶段对应的静态文件调整动态。
具体的，调整动态就可以包括调整操作和调整位置等。例如，调整操作包括新增、修改和删除等。具体的调整位置，例如可以是静态文件中的文本内容中的某个位置，而也可以是静态文件中的某个图片等。
步骤320，根据调整动态，分别对预构建的数据库以及云服务器中存在的，且与第一阶段对应的静态文件进行调整。
具体的，如上所介绍的，因为小程序从开发到发布至少包括4个阶段。针对每个阶段，实际上都会有一份静态文件。例如，在开发阶段测试成功后，有一份静态文件1-1。这份静态文件会被存储至Node服务器中预构建的数据库对应该阶段的静态文件夹中。Node服务器也会将静态文件1-1上传至云服务器，由云服务器存储至云服务器中预先构建的对应阶段的静态文件夹中。然后，在SIT阶段，相应工作人员会对小程序进行进一步测试，并调取Node服务器预构建的数据库中的静态文件1-1，基于测试阶段的小程序，根据实际需求对静态文件1-1做出适应性调整（当然，也可能不做任何调整）。为与静态文件1-1进行区别，这里将其命名为静态文件1-2。工作人员会将静态文件1-2上传至Git中。Git会以通知消息的形式告知Node服务器，然后由Node服务器获取到静态文件1-2后，存储至Node服务器的数据库中与SIT阶段对应的静态文件夹。并将静态文件1-2上传至云服务器，由云服务器存储至云存储服务器中预先构建的对应阶段（SIT）的静态文件夹。以此类推，其他阶段首次上传的静态文件也会按照类似原理存储至Node服务器中的数据库，以及云服务器中的数据库。
需要说明的是，工作人员会事先在Node服务器的数据库中构建与不同阶段对应的文件夹，以便后续将不同阶段的静态文件存储到Node服务器中对应的文件夹。类似道理，云服务器中也是会事先构建不同阶段分别对应的文件夹。以便后续将不同阶段的静态文件存储到云服务器中对应的文件夹。
在上述操作过程中，工作人员不再需要手动上传静态文件至Node服务器中的数据库以及云服务器。而是，Node服务器获取Git通知消息后，自动从Git中获取静态文件，存储至数据库，以及云服务器中。减少工作人员手动上传环节，避免工作人员在手动上传过程存在遗漏等问题，比如忘记上传，或者传错静态文件等。
在上文介绍的内容是以首次上传静态文件为例进行说明的。即，第一阶段为小程序从开发到发布过程中任一个阶段的首次上传静态文件，Node服务器都会获取到通知消息。并且可以根据通知消息获取到静态文件的调整动态，即新增静态文件。然后，根据调整动态，分别对预构建的数据库以及云服务器中存在的，与第一阶段对应的静态文件进行调整。
实际上，除了首次上传静态文件作为新增操作以外，还可以包括其他调整操作，例如删除当前阶段静态文件中的某个图片，或者对静态文件中的内容进行修改。
在一个具体的例子中，假设当前阶段为SIT阶段，工作人员在线下对静态文件中的图片进行了删除操作。那么，Git检测到工作人员对于静态文件的删除操作后，会以通知消息的形式告知Node服务器。并且告知当前对于静态文件的操作包括对XX位置的图片进行删除。Node服务器收到Git通知后，会相应修改自身数据库中存储的静态文件。同时，也会对应修改云服务器中在该阶段对应的静态文件。
进一步的，如果上文所介绍的第一阶段并非为起始阶段，例如并非是开发阶段。那么，在其他阶段对静态文件进行动态调整后，调整内容仅仅会在当前阶段的静态文件中体现，以及在当前阶段之后的静态文件中体现（后一个阶段静态文件都是在前一个阶段静态文件基础上做调整）。那么，就会存在一些特殊情况，比如下一次在当前阶段之前的某一个阶段对静态文件进行了调整。调整后的静态文件中并不会涵盖到本次调整的内容。那么，此次调整将会失效。
为更加让读者理解，这里举一个具体的例子。比如，前一次调整的是测试阶段的静态文件，调整内容为对静态文件中的删除一个图片A。前一次调整并没有同步到开发阶段，所以开发阶段的静态文件依然是原始静态文件，即仍然包含有该图片A的静态文件。
本次修改的是开发阶段，是对开发阶段静态文件中的文本内容进行了修改。本次修改后，Git会通知Node服务器。Node服务器会自动执行上文所介绍的操作流程，同步修改Node服务器数据库中的开发阶段对应的静态文件夹中的静态文件和云服务器中的开发阶段对应的静态文件夹中的静态文件。在测试阶段，会直接调取Node服务器数据库中的开发阶段的静态文件，覆盖掉之前存储在测试阶段的静态文件（默认设置最后获取的就是最新的），并以此为基础进行测试。在测试阶段会调取的是包含有图片A的静态文件。即，前一次对于测试阶段的静态文件的调整已经被覆盖掉，也可以理解为修改失效。
以解决上述中存在的问题，因此，当第一阶段为非起始阶段时，根据调整动态，分别对预构建的数据库以及云服务器中存在的，且与第一阶段对应的静态文件进行调整之后，该方法还包括：
确定第一阶段之前存在的第i个阶段，根据调整动态，分别对预构建的数据库以及云服务器中存在的，且与第i个阶段对应的静态文件进行调整；
直至第i个阶段为起始阶段，根据调整动态，对预构建的数据库以及云服务器中存在的，且与起始阶段对应的静态文件进行调整后，停止调整操作，其中，i为大于或等于2的正整数。
具体的调整过程参见图3所示，即所有阶段静态文件调整都可以参照图3的示意图，当Git提交通知消息到Node服务器后，none服务器就会从通知消息中获取调整动态，进而根据调整动态调整数据库的对应阶段的静态文件夹中的静态文件，以及调整云服务器中对应阶段静态文件夹中的静态文件。图3中以腾讯云为例进行说明。不论上传成功或失败，都可以告知开发者，例如图3中以企业文件形式通知开发者。
在当前阶段调整静态文件完成后，还需要考虑是否存在相较于当前阶段更低的一层环境，也即是如过当前阶段为第i阶段，那么则需要判断是否存在第i-1个阶段，如果存在低环境静态文件，则根据调整动态，进一步调整第i-1阶段的静态文件，包括Node服务器的预构建的数据库中的静态文件，以及云服务器中的静态文件。重复执行上述过程，直至初始阶段的静态文件也按照上述方式调整完成后，结束调整操作。
进一步可选的，当静态文件包括多个子文件，根据调整动态，对静态文件进行调整，包括以下至少一种操作：
根据调整状态，对多个子文件中的部分或全部子文件同步调整操作；
或者，
根据调整动态，对多个子文件中的单个子文件调整操作。
基于单个还是多个同步，是考虑实际情况中需要对单个执行调整操作，还是需要对多个进行调整操作。如果是多个，那么在提升工作效率的前提下，可以同步调整操作。
具体参见图4和图5所示，图4为本申请提供的验收阶段同步至发布阶段的示意框图。
即，当在UAT阶段到PRD阶段，中间需要替换某个项目例如LH02中的图片时，本申请实施例中提供一可视化页面，可视化页面显示多个项目对应的相关内容，例如，当前界面显示的是标题栏包括项目和操作。项目内容包括项目名称。可视化界面显示的内容还包括功能控件，如图4中“查看”，可以通过点击项目LH02对应的功能控件“查看”后，后台自动对比当前UAT阶段更新的后的文件和PRD阶段的文件之间的区别，及时对比出在UAT阶段已更新的图片，进而方便后续将最新图片替换掉PRD中的图片。
图5为本申请实施例提供的另一可视化界面，当触发图4中的查看操作后，所展现的示意图。具体参见图5所示，其示意出对存在差异性的子文件进行替换的过程，可以全部替换，也可以每次单独替换一个子文件。该示意图中除展示图4中的部分项目名称（未被覆盖的）以外，还展示了包括项目LH02被点击查看后，后台对比出存在差异的图片包括多张，以及功能控件“全部发布”和“单个发布”。通过功能控件，可实现手动触发全部发布（替换），也可以选择单个发布（替换）。具体参见图5所示，这里不再过多赘述。
需要说明的是，上文中，因为应用场景是基于开发人员使用，所以采用Git与node服务器进行关联，以实现Git提交后，node服务器可以自动上传至云服务器。实际上，如果并非是基于开发人员使用，那么Git也可以替换为其他方式。例如采用web页面形式。即通过web页面与node服务器进行关联。当用户通过web页面上传某些静态文件后，告知Node服务器在该阶段有新增、修改或删除的动作，并告知在静态文件中的具体调整位置。
本申请实施例提供的静态文件流程管理方法，首先获取静态文件在第一阶段已被调整的通知消息。根据通知消息，获取与第一阶段对应的静态文件调整动态，进而根据调整动态，分别对预构建的数据库以及云服务器中存在的，且与第一阶段对应的静态文件进行调整。整个调整过程中，都是根据静态文件调整动态完成自动调整。包括对于静态文件的上传、修改和删除等调整过程。通过该方式，省略工作人员手动上传静态文件的流程，提升工作效率，同时也避免了由于手动上传静态文件所带来的潜在线上问题。
修改当前阶段后，还会同步修改当前阶段之前的所有阶段中的静态文件，以避免下次修改当前阶段的之前任一阶段的静态文件时，因为本次修改没有同步静态文件，导致下次修改并非是在本次修改静态文件基础上做出调整所带来的弊端。
下文中，将会考虑到当静态文件上传到云端服务器后，例如上传至云服务，但是每次最新的上传静态文件都将覆盖之前存储的旧的静态文件。而因为云服务器中静态文件一旦更新，都将对外界有效，也即是可以被用户看到。
举一个具体的例子，例如某种产品，当前版本定价为100元。后续为了搞促销活动，重新上传一个版本静态文件，商品定价为10元，新的小程序版本还没有发布。仅仅是静态文件版本覆盖了旧的静态文件版本。
即，静态文件版本没有和小程序版本之间建立绑定关系，用户看到静态文件上的定价后，点击原有小程序版本进入商品页面下单后，发现定价依然为100元，导致小程序中的数据修改不同步，同时还存在一个弊端就是当希望追回之前旧版本静态文件时，因为旧版本静态文件已经被覆盖，很难被追回。即，小程序有版本机制控制，云服务器的静态文件缺少版本机制，云服务器中存储的永远都是最新上传版本。因此，当小程序回退到旧版本小程序时，云服务器中的旧版本对应的静态文件很难被追回。
因此，为解决上述问题，本申请还提供了一种小程序版本管理方法。具体参见图6所示，该方法可以包括：
步骤710，获取第n版本小程序进入发布阶段的通知指令。
具体的，参见上文所介绍的系统架构中，发布小程序的工具或者是承载最终小程序的平台，例如微信平台。用于发布小程序最终版本，实际上发布小程序的工具（或是平台）与Node服务器之间会通过预设定的接口建立通信关系。当发布小程序的工具（或平台）发布每一个版本小程序后，都会以通知指令形式告知Node服务器。例如，告知Node服务器当前发布小程序版本对应的标识信息，标识信息用于指示当前小程序的版本，例如标识信息可以是小程序版本号。
步骤720，根据通知指令，从预构建的数据库中，获取与第n版本小程序对应的静态文件。
其中，静态文件为与发布阶段对应的静态文件。
可选的，通知指令中包括第n版本小程序对应的标识信息；根据通知指令，从预构建的数据库中，获取与第n版本小程序对应的静态文件，具体包括：
从数据库中提取与标识信息对应的静态文件，其中，n为正整数。
步骤730，当第n版本小程序为初始版本小程序时，直接建立第n版本小程序与第n版本小程序对应的静态文件之间的绑定关系。
具体的，如果当前获取的第n版本小程序版本是第一版本小程序。那么，直接建立第一版本小程序与该版本对应的静态文件之间的绑定关系即可。
但是，当第n版本小程序并非为初始版本小程序，且n大于预设阈值时，则需要执行步骤740至步骤750。
步骤740，当第n版本小程序并非为初始版本小程序，且n大于预设阈值时，将第n版本小程序对应的静态文件与最低版本静态文件夹中的静态文件进行对比，获取区别内容。
其中，最低版本静态文件夹为云服务器中存储的至少一个静态文件夹中的一个，n为正整数。
步骤750，将区别内容同步至最低版本静态文件夹中的静态文件中，并建立第n版本小程序与最低版本静态文件夹中经修改后的静态文件之间的绑定关系。
通过该种方式，只要云服务器中当前使用的程序版本不发生改变，其对应的静态文件就不会发生变动。因此，CDN对于外部发布的静态文件不会随着内部静态文件的频繁变动而发生变动。
执行上述步骤的目的在于，通过该种方式控制云服务器文件夹数量，使得固定数量的文件夹中的静态文件循环更新，以此实现节省存储空间，以及减少每次发版所要同步文件的数量。而且，每次更新的内容也仅仅是当前版本静态文件和最低版本静态文件之间的区别内容，而相同内容则不再重复上传，以提升工作效率，达到负载均衡。
具体参见图7，图7示意出了发布小程序后，当当前阶段为PRD阶段时，利用UAT阶段的静态文件替换最低小程序版本静态文件的流程示意图。
具体参见图7所示，其操作流程包括：发布小程序，Node服务获取小程序版本，判断当前阶段是否为PRD阶段。如果是，则获取最低版本静态文件夹中的静态文件，然后Git拉取UAT环境的静态文件，将UAT环境的静态文件与最低版本静态文件夹中的静态文件进行对比，获取区别内容。然后，将区别内容同步至最低版本静态文件夹中的静态文件中。并修改配置文件对应关系。即，建立第n版本小程序与经修改后的最低版本静态文件夹之间的绑定关系。
这里需要说明的是，最低版本静态文件夹的识别可以包括如下两种情况，首先，如果云服务器中存在预构建的与发布阶段对应的空文件夹，那么空文件夹即为最低版本静态文件夹，实际上，当第n版本小程序为初始版本小程序的情况，就是最低版本静态文件夹为空文件夹的情况，所以可以直接和与之对应的静态文件之间建立绑定关系。如果不存在空文件夹，则识别与最低版本小程序绑定的静态文件夹为最低版本静态文件夹。而识别最低版本小程序，则可以根据与小程序版本对应的标识信息进行识别。
考虑到云服务器中的空间占用问题，可以限定与发布的小程序版本对应的静态文件夹的数量。比如，静态文件夹的数量只能为10个，可以预先构建10个空的静态文件夹，然后每发布一个版本小程序，则将对应的静态文件存储到一个空的静态文件夹中，并建立这个静态文件和小程序版本之间的绑定关系。
当静态文件夹已经被占用满时，则将新的小程序版本对应的静态文件和当前最低版本静态文件夹中的静态文件进行对比，获取区别内容，然后同步至最低版本静态文件夹中的静态文件中。建立新的小程序版本和经过修改后的静态文件之间的绑定关系。
即，从至少一个静态文件夹中识别出最低版本静态文件夹，具体包括：
在第一静态文件夹未与任一小程序版本之间存在绑定关系（第一静态文件夹为空文件夹）时，确定第一静态文件夹为最低版本静态文件夹，其中，第一静态文件夹为至少一个静态文件夹中的一个。
或者，在至少一个静态文件夹中每一个静态文件夹均与一个小程序版本之间建立绑定关系时，则确定与最低小程序版本之间建立绑定关系的静态文件所在的第二静态文件夹为最低版本静态文件夹，其中，第一静态文件夹，以及第二静态文件夹均为至少一个静态文件夹中的任一个静态文件夹；识别最低小程序版本可以根据标识信息确定，例如最低小程序版本为版本号最小的小程序版本。
进一步的，若当前阶段并非为PRD阶段，则执行的是图3的流程。即，Git拉取低环境静态文件，利用当前版本静态文件替换掉低环境静态文件。或者获取区别，利用区别修改低环境的静态文件。然后出发Git提交流程，进一步判断是否存在更低环境。具体操作流程参见图3，这里不再过多赘述。
本申请提供的一种小程序版本管理方法，当第n版本小程序进入发布阶段，就说明第n版本小程序对应的静态文件已采用如第一方面所介绍的静态文件管理方法完成在发布阶段之前的所有阶段的静态文件管理操作。此后，建立每一个版本小程序和对应版本静态文件之间的绑定关系。由此实现不论发布哪个版本静态文件时，都会自动上传至云服务器中与该版本小程序对应的静态文件夹中。不会再发生新版本的静态文件强制覆盖旧版本静态文件，并展示给用户查看的情况。即，不同小程序版本关联了与之对应的静态文件的版本，所以在小程序正式上线前的测试阶段，将不会把静态文件提前发布到上线。降低了提前发布静态文件的风险，及提高了用户在线上环境使用的体验。
当n大于预设阈值时，建立第n版本小程序与最低版本静态文件夹中经修改后的静态文件之间的绑定关系，是为了控制云服务器文件夹数量，使得固定数量的文件夹中的静态文件循环更新，以此实现节省存储空间，以及减少每次发版所要同步文件的数量。而且，每次更新的内容也仅仅是当前版本静态文件和最低版本静态文件之间的区别内容，而相同内容则不再重复上传，以提升工作效率，达到负载均衡。
为了更加具体的说明书上述实施例的内容，本发明提供一个结合静态文件管理方法和小程序版本管理方法的应用实例，具体参见如下：假设与node服务器进行关联的是Git。使用Git hook与node服务器建立服务关联。基于Git hook触发后台服务。使用node服务器作为后台管理，主要提供腾讯云服务器文件管理，Git文件冲突解决（包括新增、修改、删除、替换等）、建立静态文件版本及小程序版本的关联与管理。微信小程序则基于node服务器生成的配置文件查找对应小程序版本的静态资源，实现二者的版本关联及回退。
具体执行时，开发人员在DEV阶段提交静态文件到Git时，Git检测到某一个阶段的静态文件包括新增（例如，增加某个图片，或在该阶段上传静态文件等都可以理解为新增操作）、修改和删除等操作后，会告知Node服务器在该阶段有新增、修改或删除的动作，并告知在静态文件中的具体调整位置。
Node服务器会获取到静态文件在不同阶段的调整动态，以便根据调整动态做出具体调整操作。
具体的，步骤1、node服务器获取静态文件在第一阶段已被调整的通知消息。
以第一阶段为DEV阶段为例进行说明，调整动态可以包括调整操作和调整位置等。例如，调整操作包括新增、修改和删除等。具体的调整位置，例如可以是静态文件中的文本内容中的某个位置，而也可以是静态文件中的某个图片等。比如，调整动态为删除静态文件，那么Git检测到工作人员对于静态文件的删除操作后，会以通知消息的形式告知Node服务器。并且告知当前对于静态文件的操作包括对XX位置的图片进行删除。
步骤2，根据调整动态，分别对预构建的数据库以及云服务器中存在的，且与第一阶段对应的静态文件进行调整。
Node服务器收到Git通知后，会相应修改node服务器预构建的数据库中与DEV阶段对应的静态文件夹中存储的静态文件。同时，也会对应修改云服务器中与DEV阶段对应的静态文件夹中的静态文件。
当DEV阶段的静态文件测试完成后，假设Node服务器预构建的数据库中与DEV阶段对应的静态文件最终为1-1版本。在SIT阶段，相应工作人员会对小程序进行进一步测试，并调取Node服务器预构建的数据库中的静态文件1-1，根据实际需求对静态文件1-1做出适应性调整（当然，也可能不做任何调整）。如上所介绍的，SIT阶段的静态文件定义为1-2。当SIT阶段的工作人员对静态文件1-2上传至GIT。Git会以通知消息的形式告知Node服务器，然后由Node服务器获取到静态文件1-2后，存储至Node服务器的数据库中与SIT阶段对应的静态文件夹。并将静态文件1-2上传至云服务器，由云服务器存储至云存储服务器中预先构建的对应阶段（SIT）的静态文件夹。
如果在SIT阶段，后续仍然有对静态文件1-2进行修改时，具体参见步骤1和步骤2的内容介绍，对静态文件1-2进行调整。
当SIT阶段对小程序调试完成后，进入PRD阶段。
当进入PRD阶段后，相应工作人员会对小程序进行进一步测试，并调取Node服务器预构建的数据库中的SIT阶段最终获取的静态文件1-2’，根据实际需求对静态文件1-2’做出适应性调整（当然，也可能不做任何调整）。假设初始获取的PRD阶段的静态文件为1-3。PRD阶段的工作人员对静态文件1-3上传至GIT。Git会以通知消息的形式告知Node服务器，然后由Node服务器获取到静态文件1-3后，存储至Node服务器的数据库中与PRD阶段对应的静态文件夹。并将静态文件1-3上传至云服务器，由云服务器存储至云存储服务器中预先构建的对应阶段（PRD）的静态文件夹。
在PRD阶段，当小程序进行测试完成后，静态文件最终确定。同样执行上述类似操作，这里不再赘述。经过PRD阶段后，将进入到UAT阶段。
上述过程中，工作人员不再需要手动上传静态文件至Node服务器中的数据库以及云服务器。而是，Node服务器获取Git通知消息后，自动从Git中获取静态文件，存储至数据库，以及云服务器中。减少工作人员手动上传环节，避免工作人员在手动上传过程存在遗漏等问题，比如忘记上传，或者传错静态文件等。
可选的，在上述过程中，所介绍的是每个阶段对于静态文件的处理和阶段的延续性。考虑到如果第一阶段非起始阶段时，不仅仅需要对当前阶段的静态文件进行调整，还需要同步向下调整。即，确定第一阶段之前存在的第i个阶段，根据调整动态，分别对预构建的数据库以及云服务器中存在的，且与第i个阶段对应的静态文件进行调整；
直至第i个阶段为起始阶段，根据调整动态，对预构建的数据库以及云服务器中存在的，且与起始阶段对应的静态文件进行调整后，停止调整操作，其中，i为大于或等于2的正整数。
例如，存在紧急替换静态文件时，并不会严格按照DEV->SIT->UAT->PRD流程来操作。会直接在UAT或PRD环境进行上线操作，之后就需要向下环境合并，避免下次发版低开发环境的旧文件替换紧急替换的新文件。从而添加自动向下同步功能，程序会完成PRD->UAT->SIT->DEV反合并操作。如UAT提交静态文件，会将UAT提交的文件自动合并到SIT和DEV，当遇到冲突将会强制替换并提示开发者。具体反合并过程参见上文中与图3对应的文字描述过程。
上述所有操作过程均已在图2对应的实施例中做了详细描述，这里不再过多说明。
进入UAT阶段后，如果UAT阶段的静态文件未与小程序版本之间建立绑定关系。那么就会存在每次最新的上传静态文件都将覆盖之前存储的旧的静态文件。而因为云服务器中静态文件一旦更新，都将对外界有效，也即是可以被用户看到。
因此，该方法还包括步骤3，获取第n版本小程序进入发布阶段的通知指令。
步骤4，根据通知指令，从预构建的数据库中，获取与第n版本小程序对应的静态文件。
步骤5，当第n版本小程序为初始版本小程序时，直接建立第n版本小程序与第n版本小程序对应的静态文件之间的绑定关系。
步骤6，当第n版本小程序并非为初始版本小程序，且n大于预设阈值时，将第n版本小程序对应的静态文件与最低版本静态文件夹中的静态文件进行对比，获取区别内容。
步骤7，将区别内容同步至最低版本静态文件夹中的静态文件中，并建立第n版本小程序与最低版本静态文件夹中经修改后的静态文件之间的绑定关系。
在一个具体的例子中，如果预设阈值为10。那么，可以事先建立10个与发布的小程序版本对应的静态文件夹，如v1-v10。当UAT阶段对小程序测试完毕，将小程序发版至PRD阶段时，发布小程序的工具或者是承载最终小程序的平台，例如微信平台。其与Node服务器之间会通过预设定的接口建立通信关系。发布每一个版本小程序后，都会以通知指令形式告知Node服务器。例如，告知Node服务器当前发布小程序版本对应的标识信息，标识信息用于指示当前小程序的版本，例如标识信息可以是小程序版本号，比如当前版本为第11个版本，标识信息为V11。
node服务器获取标识信息后，确定V11大于V10，则会将服务器本地与V11版本对应的最终确定的UAT静态文件（也可理解为PRD阶段对应的静态文件）与v1版本小程序对应的静态文件进行对比，获取区别内容，并将区别内容同步至v1静态文件夹中的静态文件中，并建立V11版本小程序与v1版本静态文件夹中经修改后的静态文件之间的绑定关系。例如，修改配置文件将V11与v1版本的静态文件夹对应。当小程序运行时，会读取配置内容，根据自身版本过去云服务器版本，在资源Url后面追加/v1，实现与静态文件的版本绑定。
步骤3至步骤7的操作过程，均在图6对应的方法实施例中做了详细描述，因此这里不再过多说明。
上述实施例提供的方法步骤，结合了图2对应的方法实例和图6对应的方法实例进行了具体说明。其有益效果参见图2和图6所对应方法实例的效果，这里不再过多赘述。
图8为本申请实施例提供的一种静态文件流程管理装置，该装置包括：获取单元901和处理单元902。
获取单元901，用于获取静态文件在第一阶段已被调整的通知消息，其中，通知消息包括与第一阶段对应的静态文件调整动态；
处理单元902，用于根据调整动态，分别对预构建的数据库以及云服务器中存在的，且与第一阶段对应的静态文件进行调整，其中，第一阶段为小程序从开发到发布过程中的任一个阶段。
可选的，处理单元902还用于，确定第一阶段之前存在的第i个阶段，根据调整动态，分别对预构建的数据库以及云服务器中存在的，且与第i个阶段对应的静态文件进行调整；
直至第i个阶段为起始阶段，根据调整动态，对预构建的数据库以及云服务器中存在的，且与起始阶段对应的静态文件进行调整后，停止调整操作，其中，i为大于或等于2的正整数。
可选的，当静态文件包括多个子文件,处理单元902具体用于执行以下至少一种操作：
根据调整状态，对多个子文件中的部分或全部子文件同步调整操作；
或者，
根据调整动态，对多个子文件中的单个子文件调整操作。
本实施例提供的静态文件流程管理装置中各功能部件所执行的功能均已在图2对应的实施例中做了详细介绍，因此这里不再赘述。
本申请实施例提供的一种静态文件流程管理装置，首先获取静态文件在第一阶段已被调整的通知消息。根据通知消息，获取与第一阶段对应的静态文件调整动态，进而根据调整动态，分别对预构建的数据库以及云服务器中存在的，且与第一阶段对应的静态文件进行调整。整个调整过程中，都是根据静态文件调整动态完成自动调整。包括对于静态文件的上传、修改和删除等调整过程。通过该方式，省略工作人员手动上传静态文件的流程，提升工作效率，同时也避免了由于手动上传静态文件所带来的潜在线上问题。
修改当前阶段后，还会同步修改当前阶段之前的所有阶段中的静态文件，以避免下次修改当前阶段的之前任一阶段的静态文件时，因为本次修改没有同步静态文件，导致下次修改并非是在本次修改静态文件基础上做出调整所带来的弊端。
图9为本申请实施例提供的一种小程序版本管理装置，该装置包括：获取单元1001、比较单元1002以及处理单元1003。
获取单元1001，用于获取第n版本小程序进入发布阶段的通知指令；根据通知指令，从预构建的数据库中，获取与第n版本小程序对应的静态文件，静态文件为与发布阶段对应的静态文件；
比较单元1002，用于当第n版本小程序为初始版本小程序时，直接建立第n版本小程序与第n版本小程序对应的静态文件之间的绑定关系；
或，当第n版本小程序并非为初始版本小程序，且n大于预设阈值时，将第n版本小程序对应的静态文件与最低版本静态文件夹中的静态文件进行对比，获取区别内容，最低版本静态文件夹为云服务器中存储的至少一个静态文件夹中的一个；
处理单元1003，用于将区别内容同步至最低版本静态文件夹中的静态文件中，并建立第n版本小程序与最低版本静态文件夹中经修改后的静态文件之间的绑定关系，其中n为正整数。
可选的，通知指令中包括第n版本小程序对应的标识信息；获取单元1001，具体用于：从数据库中提取与标识信息对应的静态文件，其中，n为正整数。
可选的，比较单元1002具体用于，在第一静态文件夹未与任一小程序版本之间存在绑定关系时，确定第一静态文件夹为最低版本静态文件夹；
或者，在至少一个静态文件夹中每一个静态文件夹均与一个小程序版本之间建立绑定关系时，则确定与最低小程序版本之间建立绑定关系的静态文件所在的第二静态文件夹为最低版本静态文件夹，其中，第一静态文件夹，以及第二静态文件夹均为至少一个静态文件夹中的任一个静态文件夹；最低小程序版本为版本号最小的小程序版本。
本实施例提供的静态文件流程管理装置中各功能部件所执行的功能均已在图6对应的实施例中做了详细介绍，因此这里不再赘述。
本申请实施例提供的一种小程序版本管理装置，建立每一个版本小程序和对应版本静态文件之间的绑定关系后，不论发布哪个版本静态文件时，都会自动上传至云服务器中与该版本小程序对应的静态文件夹中。不会再发生新版本的静态文件强制覆盖旧版本静态文件，并展示给用户查看的情况。以解决用户频繁看到不同版本静态文件的烦恼，更不会让用户赶到静态文件发布内容和小程序中内容不一致的情况发生，大大提升用户体验度。
图10为本申请实施例提供的一种计算机设备的结构示意图，图10所示的计算机设备1100包括：至少一个处理器1101、存储器1102、至少一个网络接口1103和其他用户接口1104。计算机设备1100中的各个组件通过总线系统1105耦合在一起。可理解，总线系统1105用于实现这些组件之间的连接通信。总线系统1105除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图10中将各种总线都标为总线系统1105。
其中，用户接口1104可以包括显示器、键盘或者点击设备(例如，鼠标，轨迹球(trackball)、触感板或者触摸屏等。
可以理解，本申请实施例中的存储器1102可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(Read-Only Memory，ROM)、可编程只读存储器 (Programmable ROM，PROM)、可擦除可编程只读存储器(Erasable PROM，EPROM)、电可擦除可编程只读存储器(Electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(Random Access Memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(Static RAM，SRAM)、动态随机存取存储器 (Dynamic RAM，DRAM)、同步动态随机存取存储器(Synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(DoubleData Rate SDRAM，DDRSDRAM)、增强型同步动态随机存取存储器(Enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(Synch link DRAM，SLDRAM)和直接内存总线随机存取存储器(Direct Rambus RAM，DRRAM)。 本文描述的存储器1102旨在包括但不限于这些和任意其它适合类型的存储器。
在一些实施方式中，存储器1102存储了如下的元素，可执行单元或者数据结构，或者他们的子集，或者他们的扩展集：操作系统11021和应用程序 11022。
其中，操作系统11021，包含各种系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础业务以及处理基于硬件的任务。应用程序11022，包含各种应用程序，例如媒体播放器(Media Player)、浏览器(Browser)等，用于实现各种应用业务。实现本申请实施例方法的程序可以包含在应用程序11022中。
在本申请实施例中，通过调用存储器1102存储的程序或指令，具体的，可以是应用程序11022中存储的程序或指令，处理器1101用于执行图1对应的实施例中任意实施方式所提供的方法步骤。
上述本申请实施例揭示的方法可以应用于处理器1101中，或者由处理器1101实现。处理器1101可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器1101中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器1101可以是通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(FieldProgrammable Gate Array， FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件单元组合执行完成。软件单元可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程 存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器1102，处理器1101读取存储器1102中的信息，结合其硬件完成上述方法的步骤。
可以理解的是，本文描述的这些实施例可以用硬件、软件、固件、中间件、微码或其组合来实现。对于硬件实现，处理单元可以实现在一个或多个专用集成电路(ApplicationSpecific Integrated Circuits，ASIC)、数字信号处理器(Digital Signal Processing，DSP)、数字信号处理设备(DSPDevice，DSPD)、可编程逻辑设备(Programmable LogicDevice，PLD)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)、通用处理器、控制器、微控制器、微处理器、用于执行本申请功能的其它电子单元或其组合中。
对于软件实现，可通过执行本文功能的单元来实现本文的技术。软件代码可存储在存储器中并通过处理器执行。存储器可以在处理器中或在处理器外部实现。
本实施例提供的计算机设备可以是如图10中所示的计算机设备，可执行如图3中静态文件流程管理方法的所有步骤，进而实现图3所示静态文件流程管理方法的技术效果，具体请参照图3相关描述；
或者，可执行如图6中小程序版本管理方法的所有步骤，进而实现图6所示小程序版本管理方法的技术效果，具体请参照图6相关描述；为简洁描述，在此不作赘述。
本申请实施例还提供了一种存储介质（计算机可读存储介质）。这里的存储介质存储有一个或者多个程序。其中，存储介质可以包括易失性存储器，例如随机存取存储器；存储器也可以包括非易失性存储器，例如只读存储器、快闪存储器、硬盘或固态硬盘；存储器还可以包括上述种类的存储器的组合。
当存储介质中一个或者多个程序可被一个或者多个处理器执行，以实现上述在计算机设备侧执行的静态文件流程管理方法。
处理器用于执行存储器中存储的静态文件流程管理程序，以实现在计算机设备侧执行的静态文件流程管理方法的步骤，具体参见图2对应的实施例，或者，处理器用于执行存储器中存储的小程序版本管理程序，以实现在计算机设备侧执行的小程序版本管理方法的步骤，具体参见图6对应的实施例，这里不再赘述。
本申请实施例还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述静态文件流程管理方法中任一实施例的步骤；或者执行上述小程序版本管理方法中任一实施例的步骤。
专业人员应该还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
结合本文中所公开的实施例描述的方法或算法的步骤可以用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器（RAM）、内存、只读存储器（ROM）、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。
以上的具体实施方式，对本申请的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上仅为本申请的具体实施方式而已，并不用于限定本申请的保护范围，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (9)

1.一种静态文件管理方法，其特征在于，所述方法包括：
获取静态文件在第一阶段已被调整的通知消息，其中，所述通知消息包括与所述第一阶段对应的静态文件调整动态；
根据所述调整动态，分别对预构建的数据库以及云服务器中存在的，且与所述第一阶段对应的静态文件进行调整，其中，所述第一阶段为小程序从开发到发布过程中的任一个阶段；在所述数据库中构建与不同阶段分别对应的文件夹，将不同阶段的静态文件存储到所述数据库中对应的文件夹；在所述云服务器中构建不同阶段分别对应的文件夹，将不同阶段的静态文件上传并存储到所述云服务器中对应的文件夹；
当所述第一阶段为非起始阶段时，所述根据所述调整动态，分别对预构建的数据库以及云服务器中存在的，且与所述第一阶段对应的静态文件进行调整之后，所述方法还包括：
确定所述第一阶段之前存在的第i个阶段，根据所述调整动态，分别对预构建的所述数据库以及所述云服务器中存在的，且与所述第i个阶段对应的静态文件进行调整；
直至所述第i个阶段为起始阶段，根据所述调整动态，对预构建的所述数据库以及所述云服务器中存在的，且与所述起始阶段对应的静态文件进行调整后，停止调整操作，其中，i为大于或等于2的正整数。
2.根据权利要求1所述的方法，其特征在于，所述静态文件包括多个子文件；
所述根据所述调整动态，对静态文件进行调整，包括以下至少一种操作：
根据所述调整动态，对所述多个子文件中的部分或全部子文件同步调整操作；
或者，
根据所述调整动态，对所述多个子文件中的单个子文件调整操作。
3.一种小程序版本管理方法，其特征在于，所述方法包括：
在数据库中构建与不同阶段分别对应的文件夹，将不同阶段的静态文件存储到所述数据库中对应的文件夹；在云服务器中构建不同阶段分别对应的文件夹，将不同阶段的静态文件上传并存储到所述云服务器中对应的文件夹；
获取第n版本小程序进入发布阶段的通知指令；其中，所述第n版小程序进入发布阶段表示所述第n版小程序对应的静态文件已完成在发布阶段之前的所有节点的静态文件管理操作；
根据所述通知指令，从预构建的数据库中，获取与所述第n版本小程序对应的静态文件，所述静态文件为与所述发布阶段对应的静态文件；
当所述第n版本小程序为初始版本小程序时，直接建立所述第n版本小程序与所述第n版本小程序对应的静态文件之间的绑定关系；
或，当所述第n版本小程序并非为初始版本小程序，且n大于预设阈值时，将所述第n版本小程序对应的静态文件与最低版本静态文件夹中的静态文件进行对比，获取区别内容，所述最低版本静态文件夹为云服务器中存储的至少一个静态文件夹中的一个；
将所述区别内容同步至所述最低版本静态文件夹中的静态文件中，并建立所述第n版本小程序与最低版本静态文件夹中经修改后的静态文件之间的绑定关系，其中n为正整数。
4.根据权利要求3所述的方法，其特征在于，所述通知指令中包括第n版本小程序对应的标识信息；所述根据所述通知指令，从预构建的所述数据库中，获取与所述第n版本小程序对应的静态文件，具体包括：
从所述数据库中提取与所述标识信息对应的静态文件，其中，n为正整数，其中，所述标识信息用于指示小程序对应的版本。
5.根据权利要求4所述的方法，其特征在于，从所述至少一个静态文件夹中，识别出所述最低版本静态文件夹，具体包括：
在第一静态文件夹未与任一小程序版本之间存在绑定关系时，确定所述第一静态文件夹为所述最低版本静态文件夹；
或者，在所述至少一个静态文件夹中每一个静态文件夹均与一个小程序版本之间建立绑定关系时，则确定与最低小程序版本之间建立绑定关系的静态文件所在的第二静态文件夹为所述最低版本静态文件夹，其中，所述第一静态文件夹，以及所述第二静态文件夹均为所述至少一个静态文件夹中的任一个静态文件夹；所述最低小程序版本为版本号最小的小程序版本。
6.一种静态文件管理装置，其特征在于，所述装置包括：
获取单元，用于获取静态文件在第一阶段已被调整的通知消息，其中，所述通知消息包括与所述第一阶段对应的静态文件调整动态；
处理单元，用于根据所述调整动态，分别对预构建的数据库以及云服务器中存在的，且与所述第一阶段对应的静态文件进行调整，其中，所述第一阶段为小程序从开发到发布过程中的任一个阶段；在所述数据库中构建与不同阶段分别对应的文件夹，将不同阶段的静态文件存储到所述数据库中对应的文件夹；在所述云服务器中构建不同阶段分别对应的文件夹，将不同阶段的静态文件上传并存储到所述云服务器中对应的文件夹；当所述第一阶段为非起始阶段时，所述根据所述调整动态，分别对预构建的数据库以及云服务器中存在的，且与所述第一阶段对应的静态文件进行调整之后，还包括：确定所述第一阶段之前存在的第i个阶段，根据所述调整动态，分别对预构建的所述数据库以及所述云服务器中存在的，且与所述第i个阶段对应的静态文件进行调整；直至所述第i个阶段为起始阶段，根据所述调整动态，对预构建的所述数据库以及所述云服务器中存在的，且与所述起始阶段对应的静态文件进行调整后，停止调整操作，其中，i为大于或等于2的正整数。
7.一种小程序版本管理装置，其特征在于，所述装置包括：
获取单元，用于在数据库中构建与不同阶段分别对应的文件夹，将不同阶段的静态文件存储到所述数据库中对应的文件夹；在云服务器中构建不同阶段分别对应的文件夹，将不同阶段的静态文件上传并存储到所述云服务器中对应的文件夹；获取第n版本小程序进入发布阶段的通知指令；根据所述通知指令，从预构建的数据库中，获取与所述第n版本小程序对应的静态文件，所述静态文件为与所述发布阶段对应的静态文件；其中，所述第n版小程序进入发布阶段表示所述第n版小程序对应的静态文件已完成在发布阶段之前的所有节点的静态文件管理操作；
比较单元，用于当所述第n版本小程序为初始版本小程序时，直接建立所述第n版本小程序与所述第n版本小程序对应的静态文件之间的绑定关系；
或，当所述第n版本小程序并非为初始版本小程序，且n大于预设阈值时，将所述第n版本小程序对应的静态文件与最低版本静态文件夹中的静态文件进行对比，获取区别内容，所述最低版本静态文件夹为所述云服务器中存储的至少一个静态文件夹中的一个；
处理单元，用于将所述区别内容同步至所述最低版本静态文件夹中的静态文件中，并建立所述第n版本小程序与最低版本静态文件夹中经修改后的静态文件之间的绑定关系，其中n为正整数。
8.一种计算机设备，其特征在于，所述计算机设备包括：至少一个处理器和存储器；
所述处理器用于执行所述存储器中存储的静态文件管理程序，以实现权利要求1~2中任一项所述的静态文件管理方法；或者，所述处理器用于执行所述存储器中存储的小程序版本管理程序，以实现权利要求3~5中任一项所述的小程序版本管理方法。
9.一种计算机存储介质，其特征在于，所述计算机存储介质存储有一个或者多个程序，所述一个或者多个程序可被计算机设备执行，以实现权利要求1~2中任一项所述的静态文件管理方法，或实现权利要求3-5中任一项所述的小程序版本管理方法。
CN202011153227.1A 2020-10-23 2020-10-23 静态文件流程、小程序版本管理方法、装置及计算机设备 Active CN112230985B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011153227.1A CN112230985B (zh) 2020-10-23 2020-10-23 静态文件流程、小程序版本管理方法、装置及计算机设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011153227.1A CN112230985B (zh) 2020-10-23 2020-10-23 静态文件流程、小程序版本管理方法、装置及计算机设备

Publications (2)

Publication Number Publication Date
CN112230985A CN112230985A (zh) 2021-01-15
CN112230985B true CN112230985B (zh) 2024-04-05

Family

ID=74109980

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011153227.1A Active CN112230985B (zh) 2020-10-23 2020-10-23 静态文件流程、小程序版本管理方法、装置及计算机设备

Country Status (1)

Country Link
CN (1) CN112230985B (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112882747B (zh) * 2021-01-29 2024-04-05 北京思特奇信息技术股份有限公司 一种界面化发布程序的方法及系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017074414A1 (en) * 2015-10-30 2017-05-04 Hewlett Packard Enterprise Development Lp Software kit release management
CN109167831A (zh) * 2018-08-31 2019-01-08 北京航天云路有限公司 多站点用户行为信息同步方法及系统
CN110609732A (zh) * 2019-08-13 2019-12-24 平安普惠企业管理有限公司 应用程序部署方法、装置、计算机设备和存储介质
CN110737458A (zh) * 2019-09-18 2020-01-31 平安科技（深圳）有限公司 一种代码更新方法和相关装置
CN111724133A (zh) * 2020-06-19 2020-09-29 北京达佳互联信息技术有限公司 一种创建项目的方法及装置

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10176080B2 (en) * 2016-09-19 2019-01-08 Grand Rounds, Inc. Methods and systems for content management and testing

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017074414A1 (en) * 2015-10-30 2017-05-04 Hewlett Packard Enterprise Development Lp Software kit release management
CN109167831A (zh) * 2018-08-31 2019-01-08 北京航天云路有限公司 多站点用户行为信息同步方法及系统
CN110609732A (zh) * 2019-08-13 2019-12-24 平安普惠企业管理有限公司 应用程序部署方法、装置、计算机设备和存储介质
CN110737458A (zh) * 2019-09-18 2020-01-31 平安科技（深圳）有限公司 一种代码更新方法和相关装置
CN111724133A (zh) * 2020-06-19 2020-09-29 北京达佳互联信息技术有限公司 一种创建项目的方法及装置

Also Published As

Publication number Publication date
CN112230985A (zh) 2021-01-15

Similar Documents

Publication Publication Date Title
CA2831381C (en) Recovery of tenant data across tenant moves
CN105739968B (zh) 基于分布式版本控制系统Git的更新内容的评审方法和装置
JP2017084334A (ja) 仮想マシンイメージファイルを抽出する方法および装置
JP4880376B2 (ja) 支援装置、プログラム、情報処理システム及び支援方法
CN110297659A (zh) 算法模型部署上线方法和装置
WO2019109519A1 (zh) 业务规则管理方法、装置、设备及计算机可读存储介质
CN112230985B (zh) 静态文件流程、小程序版本管理方法、装置及计算机设备
CN111949607A (zh) 一种udt文件的监控方法、系统和装置
CN113821249A (zh) 项目开发配置的方法、装置、电子设备和可读存储介质
CN112115056B (zh) 一种项目部署方法和装置、服务器、存储介质
CN104461893A (zh) 数据处理方法与数据处理装置
US10311138B2 (en) Preventing partial change set deployments in content management systems
CN111367703A (zh) 故障排查方法及装置
CN113010149A (zh) 应用加载方法、装置、用户终端和服务器
CN115309558A (zh) 一种资源调度管理系统、方法、计算机设备及存储介质
CN114936152A (zh) 应用测试方法及设备
CN114385570A (zh) 数据同步的方法、装置、电子设备和可读介质
CN112905164B (zh) 一种项目代码处理方法和装置
CN111935249A (zh) 同步校验方法及装置、计算机存储介质和电子设备
CN113806327A (zh) 一种数据库设计方法、装置及相关设备
CN116893834B (zh) 负载更新方法、装置、系统、电子设备及可读存储介质
US8887010B2 (en) Application information specifiable by users and third parties
CN115086297B (zh) 文件处理方法及设备
CN115185565A (zh) 基于约束的制品构建方法、装置、设备、介质和程序产品
CN108875070B (zh) 一种设置留言类网页的方法、设备和系统

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant