Method and apparatus for processing version data, storage medium and electronic device

Abstract

The application provides a version data processing method and device, a storage medium and an electronic device. The method comprises the following steps: obtaining first version data of a target miniprogram, wherein the target miniprogram is a subprogram installed in a target application program, and the first version data is code data of a first program version to be published by the target miniprogram; uploading the first version data to a first server, wherein the first server is a server corresponding to the target application program; simulating a target operation performed on a webpage end of the first server, and triggering sending of an audit request to the first server, wherein the audit request is used for requesting auditing of the first version data; and obtaining an auditing result of the first version data, wherein the auditing result is used for indicating whether the auditing of the first version data is passed. Through the application, the problem that the operation of the publishing process is complicated due to the fact that only a single interface is used to publish the miniprogram in the related art is solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of Internet, and in particular, to a version data processing method and device, a storage medium and an electronic device. BACKGROUND

[0002] At present, based on the open ability provided by some applications, a third party can develop, upload and maintain a program (for example, a small program) running in the application to provide a certain service or function for users of the application.

[0003] In the related art, a small program publishing scheme based on Gitlab CI (Continuous Integration) can be used: combining Gitlab CI and the developer tools provided by the application, a publishing task is configured on the Gitlab CI.

[0004] For example, Gitlab Runner (a bearer of script execution) Install can be downloaded, and a Runner is registered on the Gitlab server; a ".gitlab-ci.yml" file is configured under the code repository, and a building and deploying task is added; the source code of the developer tools is modified to increase an exception handling part; and after the code is committed, the task (a small program publishing task) is triggered.

[0005] For the above-mentioned small program publishing method, the controllability of the user for the publishing process is poor, and the version management is not flexible, and the user still needs to implement a set of version management process across self-developed services and Gitlab CI services. Moreover, if the size of a project is very large and needs to cross multiple repositories, the user still needs to develop the content of multi-repository code management by himself. In addition, the exceptions in the publishing process customized by the Gitlab CI service are difficult to capture comprehensively.

[0006] Therefore, in the related art, there is a problem that the publishing process operation is complicated due to the small program publishing through a single interface. SUMMARY

[0007] The present application provides a version data processing method and device, a storage medium and an electronic device to at least solve the problem that the publishing process operation is complicated due to the small program publishing through a single interface in the related art.

[0008] According to an aspect of some embodiments of the present application, a method for processing version data is provided. The method includes: obtaining first version data of a target miniprogram, wherein the target miniprogram is an installation-free subprogram running in a target application, and the first version data is code data of a first program version to be published by the target miniprogram; uploading the first version data to a first server, wherein the first server is a server corresponding to the target application; simulating a target operation performed on a web page end of the first server to trigger sending an audit request to the first server, wherein the audit request is used to request auditing the first version data; and obtaining an audit result of the first version data, wherein the audit result is used to indicate whether the auditing of the first version data is passed.

[0009] Optionally, before obtaining the timing publishing task configured by the second client, the method further includes: displaying a task configuration interface of the timing publishing task by the second client, wherein the task configuration interface includes a target area for configuring a publishing time corresponding to the timing publishing task; detecting a third operation performed on the target area and a fourth operation performed on a confirm button in the task configuration interface, wherein the third operation is used to configure the publishing time of the timing publishing task, and the fourth operation is used to confirm the configuration of the timing publishing task; and in response to the fourth operation, sending a task configuration message to the third server, wherein the task configuration message is used to instruct the third server to configure the timing publishing task, and the task configuration message carries the publishing time.

[0010] According to an aspect of some embodiments of the present application, a device for processing version data is provided. The device includes: a first obtaining unit configured to obtain first version data of a target miniprogram, wherein the target miniprogram is an installation-free subprogram running in a target application, and the first version data is code data of a first program version to be published by the target miniprogram; an uploading unit configured to upload the first version data to a first server, wherein the first server is a server corresponding to the target application; a triggering unit configured to simulate a target operation performed on a web page end of the first server to trigger sending an audit request to the first server, wherein the audit request is used to request auditing the first version data; and a second obtaining unit configured to obtain an audit result of the first version data, wherein the audit result is used to indicate whether the auditing of the first version data is passed.

[0011] Optionally, the first obtaining unit includes: a first pulling module configured to pull main code data of the target miniprogram from a main code repository of the target miniprogram; a second pulling module configured to pull a plurality of subcode data of the target miniprogram from a plurality of subcode repositories of the target miniprogram respectively, wherein the plurality of subcode repositories correspond to the plurality of subcode data one by one; and a merging module configured to merge each subcode data in the plurality of subcode data into a code position corresponding to the each subcode data in the main code data respectively, and construct the first version data.

[0012] Optionally, the above apparatus further includes: a download unit, configured to download second version data via a target device before acquiring the first version data to be released of the target mini-program, wherein the second version data is the code data of a second program version already released by the target mini-program, the second program version containing multiple code branches, each of the multiple code branches corresponding to different parts of the code data in the second version data; a first detection unit, configured to detect a first operation performed on the display interface of a first client, wherein the first client runs on the target device, the first operation being configured to select a target branch to be updated from the multiple code branches, the target branch corresponding to the first code data in the second version data; and a first sending unit, configured to respond to the first operation by sending an update instruction to a target code repository, wherein the target code repository is a code repository storing the first code data in a main code repository and multiple sub-code repositories, the update instruction being configured to instruct the first code data to be updated using the second code data, and the first version data including the second code data.

[0013] Optionally, the above apparatus further includes: a third acquisition unit, configured to acquire a scheduled release task configured through a second client before acquiring the first version data of the target mini-program to be released, wherein the scheduled release task is used to release the program version of the target mini-program at regular intervals; and a startup unit, configured to start the scheduled release task to release the program version of the target mini-program at regular intervals according to the release time indicated by the scheduled release task, wherein the first program version is a program version released by the target mini-program.

[0014] Optionally, the above apparatus further includes: a first display unit, configured to display a task configuration interface for a timed publishing task via the second client before acquiring the timed publishing task configured through the second client, wherein the task configuration interface includes a target area for configuring the publishing time corresponding to the timed publishing task; a second detection unit, configured to detect a third operation performed on the target area and a fourth operation performed on the confirm button in the task configuration interface, wherein the third operation is used to configure the publishing time of the timed publishing task, and the fourth operation is used to confirm the configuration of the timed publishing task; and a second sending unit, configured to respond to the fourth operation by sending a task configuration message to a third server, wherein the task configuration message is used to instruct the third server to configure the timed publishing task, and the task configuration message carries the publishing time.

[0015] Optionally, the apparatus further includes a second display unit configured to display, through the third client, a version publishing interface of the target miniprogram before the first version data of the target miniprogram to be published is acquired, wherein the version publishing interface is a publishing interface of a program version of the target miniprogram; a third detection unit configured to detect a second operation performed on a target button in the version publishing interface, wherein the second operation is used to trigger publishing of the first program version; and a third sending unit configured to send, in response to the second operation, a version publishing instruction to the second server to trigger the second server to acquire the first version data.

[0016] Optionally, the apparatus further includes a receiving unit configured to receive, after the first version data is uploaded to the first server, abnormal indication information returned by the first server, wherein the abnormal indication information is used to indicate an abnormality in uploading the first version data; a detecting unit configured to detect, from a web page end of the first server, state indication information of the first version data, wherein the state indication information is used to indicate an uploading state of the first version data; and a determining unit configured to determine that the uploading of the first version data is abnormal in a case where the abnormal indication information and the state indication information match.

[0017] Optionally, the second acquiring unit includes a starting module configured to start a page refreshing task, wherein the page refreshing task is used to periodically refresh the web page end to acquire page data corresponding to the web page end; and a determining module configured to determine, in a case where the target page state identifier is included in the page data, an audit result of the first version data according to the target page state identifier.

[0018] According to still another aspect of the embodiments of the present application, a computer readable storage medium is provided, and the storage medium stores a computer program. The computer program is configured to execute the steps of any of the above-mentioned version data processing methods when running.

[0019] According to still another aspect of the embodiments of the present application, an electronic device is provided, which includes a memory and a processor. The memory stores a computer program, and the processor is configured to execute the computer program to perform the steps of any of the above-mentioned version data processing methods.

[0020] According to still another aspect of the embodiments of the present application, a computer program product or a computer program is provided, which includes computer instructions stored in a computer readable storage medium. A processor of a computer device reads the computer instructions from the computer readable storage medium, and the processor executes the computer instructions to cause the computer device to perform the steps of any of the above-mentioned version data processing methods.

[0021] In the embodiment of the present application, the version data of the automatic submission applet is audited, the first version data of the target applet is obtained, wherein the target applet is a subprogram running in the target application program, and the first version data is the code data of the first program version to be published of the target applet; the first version data is uploaded to the first server, wherein the first server is a server corresponding to the target application program; the target operation performed on the web end of the first server is simulated to trigger the sending of an audit request to the first server, wherein the audit request is used to request the audit of the first version data; and the audit result of the first version data is obtained, wherein the audit result is used to indicate whether the audit of the first version data passes. Since the operation performed on the web end of the server is simulated to trigger the sending of an audit request to the server, the applet submission and audit process can be automatically implemented, and the user does not need to manually perform the version submission and audit of the applet through a single interface provided by the program, thereby achieving the purpose of simplifying the applet publishing process, achieving the technical effect of improving the applet publishing efficiency, and further solving the problem of complicated publishing process operation caused by the applet publishing through a single interface in the related art. BRIEF DESCRIPTION OF DRAWINGS

[0022] The accompanying drawings, which are incorporated into and form a part of the specification, illustrate preferred embodiments of the present application and, together with the description, serve to explain the principles of the application.

[0023] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the accompanying drawings needed to be used in the embodiments or prior art description will be briefly introduced. Obviously, for those skilled in the art, other drawings can also be obtained based on these drawings without creative labor.

[0024] Figure 1 is a schematic diagram of a hardware environment of an optional version data processing method according to an embodiment of the present application;

[0025] Figure 2 is a flowchart of an optional version data processing method according to an embodiment of the present application;

[0026] Figure 3 is a schematic diagram of an optional network architecture according to an embodiment of the present application;

[0027] Figure 4 is a flowchart of an optional version data processing method according to an embodiment of the present application;

[0028] Figure 5 is a schematic diagram of an optional version data processing method according to an embodiment of the present application;

[0029] Figure 6 is a schematic diagram of an optional timing publishing task according to an embodiment of the present application;

[0030] Figure 7 is a schematic diagram of an optional applet publishing interface according to an embodiment of the present application;

[0031] Figure 8 is a schematic diagram of another optional network architecture according to an embodiment of the present application;

[0032] Figure 9 is a flow diagram of another optional version data processing method according to an embodiment of the present application;

[0033] Figure 10 is a schematic diagram of an optional simulation browser operation according to an embodiment of the present application;

[0034] Figure 11 is a structural block diagram of an optional version data processing apparatus according to an embodiment of the present application;

[0035] Figure 12 is a structural block diagram of an optional electronic apparatus according to an embodiment of the present application. DETAILED DESCRIPTION

[0036] In order to make the personnel in the art better understand the present application, the technical solutions in the embodiments of the present application will be described clearly and completely below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work should belong to the scope of protection of the present application.

[0037] It should be noted that the terms "first", "second", and the like in the specification and claims of the present application and the above-described drawings are used to distinguish similar objects, and do not necessarily indicate a specific order or a chronological sequence. It should be understood that the data thus used can be interchanged under appropriate circumstances, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device that includes a series of steps or units does not necessarily have to be limited to those steps or units clearly listed, but can include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0038] First, some of the nouns or terms that appear in the description of the embodiments of the present application are applicable to the following explanations:

[0039] (1)Small program: a program developed and maintained by a third party using the open capabilities provided by an application (App, such as an instant messaging application), running within the App, providing certain services or functions to users of the App.

[0040] (2)Chrome V8: an open-source browser engine.

[0041] (3)NodeJS: a runtime environment for JavaScript language based on Chrome V8 engine, usually running on server side.

[0042] (4)HTTP: HyperText Transfer Protocol, a request-response protocol, usually running on TCP protocol (Transmission Control Protocol). It can specify what messages the client can send to the server and what responses it can get. The headers of the request and response messages are given in ASCII code (American Standard Code for Information Interchange); the content of the message has a format similar to MIME (Multipurpose Internet Mail Extensions).

[0043] (5)Windows Server: a server operating system that can run on physical machines and virtual machines.

[0044] (6)Puppeteer: an open-source automated testing framework that provides both interface and non-interface browser environments. The API (Application Programming Interface) provided by the framework simulates human-computer interaction operations on the pages running in the browser to achieve automated testing.

[0045] (7)Vue: an open-source, multi-level browser-side development framework based on JavaScript language.

[0046] (8)Ant design: a UI (User Interface) design standard.

[0047] (9)Enterprise instant messaging application: an instant messaging application with complete enterprise collaboration functions, usually only used within an enterprise.

[0048] (10) Git: An open-source code version control tool.

[0049] (11) GitLab: is an open-source project for repository management systems. It uses Git as a code management tool and builds web services on top of it.

[0050] (12)SPA: Single Page Web Application, a browser-based single-page application.

[0051] According to one aspect of the embodiments of this application, a method for processing version data is provided. Optionally, in this embodiment, the above-described method for processing version data can be applied to, for example... Figure 1 The hardware environment shown consists of terminal 101 and server 103. Figure 1 As shown, server 103 is connected to terminal 101 via a network and can be used to provide services (such as game services, application services, etc.) to the terminal or clients installed on the terminal. A database can be set up on the server or independently of the server to provide data storage services to server 103. The aforementioned network includes, but is not limited to, wide area networks (WANs), metropolitan area networks (MANs), or local area networks (LANs). Terminal 101 is not limited to PCs, mobile phones, tablets, etc. The version data processing method of this application embodiment can be executed by server 103, by terminal 101, or by both server 103 and terminal 101. The version data processing method of this application embodiment can also be executed by a client installed on terminal 101.

[0052] Taking running on a server as an example, Figure 2 This is a flowchart illustrating an optional version data processing method according to an embodiment of this application, such as... Figure 2 As shown, the process of this method may include the following steps:

[0053] Step S202: Obtain the first version data of the target mini-program, wherein the target mini-program is a sub-program that runs within the target application without requiring installation, and the first version data is the code data of the first program version of the target mini-program to be released;

[0054] Step S204: Upload the first version data to the first server, wherein the first server is the server corresponding to the target application;

[0055] Step S206: Simulate the target operation performed on the web page of the first server to trigger the sending of an audit request to the first server, wherein the audit request is used to request the audit of the first version data;

[0056] In step S208, an audit result of the first version data is obtained, where the audit result is used to indicate whether the audit of the first version data passes.

[0057] Through the steps S202 to S208, the first version data of the target applet is obtained, where the target applet is an installation-free subprogram running in the target application, and the first version data is the code data of the first program version to be published by the target applet. The first version data is uploaded to the first server, where the first server is a server corresponding to the target application. The target operation performed on the web end of the first server is simulated to trigger sending of an audit request to the first server, where the audit request is used to request an audit of the first version data. The audit result of the first version data is obtained, where the audit result is used to indicate whether the audit of the first version data passes. The problem of complicated operation in the publishing process due to the applet publishing through a single interface only in the related art is solved, and the applet publishing efficiency is improved.

[0058] In the technical solution provided in step S202, the first version data of the target applet is obtained, where the target applet is an installation-free subprogram running in the target application, and the first version data is the code data of the first program version to be published by the target applet.

[0059] The version data processing method in this embodiment can be applied to a scenario where an application program allows a third-party program to run in the application program, for example, a scenario where an applet runs in an application program. The target applet can be an installation-free subprogram running in the target application program, which is developed and maintained by a third party. The target application program can be an instant messaging application, a third-party payment application (corresponding to a third-party payment platform), an online shopping application, a comprehensive business processing application, and the like, which are not limited in this embodiment. The target applet can be an installation-free program running in the target application program and capable of providing one or more business functions, such as a shopping function, a consultation function, a life service function, and the like.

[0060] The version data processing method in this embodiment can be applied to a network architecture as shown in Figure 3 , in which a code repository and a developer tool-based applet publishing system run. In Figure 3In the specific implementation, the client of the target applet is a client (a client of the applet publishing system) used by a relevant person of the target applet, and the relevant person can be an applet developer, a tester, an operation and maintenance person, and the like; the code repository can store program code of the applet; the associated server of the target applet (a server of the applet publishing system, for example, a Windows Server) can run a developer tool, which is configured to perform operations such as acquisition of code data of the applet and application for release of a version of the applet; and the associated server of the target application can be configured to perform operations such as auditing of a program version of the applet and release of the program version of the applet.

[0061] In the process of developing and maintaining the applet, a new program version of the applet can be released in a time-based manner or a non-time-based manner, to ensure normal operation of the applet and continuously improve user experience.

[0062] In the online version release of the target applet, the associated server of the target applet can first acquire code data of a program version to be released (that is, a first program version, for example, 2.28.1), to obtain first version data, which is code data of the first program version of the target applet.

[0063] In the technical solution provided in step S204, the first version data is uploaded to a first server, where the first server is a server corresponding to the target application.

[0064] After the first version data is acquired, the associated server of the target applet can upload the first version data to a first server, which is a server corresponding to the target application (and has the same function as the aforementioned associated server of the target application).

[0065] The first version data can be uploaded through a communication connection between the associated server of the target applet and the first server. The uploaded first version data can include at least one of the following: an applet identifier of the target applet, an object identifier of the uploader, a version identifier of the first program version, and other information, for example, information for security verification.

[0066] The applet identifier of the target applet can be used to determine the applet to be updated using the first version data. The object identifier of the uploader can be used to identify a person of the relevant persons of the target applet who triggers uploading of the first version data, or to identify a specific person of the relevant persons of the target applet, so that the first server verifies validity and legality of the first version data.

[0067] In addition, the uploaded first version data can be encrypted data to ensure data security during transmission. The type of encryption key used can be configured as needed, which is not limited in the embodiment.

[0068] After receiving the first version data, the first server can first verify the first version data, for example, validity verification, legality verification, security verification, etc. After verification, the first server can save the first version data and wait for subsequent operation instructions.

[0069] After the first version data is successfully uploaded, the associated server of the target applet can send a first notification message to the relevant personnel of the target applet to inform the successful uploading of the first version data. The notification method can include but is not limited to at least one of the following: a session message in an instant messaging application (which can be a target application), a notification message of the application, a short message, an email, etc. The embodiment is not limited.

[0070] In the technical solution provided in step S206, the target operation performed on the web page end of the first server is simulated to trigger the sending of an audit request to the first server, wherein the audit request is used to request an audit of the first version data.

[0071] After uploading the first version data to the first server, the associated server of the target applet can simulate the target operation performed on the web page end of the first server. The web page end of the first server can be a web page end in a non-interface browser environment.

[0072] The target operation can include a trigger operation performed on the audit submission page in the web page end, which is used to trigger the submission of an audit request to the first server to request an audit of the first version data. The audit request can carry at least one of the following: the applet identifier of the target applet, the version identifier of the first program version. The target operation can also include at least one of the following: logging in to the web page end using the target account and password, entering the audit submission page, and inputting version association information (such as the version identifier of the first program version) in the audit submission page.

[0073] The target operation can be controlled and executed by a target tool engine running on the associated server of the target applet. The target tool engine (for example, Puppeteer) can be provided by the target browser to simulate the running of the target browser. The target tool engine can be an open-source automated testing framework that can provide both interface and non-interface browser environments. The API provided by the framework simulates human-computer interaction operations on the page running in the browser to achieve the purpose of automated testing.

[0074] For example, the user is simulated by Puppeteer to operate the webpage of the first server, and the submitted version (first program version) is submitted for review.

[0075] After the first server receives the review request, the first version data can be controlled to be reviewed. For example, the first version data can be submitted to the developer platform of the applet for automatic review, or pushed to the reviewer of the applet for manual review by the reviewer.

[0076] In the technical solution provided in step S208, the review result of the first version data is obtained, wherein the review result is used to indicate whether the review of the first version data is passed.

[0077] After obtaining the review result of the first program version, the first server can return the review result through its webpage or other ways. The associated server of the target applet can obtain the review result of the first version data, which can be used to indicate that the review of the first version data is passed or not passed.

[0078] After obtaining the review result, the associated server of the target applet can notify the relevant personnel of the target applet through a second notification message. The notification method can include but is not limited to at least one of the following: a session message in an instant messaging application (which can be a target application), a notification message of the application, a short message, an email, etc. The present embodiment is not limited in this regard.

[0079] The relevant members of the target applet can test the first program version to verify whether the experience version of the first program version of the target applet can achieve the expected function, whether the running process is stable, etc. The above verification process and the review process can be executed in parallel, i.e., the verification can be performed after obtaining the first version data, or the verification can be performed in series after the review is passed. The present embodiment is not limited in this regard.

[0080] The second notification message can contain a graphic code (such as a two-dimensional code) or a link, so that the relevant members of the target applet can determine to publish the first program version. For example, the second notification message is a session message in an instant messaging application, which can contain a graphic code. After the experience version of the first program version is verified, the relevant members of the target applet can scan the graphic code to publish the formal version of the first program version.

[0081] As an optional embodiment, obtaining the first version data to be published by the target applet includes:

[0082] S11, pulling the main code data of the target applet from the main code repository of the target applet;

[0083] S12, respectively pulling the plurality of sub-code data of the target applet from the plurality of sub-code repositories of the target applet, wherein the plurality of sub-code repositories correspond to the plurality of sub-code data one by one;

[0084] S13, respectively merging each sub-code data in the plurality of sub-code data into a code position corresponding to each sub-code data in the main code data, to construct the first version data.

[0085] The first version data can be stored in one code repository. If the volume of one project is very large, if it is stored through one code repository, due to the large required repository capacity, it will cause problems such as easy data loss (after the repository is full, subsequent data cannot be continuously stored), inconvenient program code modification, etc.

[0086] Optionally, in the embodiment, a code management mode across multiple code repositories is provided. The code data of the target applet can be stored in multiple code repositories, and the multiple code repositories include a main code repository and a plurality of sub-code repositories. Each code repository can store part of the code data of the first version data.

[0087] The associated server of the target applet can respectively pull the main code data and the plurality of sub-code data from the plurality of code repositories, and merge the main code data and the plurality of sub-code data, thereby constructing the first version data.

[0088] Optionally, in order to merge the code data in different code repositories, a configuration file for code merging can be configured in advance, for example, a configuration file in JSON data format. The configuration file can indicate the position of the code data of each sub-code repository in the code data of the main code repository, and the code data of the sub-code repository can be identified by the repository address of the sub-code repository.

[0089] When performing code data merging, the configuration file can be parsed through a plug-in of gulp to determine the local path corresponding to the repository address of the sub-code repository (i.e., the path where the data in the sub-code repository is stored after being downloaded to the local), map the configuration file into a path structure, and merge the sub-code data into the corresponding position in the main code data according to the path structure, to construct the first version data.

[0090] When constructing the first version data, the plurality of code data (the main code data and the plurality of sub-code data) can be first subjected to code checking to check whether the writing manner of each code data conforms to the writing specification; then, each code data is subjected to code compilation and code compression; finally, the compressed code data is merged, thereby obtaining the first version data.

[0091] For example, as shown in FIG. 6, the first version data of the target applet can be constructed by merging the main code data and the plurality of sub-code data. Figure 4As shown, for all the pulled associated repository code, a pre-release build can be performed on the code, and the build process includes the following steps: eslint check (code specification check); Gulp compression (code compilation compression); Gulp task merging to obtain the app.json file of the small program; and uploading the merged file.

[0092] Through the embodiment, by storing the code data of the small program in multiple code repositories, the storage and control of the code data can be facilitated, and the convenience of program code modification can be improved.

[0093] As an optional embodiment, before obtaining the first version data to be released of the target small program, the above method further includes:

[0094] S21, downloading the second version data through the target device, wherein the second version data is code data of a second program version of the target small program that has been released, the second program version contains multiple code branches, and each code branch in the multiple code branches corresponds to different parts of the code data in the second version data;

[0095] S22, detecting a first operation performed on a display interface of a first client, wherein the first client runs on the target device, and the first operation is used to select a target branch to be updated from the multiple code branches, the target branch corresponding to first code data in the second version data;

[0096] S23, in response to the first operation, sending an update instruction to a target code repository, wherein the target code repository is a code repository storing the first code data in the master code repository and the multiple sub-code repositories, the update instruction is used to instruct to update the first code data using the second code data, and the first version data includes the second code data.

[0097] For the code data storage manner of the multiple code repositories, the updated code data of each program version can be the code data stored in a certain code repository. Different code data related to different versions can be stored in different code repositories.

[0098] For example, in a version (V1), the small program contains 3 functions: function 1, function 2, and function 3, the code data of function 1 and function 2 are stored in code repository 1, and the code data of function 3 is stored in code repository 2. When updating the next version (V2), function 1 of the 3 functions is updated (updated to function 1'), and function 2 and function 3 are not updated (retained), then, code repository 1 stores the code data of function 2 of V1 version and the code data of function 1' of V2 version (and can also store the code data of function 1 of V1 version), and code repository 2 stores the code data of function 3 of V1 version.

[0099] The latest program version released before the first program version can be a second program version (e.g., 2.28.0), and the code data of the second program version is second version data. The second program version includes a plurality of code branches, each of which corresponds to code data of a different part of the second version data, which can be code data implementing a certain function. The function can be a function updated by a certain historical version (the second program version or a program version before the second program version), and the code data corresponding to different code branches can be stored in different code repositories.

[0100] The plurality of code branches can be identified by a plurality of branch tags in a branch tag set, each of which is used to represent a code branch, i.e., to represent the code repository in which the code data corresponding to the code branch is stored and the storage location in the code repository.

[0101] To facilitate the determination of the location of this code update, the target device can download the code data of the last version of the first program version, i.e., the second version data. The target device can run a client (first client) of the applet publishing system. The target device can detect an operation performed on the display interface of the first client, and control the updating of the code data and the publishing of the program version.

[0102] The target device can detect a first operation performed on the display interface of the first client, the first operation being used to select a target branch to be updated from the plurality of code branches. The first operation can include, but is not limited to, at least one of the following: an input operation (an operation of inputting a branch identifier of the target branch), a click operation, etc.

[0103] The target branch corresponds to first code data in the second version data, and the first code data is stored in a main code repository and a target code repository of a plurality of sub-code repositories. In response to the first operation, the target device can send an update instruction to the target code repository to instruct the updating of the first code data using the second code data. The first version data can be the version data of the target applet published after the above updating operation.

[0104] Optionally, in this embodiment, detecting the first operation performed on the display interface of the first client can include detecting an input operation performed on an input area on the display interface of the first client, where the input area is an area for inputting a branch tag, and the input operation is used to input a target branch tag of the target branch, the target branch tag being used to represent the target code repository and the storage location of the first code data in the target code repository.

[0105] For example, the applet publishing system can support incremental updates of a certain Git sub-code repository, and the target code repository can be a Git sub-code repository. Figure 5In the shown update interface, the version identifier 2.28.0 of the previous version code can be input in the first input box, the previous version code is downloaded after clicking download, the release description is input in the second input box, for example, the identity of the release person is described, the code repository to be updated and the target branch to which the code is updated are added in the third box, and after clicking submit, the incremental update of the sub-code repository can be performed.

[0106] It should be noted that the code data can be written by the same client or by other clients, which is not limited in the embodiment.

[0107] Through the embodiment, the incremental update of the code data in the sub-code repository can improve the convenience of program code modification and the positioning efficiency of program running exception.

[0108] The release of the program version of the target mini-program can be automatic release (for example, controlled by a timing release task), manual release, or a combination of automatic release and manual release.

[0109] As an optional implementation, before obtaining the first version data to be released of the target mini-program, the above method further includes:

[0110] S31, obtaining a timing release task configured by the second client, wherein the timing release task is used for timing release of the program version of the target mini-program;

[0111] S32, starting the timing release task to timing release the program version of the target mini-program according to the release time indicated by the timing release task, wherein the first program version is a program version released by the target mini-program once.

[0112] The associated server of the target mini-program can obtain the timing release task configured by the second client, the timing release task is the timing release task of the target mini-program, and is used for indicating timing release of the program version of the target mini-program, and can also indicate the timing release time of the target mini-program.

[0113] The associated server of the target mini-program can start the timing release task to control timing release of the program version of the target mini-program according to the release time indicated by the timing release task. The first program version and the second program version can be program versions released by a timing release once.

[0114] It should be noted that the timing release task indicates the release time of the program version of the timing release target mini-program. If the code data of the target mini-program is not updated (the same as the code data released last time) at one timing release, the program version can not be released this time. If the code data of the target mini-program is updated (different from the code data released last time) at one timing release, the program version can be released.

[0115] Through the embodiment, the program version of the target mini-program is controlled to be updated in timing through the timing release task, which can simplify the release operation required to be performed by the related personnel, improve the efficiency of the program version release, and improve the user experience.

[0116] Optionally, in the embodiment, before the timing release task configured through the client is acquired, the task configuration interface of the timing release task can be displayed through the second client, wherein the task configuration interface includes a target area for configuring the release time corresponding to the timing release task; a third operation performed on the target area and a fourth operation performed on a confirm button in the task configuration interface are detected, wherein the third operation is used to configure the release time of the timing release task, and the fourth operation is used to confirm the configuration of the timing release task; in response to the fourth operation, a task configuration message is sent to the third server, wherein the task configuration message is used to instruct the third server to configure the timing release task, and the release time is carried in the task configuration message.

[0117] The timing release task can be configured through the task configuration interface of the second client, and the task configuration interface is the configuration interface of the timing release task of the target mini-program. The target area for configuring the release time corresponding to the timing release task is included in the interface, and the confirm button for confirming the configuration of the timing task can also be displayed.

[0118] It should be noted that the second client and the first client can be the same client (for example, the client of the same related personnel), or different clients (for example, the client of different related personnel), which is not limited in the embodiment.

[0119] The terminal device running the second client can detect the third operation performed on the target area, and the third operation is used to configure the release time of the timing release task. The fourth operation performed on the confirm button can also be detected, and the fourth operation is used to confirm the configuration of the timing release task.

[0120] After detecting the fourth operation performed on the determination button, in response to the fourth operation, the terminal device running the second client can send a task configuration message to the third server to instruct the third server to configure a timing publishing task, and the timing publishing task corresponding to the timing publishing task is carried in the task configuration message. The third server can be the associated server of the target applet.

[0121] For example, the task interface corresponding to the configured timing publishing task is as shown in Figure 6 The task interface includes a task instruction, a time parameter, a task state, and an operation button, wherein,

[0122] The task instruction is automatic publishing.

[0123] The time parameter includes: o (cron, timing instruction), daily publishing time (for example, 12, 15, 18, 21; 12), week identifier (for example, "3" represents Wednesday, "2" represents Tuesday, and "4" represents Thursday), for example, the time parameter "o12,15,18,21**3" represents the version publishing of the target applet at 12 o'clock, 15 o'clock, 18 o'clock and 21 o'clock every Wednesday.

[0124] The task state indicates whether the task is currently in a start state (corresponding to "1") or an unstarted state (corresponding to "0").

[0125] The operation button includes an "edit" button for an editing interface of the timing publishing task, a "restart" button for restarting the timing publishing task, and a "pause" button for pausing the timing publishing task.

[0126] Through the embodiment, the configuration of the timing publishing task is performed through the task configuration interface, the configuration operation is simple, the configuration efficiency of the timing publishing task can be improved, and the user experience is improved.

[0127] As another optional implementation, before obtaining the first version data to be published by the target applet, the above method further includes:

[0128] S41, displaying a version publishing interface of the target applet through the third client, wherein the version publishing interface is a publishing interface of the program version of the target applet;

[0129] S42, detecting a second operation performed on a target button in the version publishing interface, wherein the second operation is used to trigger publishing of the first program version.

[0130] S43, in response to the second operation, sending a version publishing instruction to the second server to trigger the second server to obtain the first version data.

[0131] The program version of the target applet can be manually published through a version publishing interface of the third client, which is a version publishing interface of the program version of the target applet. The version publishing interface can display a target button, which can be used to determine the program version of the target applet to be published.

[0132] It should be noted that the third client and the first client can be the same client (for example, the client of the same relevant personnel) or different clients (for example, the client of different relevant personnel), and the embodiment is not limited in this regard.

[0133] The terminal device running the third client can detect a second operation performed on the target button to trigger the publishing of the first program version. The second operation can be a click operation, a double-click operation, a sliding operation, or other operations, and the embodiment is not limited in this regard.

[0134] After detecting the second operation performed on the target button, the terminal device running the third client can send a version publishing instruction to the second server in response to the second operation to trigger the second server to obtain the first version data. The second server can be the associated server of the target applet.

[0135] For example, the version publishing interface of the target applet can be as shown in Figure 7 The version publishing interface is a PRD (Production System) manual publishing interface. In the version publishing interface, the target version identifier can be automatically input or manually input in the first input box. The second input box can input the publishing description information, that is, the information related to the description of this publishing, for example, the description information of the publisher. The version publishing interface also includes a "publish" button (target button) for triggering the version publishing. In addition, the client of the applet publishing system can also include a preview interface, a UAT (User Acceptance Testing) publishing interface, and a PRD emergency repair. The PRD emergency repair can be repaired by the incremental update of the sub-code repository.

[0136] Through the embodiment, the manual publishing of the program version of the target applet through the version publishing interface is simple, and the efficiency of manually publishing the program version is improved, the user experience is improved, and the control ability of the version publishing is improved.

[0137] As an optional embodiment, after uploading the first version data to the first server, the above method further includes:

[0138] S51, receiving the exception indication information returned by the first server, wherein the exception indication information is used to indicate that the first version data uploading is abnormal;

[0139] S52, detecting the state indication information of the first version data from the webpage end of the first server, wherein the state indication information is used to indicate the uploading state of the first version data;

[0140] S53, in the case that the exception indication information and the state indication information match, determining that the first version data uploading is abnormal.

[0141] The related personnel of the target mini-program can configure the processing rule of the uploading exception, and the processing rule of the uploading exception can be used to indicate the operation performed in the case that the version data uploading is abnormal. The uploading exception can be determined by the following manners: the notification message of the uploading exception received by the associated server of the target mini-program, and the notification message of the uploading result is not received within the target time.

[0142] Optionally, in the embodiment, the associated server of the target mini-program can receive the exception indication information returned by the first server, and the exception indication information is used to indicate that the first version data uploading is abnormal. The uploading exception can include but is not limited to: a certain code line fails to be uploaded, and the version data fails to be successfully uploaded. Based on the processing rule of the uploading exception, the associated server of the target mini-program can detect the state indication information of the first version data from the webpage end of the first server, and the state indication information is used to indicate the uploading state of the first version data.

[0143] Since the exception indication information returned by the first server cannot necessarily reflect the actual situation of the version data uploading, that is, the version data has been successfully uploaded, but the first server returns the exception indication information. By detecting the webpage end of the first server, the actual situation of the version data uploading can be obtained, that is, the state indication information.

[0144] If the exception indication information and the state indication information match, it is determined that the first version data uploading is abnormal, the related personnel of the target mini-program can be notified, and the related personnel of the target mini-program is reminded to re-upload the first version data, or to re-upload the first version data after updating.

[0145] If the exception indication information and the state indication information do not match, it is determined that the first version data has been successfully uploaded, and the exception indication information can be ignored, and subsequent operations are continued.

[0146] Through the embodiment, by detecting the uploading result of the version data from the webpage end of the server, the accuracy of the version data uploading state acquisition can be ensured, unnecessary operations of the user are reduced, and the use experience of the user is improved.

[0147] As an optional embodiment, obtaining the audit result of the first version data comprises:

[0148] S61, starting a page refreshing task, wherein the page refreshing task is used to periodically refresh the webpage end to obtain the page data corresponding to the webpage end.

[0149] S62, in the case that the target page state identifier is contained in the page data, determining the audit result of the first version data according to the target page state identifier.

[0150] In order to obtain the audit result of the first version data, the associated server of the target applet can start a page refreshing task (for example, a polling task), which can be used to periodically refresh the aforementioned webpage end to obtain the page data corresponding to the webpage end.

[0151] If the audit is completed, the webpage end will be identified by the target page state identifier (for example, a page label), which is used to indicate that the first version data (the first program version) has been audited, and different values of the target page state identifier can represent different audit results, for example, "1" represents that the audit is passed, and "0" represents that the audit is failed.

[0152] If it is detected that the target page state identifier is contained in the page data, the associated server of the target applet can determine the audit result of the first version data.

[0153] Through the present embodiment, the page data of the webpage end is obtained by the page refreshing task at regular intervals, and the audit result is determined according to the page state identifier, which can improve the timeliness of information acquisition and improve the efficiency of program version release.

[0154] The processing method of version data in the embodiments of the present application will be explained and described below in combination with optional examples. In the present example, the target application program is an instant messaging application.

[0155] The processing method of version data in the present example is a small program publishing scheme based on Gitlab CI, which combines Gitlab CI and developer tools, and is based on Windows Server, NodeJS, Vue, Ant design, Puppeteer and other technology selection, can configure automatic publishing tasks on Gitlab CI, through the use of small program publishing platform and the interaction of all parties, can support small program publishing of multiple Git code repositories, one-key publishing, automatic publishing, automatic review, automatic version management, online code patch type update and other functions.

[0156] The small program publishing platform in the present example can be as follows Figure 8As shown, the publishing system B-end is the client (browser-based) of the mini-program publishing system; the system interface can be as follows: Figure 7 As shown, the target mini-program's associated server is Windows Server, and the target application's associated server is the backend server of the instant messaging application. The URL of this backend server can be: xx.yy.zz.com.

[0157] Start a NodeJS service (corresponding to a Koa instance) on Windows Server. The NodeJS service proxies the SPA (corresponding to a Vue build dist SPA), serving as the entry point for the browser (the publishing system B-end) to access this platform (the mini-program publishing platform). The publishing system B-end and NodeJS can interact via requests / sockets and status postbacks.

[0158] With developer tools installed on a Windows Server virtual machine, NodeJS can trigger upload requests to the backend server of the instant messaging application to upload the target mini-program's version data. The uploaded version data can be pulled from the code repository (gitlab.oa.com) by NodeJS, and version logs and other version records can be stored in a database (MongoDB). The version data in the target mini-program can be stored in multiple code repositories (sub-repositories), and the data in these repositories can be retrieved from the browser and pushed by NodeJS.

[0159] Furthermore, on Windows Server, Puppeteer can simulate user actions in a browser (web version, xx.yy.zz.com) to submit uploaded version data to the developer platform for review. The operation of the Koa instance can be monitored using a monitoring tool (PM2, Performance Monitor 2).

[0160] For a version of a target mini-program, the version data can go through four stages from start to official release: the development environment for developers, the Git environment, the testing environment, and the production environment. For the testing environment, the test environment code can be automatically released daily and updated hourly. The version data processing method in this optional example mainly involves the version data release process from the Git environment to the production environment.

[0161] like Figure 9 As shown, the process of processing version data in this optional example may include the following steps:

[0162] Step S902, the NodeJS service starts the scheduled publishing task configured on the webpage.

[0163] A scheduled publishing task can be configured for the target applet. As shown in Figure 6 , the scheduled publishing task is a task of publishing the program version of the target applet at a scheduled time.

[0164] Optionally, the program version of the target applet can also be manually published through a configuration interface as shown in Figure 7 . After inputting the publishing description, the publishing can be completed by clicking the publish button.

[0165] Step S904, according to the scheduled publishing task, pull the code of all associated repositories on gitlab.oa.com scheduled to be pulled, and perform pre-publishing construction on the code.

[0166] When the scheduled time corresponding to the scheduled publishing task arrives, the code of all associated repositories of the target applet on gitlab.oa.com can be pulled, and pre-publishing construction is performed using a construction process as shown in Figure 4 to obtain the version data to be published.

[0167] Step S906, after the construction is completed, the NodeJS service sends an HTTP request to the developer tool, and the developer tool uploads the code to the background server (xx.yy.zz.com).

[0168] Step S908, after the uploading is successful, the Puppeteer simulates the user's operation on the webpage of the background server (xx.yy.zz.com) to submit the uploaded version to the developer platform for review.

[0169] After the uploading is successful, a notification can be sent to the relevant personnel of the target applet through an instant messaging application. At the same time, the Puppeteer simulates the user's operation on the webpage of the background server (xx.yy.zz.com) to submit the submitted version to the developer platform for review.

[0170] In combination with the process of simulating browser operation by the Puppeteer as shown in Figure 10 , after the developer tool uploads the version data through the HTTP API, the Puppeteer can simulate the user's operation on the xx.yy.zz.com page to log in to the tool platform using a specific account and password, and submit the submitted version data to the developer platform for review.

[0171] Step S910, the Puppeteer starts a polling task to automatically refresh the developer platform page, and when a change in the page state is detected, sends a notification to the relevant member that the publishing can be performed.

[0172] In combination Figure 10 Puppeteer can poll for the review result: Puppeteer can start a polling task to automatically refresh the developer platform page. If a change in the page state is detected, i.e., the page contains a page tag indicating that the version has been reviewed, it can be determined that the program version has been reviewed and completed. Puppeteer can obtain a two-dimensional code that can be used to determine the release of the official version.

[0173] The relevant personnel of the target mini-program can be notified through the instant messaging application that the review has been completed, and the program version can be released.

[0174] Step S912, after the relevant members pass the experience version of the target mini-program, the version is released to the online environment.

[0175] The relevant members can test the experience version of the target mini-program to verify whether the functions of the program version to be released are normal, whether the mini-program is stable, etc. After verification, the two-dimensional code can be scanned through the instant messaging application to determine the release of the version to the online environment.

[0176] In addition, the Jenkins platform can also be used to complete the process of automatic release. The process of automatic release and review by the Jenkins platform is basically the same as that of Gitlab CI, and will not be described here.

[0177] Through the example, the freedom, flexibility and controllability of the program version release process of the mini-program can be realized, and the maintenance of the program version of the mini-program is facilitated.

[0178] It should be noted that, for each of the method embodiments described above, in order to simplify the description, they are all described as a series of action combinations, but those skilled in the art should know that the present application is not limited by the order of the described actions, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should know that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present application.

[0179] Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be realized by means of software on a general hardware platform as necessary, and of course can also be realized by hardware, but in many cases the former is a better embodiment. Based on such understanding, the technical solutions of the present application can be embodied in the form of a software product in essence or the part that contributes to the prior art, and the computer software product is stored in a storage medium (such as a ROM / RAM, a magnetic disk, or an optical disk), and includes a plurality of instructions for causing a terminal device (which can be a mobile phone, a computer, a server, or a network device) to execute the method described in each embodiment of the present application.

[0180] According to another aspect of the embodiments of the present application, a version data processing apparatus for implementing the above-mentioned version data processing method is also provided. Figure 11 is a structural block diagram of an optional version data processing apparatus according to an embodiment of the present application, as shown in the figure, the apparatus can include: Figure 11

[0181] (1) a first acquisition unit 1102, configured to acquire first version data of a target miniprogram, wherein the target miniprogram is an installation-free subprogram running in a target application program, and the first version data is code data of a first program version to be published by the target miniprogram;

[0182] (2) an uploading unit 1104, connected with the first acquisition unit 1102, configured to upload the first version data to a first server, wherein the first server is a server corresponding to the target application program;

[0183] (3) a triggering unit 1106, connected with the uploading unit 1104, configured to simulate a target operation performed on a web end of the first server, and trigger sending of an audit request to the first server, wherein the audit request is used to request auditing of the first version data;

[0184] (4) a second acquisition unit 1108, connected with the triggering unit 1106, configured to acquire an audit result of the first version data, wherein the audit result is used to indicate whether the auditing of the first version data is passed.

[0185] It should be noted that the first acquisition unit 1102 in this embodiment can be used to execute the above-mentioned step S202, the uploading unit 1104 in this embodiment can be used to execute the above-mentioned step S204, the triggering unit 1106 in this embodiment can be used to execute the above-mentioned step S206, and the second acquisition unit 1108 in this embodiment can be used to execute the above-mentioned step S208.

[0186] ​The first version data of the target miniprogram is acquired through the above module, the target miniprogram is an installation-free subprogram running in a target application program, and the first version data is code data of a first program version to be published of the target miniprogram; the first version data is uploaded to a first server, the first server is a server corresponding to the target application program; a target operation performed on a webpage end of the first server is simulated to trigger sending of an audit request to the first server, the audit request is used to request auditing of the first version data; and an audit result of the first version data is acquired, the audit result is used to indicate whether the auditing of the first version data passes, thereby solving the problem of cumbersome operation of a publishing process due to only a single interface being used for publishing of a miniprogram in the related art, and improving the publishing efficiency of the miniprogram.

[0187] As an optional embodiment, the first acquisition unit 1102 includes:

[0188] The first pulling module is configured to pull main code data of the target miniprogram from a main code repository of the target miniprogram.

[0189] The second pulling module is configured to pull a plurality of subcode data of the target miniprogram from a plurality of subcode repositories of the target miniprogram respectively, the plurality of subcode repositories correspond to the plurality of subcode data one by one.

[0190] The merging module is configured to merge each subcode data in the plurality of subcode data into a code position corresponding to each subcode data in the main code data, and construct the first version data.

[0191] As an optional embodiment, the apparatus further includes:

[0192] The downloading unit is configured to download second version data through the target device before acquiring the first version data to be published of the target miniprogram, the second version data is code data of a second program version of the target miniprogram that has been published, the second program version includes a plurality of code branches, and each code branch in the plurality of code branches corresponds to code data of a different part in the second version data.

[0193] The first detection unit is configured to detect a first operation performed on a display interface of a first client, the first client runs on the target device, and the first operation is used to select a target branch to be updated from the plurality of code branches, the target branch corresponds to first code data in the second version data.

[0194] The first sending unit is configured to send an update instruction to a target code repository in response to the first operation, the target code repository being a code repository storing the first code data among the master code repository and the plurality of sub code repositories, the update instruction being used to instruct to update the first code data using the second code data, and the first version data including the second code data.

[0195] As an optional embodiment, the apparatus further includes:

[0196] The third obtaining unit is configured to obtain a timing publishing task configured by the second client before obtaining the first version data to be published by the target mini-program, the timing publishing task being used to publish a program version of the target mini-program at a timing;

[0197] The starting unit is configured to start the timing publishing task to publish the program version of the target mini-program at a timing indicated by the timing publishing task, the first program version being a program version published by the target mini-program once.

[0198] As an optional embodiment, the apparatus further includes:

[0199] The first display unit is configured to display a task configuration interface of the timing publishing task by the second client before obtaining the timing publishing task configured by the second client, the task configuration interface including a target area used to configure a publishing time corresponding to the timing publishing task;

[0200] The second detection unit is configured to detect a third operation performed on the target area and a fourth operation performed on a confirm button in the task configuration interface, the third operation being used to configure the publishing time of the timing publishing task, and the fourth operation being used to confirm the configuration of the timing publishing task.

[0201] The second sending unit is configured to send a task configuration message to the second server in response to the fourth operation, the task configuration message being used to instruct the second server to configure the timing publishing task, and the task configuration message carrying the publishing time.

[0202] As an optional embodiment, the apparatus further includes:

[0203] The second display unit is configured to display a version publishing interface of the target mini-program by the third client before obtaining the first version data to be published by the target mini-program, the version publishing interface being a publishing interface of the program version of the target mini-program.

[0204] The third detection unit is configured to detect a second operation performed on a target button in the version publishing interface, the second operation being used to trigger the publishing of the first program version.

[0205] The third sending unit is configured to send a version publishing instruction to the second server in response to the second operation, so as to trigger the second server to acquire the first version data.

[0206] As an optional embodiment, the apparatus further includes:

[0207] The receiving unit is configured to receive abnormal indication information returned by the first server after uploading the first version data to the first server, wherein the abnormal indication information is used to indicate an abnormality in uploading the first version data.

[0208] The detecting unit is configured to detect state indication information of the first version data from a webpage end of the first server, wherein the state indication information is used to indicate an uploading state of the first version data.

[0209] The determining unit is configured to determine that the uploading of the first version data is abnormal in a case where the abnormal indication information and the state indication information match.

[0210] As an optional embodiment, the second acquiring unit 1108 includes:

[0211] The starting module is configured to start a page refreshing task, wherein the page refreshing task is used to periodically refresh the webpage end and acquire page data corresponding to the webpage end.

[0212] The determining module is configured to determine an auditing result of the first version data according to the target page state identifier in a case where the page data includes the target page state identifier.

[0213] It should be noted that the above modules and examples and application scenarios realized by the corresponding steps are the same, but are not limited to the content disclosed in the above embodiments. It should be noted that the above modules as part of the apparatus can run in the hardware environment as shown in Figure 1 , and can be implemented by software or hardware, wherein the hardware environment includes a network environment.

[0214] According to another aspect of the embodiments of the present application, an electronic device for implementing the above-mentioned version data processing method is also provided, which can be a server, a terminal, or a combination thereof.

[0215] Figure 12 is a structural block diagram of an optional electronic device according to an embodiment of the present application, as shown in Figure 12 The electronic device includes a memory 1202 and a processor 1204, the memory 1202 stores a computer program, and the processor 1204 is configured to execute the steps in any method embodiment described above by the computer program.

[0216] Optionally, in the embodiment, the electronic device can be located in at least one of the plurality of network devices of the computer network.

[0217] Optionally, in the embodiment, the processor can be configured to perform the following steps by means of a computer program:

[0218] S1, obtaining first version data of a target applet, wherein the target applet is an installation-free subprogram running in a target application program, and the first version data is code data of a first program version to be published by the target applet;

[0219] S2, uploading the first version data to a first server, wherein the first server is a server corresponding to the target application program;

[0220] S3, simulating a target operation performed on a web page end of the first server, and triggering sending of an audit request to the first server, wherein the audit request is used to request auditing of the first version data;

[0221] S4, obtaining an audit result of the first version data, wherein the audit result is used to indicate whether the auditing of the first version data is passed.

[0222] The memory 1202 can be used to store software programs and modules, such as program instructions / modules corresponding to the version data processing method and device in the embodiments of the present application. The processor 1204 performs various functional applications and data processing by running the software programs and modules stored in the memory 1202, that is, implements the above-mentioned version data processing method. The memory 1202 can include a high-speed random access memory, and can also include a non-volatile memory, such as one or more magnetic storage devices, flash memories, or other non-volatile solid-state memories. In some examples, the memory 1202 can further include a memory remotely arranged with respect to the processor 1204, which can be connected to the terminal through a network. Examples of the above-mentioned network include but are not limited to the Internet, an intranet, a local area network, a mobile communication network, and a combination thereof. The memory 1202 can be used to store, but is not limited to, version data of a target applet and the like.

[0223] As an example, as shown in Figure 12 The memory 1202 can include, but is not limited to, the first obtaining unit 1102, the uploading unit 1104, the triggering unit 1106, and the second obtaining unit 1108 in the version data processing device. In addition, other module units in the version data processing device can also be included, but not limited to, which will not be described in detail in this example.

[0224] Optionally, the transmission device 1206 is configured to receive or send data via a network. Examples of the network can include a wired network and a wireless network. In an example, the transmission device 1206 includes a network interface controller (NIC) which can be connected to other network devices and routers through a network cable to communicate with the Internet or a local area network. In an example, the transmission device 1206 is a radio frequency (RF) module which is configured to communicate with the Internet in a wireless manner.

[0225] In addition, the electronic device further includes a connection bus 1208 which is configured to connect various module components in the electronic device.

[0226] Optionally, specific examples in the embodiments can refer to the examples described in the above embodiments, and details are not described herein again.

[0227] Those skilled in the art can understand that the above-described technical solutions have at least the following beneficial effects: Figure 12 The structure shown is only schematic, and the device for implementing the processing method of version data can be a terminal device, which can be a smart phone (such as an Android phone, an iOS phone, etc.), a tablet computer, a palm computer, a mobile internet device (MID), a PAD, etc. Figure 12 This does not limit the structure of the electronic device. For example, the terminal device can further include more or less components (such as a network interface, a display device, etc.) than those shown in the figure, or have a different configuration from that shown in the figure. Figure 12 Figure 12

[0228] Those skilled in the art can understand that all or part of the steps in the various methods of the above embodiments can be completed by programs instructing the related hardware of the terminal device, and the programs can be stored in a computer readable storage medium, which can include a flash disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.

[0229] According to another aspect of the embodiments of the present application, a storage medium is further provided. Optionally, in the embodiments, the storage medium can be used to store program codes for implementing the processing method of version data.

[0230] Optionally, in the embodiments, the storage medium can be located on at least one of the network devices in the network shown in the above embodiments.

[0231] ​​Optionally, in the embodiment, the storage medium is configured to store program code for performing the following steps:

[0232] S1, obtaining first version data of a target applet, wherein the target applet is an installation-free subprogram running in a target application program, and the first version data is code data of a first program version to be published of the target applet;

[0233] S2, uploading the first version data to a first server, wherein the first server is a server corresponding to the target application program;

[0234] S3, simulating a target operation performed on a web end of the first server, and triggering sending of an audit request to the first server, wherein the audit request is used to request auditing of the first version data;

[0235] S4, obtaining an audit result of the first version data, wherein the audit result is used to indicate whether the auditing of the first version data passes.

[0236] Optionally, specific examples in the embodiment can refer to examples described in the above embodiments, and details are not described herein.

[0237] Optionally, in the embodiment, the storage medium can include but is not limited to a U disk, a ROM, a RAM, a mobile hard disk, a magnetic disk or an optical disk, and various storage medium that can store program code.

[0238] According to still another aspect of the embodiments of the present application, a computer program product or computer program is provided, which includes computer instructions stored in a computer readable storage medium; a processor of a computer device reads the computer instructions from the computer readable storage medium, and the processor executes the computer instructions, so that the computer device executes steps of any embodiment of the version data processing method.

[0239] The above sequence numbers of the embodiments of the present application are only for description, and do not represent advantages or disadvantages of the embodiments.

[0240] The integrated units in the above embodiments, if realized in the form of software function units and sold or used as independent products, can be stored in the above computer readable storage medium. Based on such understanding, the technical solutions of the present application essentially or the parts that make contributions to the prior art or the whole or part of the technical solutions can be embodied in the form of software product, and the computer software product is stored in the storage medium, including a plurality of instructions for causing one or more computer devices (which can be personal computers, servers or network devices, etc.) to execute all or part of the steps of the methods described in the embodiments of the present application.

[0241] In the above-described embodiments of the present application, the description of each embodiment is focused on, and the part not described in detail in a certain embodiment can be referred to the relevant description of other embodiments.

[0242] In several embodiments provided in the present application, it should be understood that the disclosed client can be implemented by other manners. Among them, the above-described device embodiments are only schematic, for example, the division of the units is only a logical function division, and actual implementation can have another division manner, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the displayed or discussed each other can be indirect coupling or communication connection through some interfaces, units or modules, and can be electrical or other forms.

[0243] The units described as separate components can or can not be physically separated, and the components shown as units can or can not be physical units, that is, they can be located in one place, or can be distributed on a plurality of network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the scheme provided in the embodiments.

[0244] In addition, each functional unit in each embodiment of the present application can be integrated in one processing unit, or each unit can be physically present separately, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware or in the form of a software functional unit.

[0245] The above is only the preferred embodiment of the present application, and it should be pointed out that for ordinary skilled in the art, without departing from the principles of the present application, a number of improvements and refinements can be made, and these improvements and refinements should be considered as the protection scope of the present application.

Claims

1. A method for processing version data, characterized in that, include: Obtain the first version data of the target mini-program, wherein the target mini-program is a sub-program that runs within the target application without requiring installation, and the first version data is the code data of the first program version of the target mini-program to be released; The first version data is uploaded to the first server, wherein the first server is a server corresponding to the target application, and the first version data is uploaded through a communication connection between the associated server of the target mini-program and the first server. Simulate the target operation performed on the web page of the first server to trigger the sending of an audit request to the first server, wherein the audit request is used to request the audit of the first version data, and the target operation includes at least one of the following: logging into the web page using the target account and password, entering the audit submission page, and entering version association information on the audit submission page; Obtain the review result of the first version of the data, wherein the review result is used to indicate whether the review of the first version of the data has passed; If it is determined that the first version of the data has been reviewed and approved, then notify the release of the target mini-program version; The acquisition of the first version data of the target mini-program to be released includes: Retrieve the main code data of the target mini-program from its main code repository; Multiple sub-code data of the target mini-program are retrieved from multiple sub-code repositories of the target mini-program, wherein the multiple sub-code repositories and the multiple sub-code data correspond one-to-one; Each sub-code data in the plurality of sub-code data is merged into the code position corresponding to each sub-code data in the main code data to construct the first version data.

2. The method according to claim 1, characterized in that, Before obtaining the first version data of the target mini-program to be released, the method further includes: Download the second version data through the target device. The second version data is the code data of the second program version that has been released by the target mini program. The second program version contains multiple code branches, and each of the multiple code branches corresponds to a different part of the code data in the second version data. A first operation is detected on the display interface of the first client, wherein the first client runs on the target device, and the first operation is used to select a target branch to be updated from the plurality of code branches, wherein the target branch corresponds to the first code data in the second version data; In response to the first operation, an update instruction is sent to the target code repository, wherein the target code repository is the code repository in the main code repository and the plurality of sub-code repositories that stores the first code data, and the update instruction is used to instruct the first code data to be updated with second code data, wherein the first version data includes the second code data.

3. The method according to claim 1, characterized in that, Before obtaining the first version data of the target mini-program to be released, the method further includes: Obtain the scheduled release task configured through the second client, wherein the scheduled release task is used to release the program version of the target mini-program at regular intervals; The scheduled release task is initiated to release the program version of the target mini-program at the release time indicated by the scheduled release task, wherein the first program version is a program version released by the target mini-program.

4. The method according to claim 1, characterized in that, Before obtaining the first version data of the target mini-program to be released, the method further includes: The version release interface of the target mini-program is displayed through a third client, wherein the version release interface is the program version release interface of the target mini-program; A second operation is detected performed on the target button in the version release interface, wherein the second operation is used to trigger the release of the first program version; In response to the second operation, a version release instruction is sent to the second server to trigger the second server to obtain the first version data.

5. The method according to claim 1, characterized in that, After uploading the first version data to the first server, the method further includes: Receive the exception indication information returned by the first server, wherein the exception indication information is used to indicate that the first version of data upload is abnormal; The status indication information of the first version data is detected from the web page of the first server, wherein the status indication information is used to indicate the upload status of the first version data; If the anomaly indication information and the status indication information match, it is determined that the first version of the data upload is abnormal.

6. The method according to any one of claims 1 to 5, characterized in that, The process of obtaining the audit results for the first version of the data includes: Initiate a page refresh task, wherein the page refresh task is used to periodically refresh the web page and obtain page data corresponding to the web page; If the page data contains a target page status identifier, the review result for the first version of the data is determined based on the target page status identifier.

7. A version data processing apparatus, characterized in that, include: The first acquisition unit is used to acquire the first version data of the target mini-program, wherein the target mini-program is a sub-program that runs within the target application without installation, and the first version data is the code data of the first program version of the target mini-program to be released; An upload unit is used to upload the first version data to a first server, wherein the first server is a server corresponding to the target application, and the first version data is uploaded through a communication connection between the associated server of the target mini-program and the first server. The triggering unit is used to simulate the target operation performed on the web page of the first server and trigger the sending of an audit request to the first server. The audit request is used to request the audit of the first version data. The target operation includes at least one of the following: logging into the web page using the target account and password, entering the audit submission page, and entering version association information on the audit submission page. The second acquisition unit is used to acquire the review result of the first version data, wherein the review result is used to indicate whether the review of the first version data has passed; if it is determined that the first version data has been reviewed and approved, then the release of the target mini-program version is notified. Wherein, the first acquisition unit is used for: Retrieve the main code data of the target mini-program from its main code repository; Multiple sub-code data of the target mini-program are retrieved from multiple sub-code repositories of the target mini-program, wherein the multiple sub-code repositories and the multiple sub-code data correspond one-to-one; Each sub-code data in the plurality of sub-code data is merged into the code position corresponding to each sub-code data in the main code data to construct the first version data.

8. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, wherein the computer program is configured to execute the method described in any one of claims 1 to 6 when it is run.

9. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to execute the method described in any one of claims 1 to 6 through the computer program.

10. A computer program product or computer program comprising computer instructions stored in a computer-readable storage medium; a processor of a computer device reading the computer instructions from the computer-readable storage medium, the processor executing the computer instructions to cause the computer device to perform the method of any one of claims 1 to 6.

Images