Hot update test methods and apparatus, electronic equipment, storage media

Abstract

This application provides a hot update testing method, apparatus, electronic device, and storage medium. The method includes: responding to a hot update command for an SVN repository, generating a corresponding hot update repair file based on the hot update command; sending the hot update repair file to a corresponding hot update repair branch in a Git repository, and combining it with a baseline package corresponding to the hot update repair branch to generate a hot update repair package to be tested; the SVN repository and the Git repository correspond to the same application; after the hot update repair package is successfully tested, merging the hot update repair file into the corresponding main branch of the Git repository, and generating a corresponding target package for external release. This application's embodiments combine the strengths of SVN and Git repositories, achieving both compliance with most users' habits of using SVN repositories and improved testing efficiency and reduced probability of code errors in externally released packages through Git repository branch management functionality.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to hot update testing methods and apparatus, electronic devices, and storage media. Background Technology

[0002] Mobile games have become an increasingly common form of entertainment, and with the continuous expansion of the game market, competition in the game industry is becoming increasingly fierce. In order to retain players and attract more players, most games adopt a weekly version update approach (that is, update the game content every 7 days) to ensure that players can experience more new content without updating the game application version; this method of updating application content without releasing a new version is called hot update.

[0003] Currently, the common method for testing hot updates of applications is to conduct hot update tests based on SVN (Subversion, an open-source version control system) repositories.

[0004] Programmers need to commit code to the SVN repository for testing. When hot-update content is already being tested, later commits cannot be released independently; they must wait for the earlier commits to complete testing before being released together, resulting in low testing efficiency. Furthermore, after testing, programmers need to recompile the release package. If a programmer mistakenly commits code at this time, incorrect content may be released, posing a product quality risk. Summary of the Invention

[0005] In view of the above problems, this application is made to provide a hot-replacement testing method and apparatus, electronic equipment, and storage medium that overcome or at least partially solve the above problems, including:

[0006] A hot update testing method, the method comprising:

[0007] In response to a hot update command for an SVN repository, a corresponding hot update repair file is generated based on the hot update command.

[0008] The hot update fix file is sent to the hot update fix branch corresponding to the Git repository, and combined with the baseline package corresponding to the hot update fix branch, a hot update fix package to be tested is generated; the SVN repository and the Git repository correspond to the same application;

[0009] After the hot update repair package is successfully tested, the hot update repair file is merged into the main branch corresponding to the Git repository, and a corresponding target package for external release is generated.

[0010] Optionally, the step of generating a corresponding hot update repair file based on a hot update command for an SVN repository in response to the hot update command further includes:

[0011] Determine whether the hot update instruction carries hot update order number information;

[0012] If so, then obtain the hot update repair code corresponding to the hot update order number information;

[0013] Generate the corresponding hot update repair file based on the hot update repair code.

[0014] Optionally, before sending the hot update fix file to the corresponding hot update fix branch in the Git repository, and combining it with the baseline package body corresponding to the hot update fix branch to generate the hot update fix package body to be tested, the method further includes:

[0015] Create a hot update repair branch corresponding to the current hot update cycle. The baseline package corresponding to the hot update repair branch is the package obtained at the end of the previous hot update cycle for external release.

[0016] Optionally, after the hot update repair package body test is successful, generating a target package body corresponding to the hot update repair file for external release includes:

[0017] After the hot update repair package body test is successful, a request to merge the hot update repair file is received.

[0018] Based on the merge request, the hot update fix file is merged into the main branch corresponding to the Git repository, and a corresponding target package for external release is generated.

[0019] Optionally, the merge request carries the hot update order number information, and based on the merge request, the hot update fix file is merged into the main branch corresponding to the Git repository, and a corresponding target package for external release is generated, including:

[0020] Determine whether the status information of the hot update request order corresponding to the hot update order number is "test successful";

[0021] If so, based on the merge request, the hot update fix file is merged into the main branch corresponding to the Git repository, and a corresponding target package for external release is generated.

[0022] Optionally, after merging the hot update fix file into the main branch corresponding to the Git repository based on the merge request and generating the corresponding target package for external release, the method further includes:

[0023] The target package is sent to the corresponding target server to trigger the target server to perform a hot update of the application based on the target package.

[0024] Optionally, sending the target packet body to the corresponding target server further includes:

[0025] Determine whether the status information of the hot update request corresponding to the target package is "test successful";

[0026] If so, the target packet body is sent to the corresponding target server.

[0027] Optionally, the method further includes:

[0028] If the hot update repair package test fails, roll back the code in the SVN repository corresponding to the hot update instruction.

[0029] Optionally, the step of generating a corresponding hot update repair file based on a hot update command for an SVN repository in response to the hot update command further includes:

[0030] If the hot update command does not carry hot update order number information, a first prompt message is generated, which is used to indicate that there is an error in the hot update command.

[0031] A hot-renewal testing apparatus, the apparatus comprising:

[0032] The hot update repair file generation module is used to respond to a hot update command for an SVN repository and generate a corresponding hot update repair file according to the hot update command.

[0033] The hot update fix package generation module is used to send the hot update fix file to the hot update fix branch corresponding to the Git repository, so as to generate the hot update fix package to be tested by combining it with the baseline package corresponding to the hot update fix branch; the SVN repository and the Git repository correspond to the same application;

[0034] The target package generation module is used to merge the hot update repair file into the main branch corresponding to the Git repository after the hot update repair package test is successful, and generate the corresponding target package for external release.

[0035] Optionally, the hot update repair file generation module further includes:

[0036] The first judgment module is used to determine whether the hot update instruction carries hot update order number information;

[0037] The hot update repair code acquisition module is used to acquire the hot update repair code corresponding to the hot update order number information if the condition is met.

[0038] The hot update repair file determination module is used to generate the corresponding hot update repair file based on the hot update repair code.

[0039] Optionally, the device further includes:

[0040] The hot update repair branch creation module is used to create a hot update repair branch corresponding to the current hot update cycle. The baseline package corresponding to the hot update repair branch is the package obtained at the end of the previous hot update cycle for external release.

[0041] Optionally, the target package generation module includes:

[0042] The merge request receiving module is used to receive a merge request for the hot update repair file after the hot update repair package body test is successful.

[0043] The hot update fix file merging module is used to merge the hot update fix file into the main branch corresponding to the Git repository based on the merging request, and generate the corresponding target package for external release.

[0044] Optionally, the merge request carries the hot update order number information, and the hot update repair file merge module includes:

[0045] The second judgment module is used to determine whether the status information of the hot update request order corresponding to the hot update order number information is "test successful";

[0046] The file merging module is used to merge the hot update fix file into the main branch corresponding to the Git repository based on the merging request if the request is true, and generate a corresponding target package for external release.

[0047] Optionally, the device further includes:

[0048] The target package external release module is used to send the target package to the corresponding target server to trigger the target server to perform a hot update of the application based on the target package.

[0049] Optionally, the target package external projection module further includes:

[0050] The third judgment module is used to determine whether the status information of the hot update request corresponding to the target package is "test successful";

[0051] The target packet sending module is used to send the target packet to the corresponding target server if the condition is met.

[0052] Optionally, the device further includes:

[0053] The failure rollback module is used to roll back the code corresponding to the hot update instruction in the SVN repository after the hot update repair package test fails.

[0054] Optionally, the hot update repair file generation module further includes:

[0055] The error message module is used to generate a first message if the hot update instruction does not carry a hot update order number. The first message indicates that there is an error in the hot update instruction.

[0056] An electronic device includes a processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein the computer program, when executed by the processor, implements the steps of the hot update test method as described above.

[0057] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the hot update test method as described above.

[0058] This application has the following advantages:

[0059] In the embodiments of this application, in response to a hot update command for an SVN repository, a corresponding hot update fix file is generated according to the hot update command; the hot update fix file is sent to the hot update fix branch corresponding to the Git repository, and combined with the baseline package corresponding to the hot update fix branch, a hot update fix package to be tested is generated; the SVN repository and the Git repository correspond to the same application; after the hot update fix package is successfully tested, the hot update fix file is merged into the main branch corresponding to the Git repository, and a corresponding target package for external release is generated. This embodiment of the application combines the advantages of SVN and Git repositories, achieving both compliance with the usage habits of most users of SVN repositories and improved testing efficiency and reduced probability of code errors in external packages through the branch management function of Git repositories. Attached Figure Description

[0060] To more clearly illustrate the technical solution of this application, the drawings used in the description of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0061] Figure 1 This is a flowchart illustrating the steps of a hot update testing method according to an embodiment of this application;

[0062] Figure 2This is a schematic diagram of package body management in one embodiment of this application;

[0063] Figure 3 This is a schematic diagram of the hot update repair package generation process in one embodiment of this application;

[0064] Figure 4 This is a schematic diagram of the test process in one embodiment of this application;

[0065] Figure 5 This is a structural block diagram of a hot-update testing device according to an embodiment of this application. Detailed Implementation

[0066] To make the above-mentioned objectives, features, and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0067] First, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be subject to the following interpretations.

[0068] Hot update: This refers to modifying game content using code mechanisms without releasing a new version, enabling dynamic modification of content for external servers.

[0069] SVN: short for Subversion, is an open-source centralized version control system.

[0070] Git is an open-source distributed version control system.

[0071] GitLab is an open-source project for repository management systems. It uses Git as the code management tool and builds a web service on top of it.

[0072] Existing hot update testing methods are based on a single SVN repository. When multiple hot update requests exist simultaneously, SVN branching becomes costly and inefficient, making parallel processing difficult and hot update testing inefficient. Furthermore, after hot update testing is completed, programmers need to recompile and release the package. The lack of corresponding monitoring measures during this process can easily lead to the release of incorrect, untested content, posing a product quality risk.

[0073] Therefore, embodiments of this application provide a hot update testing method to overcome the deficiencies of the prior art.

[0074] Reference Figure 1This diagram illustrates a flowchart of a hot update testing method according to an embodiment of this application. This method can be applied to a hot update testing system, which may include multiple terminal devices, an SVN repository, and a Git repository; the SVN repository and the Git repository correspond to the same application.

[0075] The terminal device can be an electronic device such as a desktop computer, laptop computer, tablet computer, smartphone, or personal digital assistant. The terminal device can have a client installed and running for application developers to maintain and update the target application. The SVN repository serves as the daily code maintenance repository for the target application, while the Git repository serves as the dedicated repository for hot updates of the target application.

[0076] This method may specifically include the following steps:

[0077] Step 101: In response to the hot update command for the SVN repository, generate the corresponding hot update repair file according to the hot update command;

[0078] Step 102: Send the hot update fix file to the hot update fix branch corresponding to the Git repository, so as to generate a hot update fix package to be tested by combining it with the baseline package corresponding to the hot update fix branch; the SVN repository and the Git repository correspond to the same application;

[0079] Step 103: After the hot update repair package is successfully tested, merge the hot update repair file into the main branch corresponding to the Git repository and generate the corresponding target package for external release.

[0080] In this embodiment, in response to a hot update command for an SVN repository, a corresponding hot update fix file is generated based on the hot update command. The hot update fix file is sent to the corresponding hot update fix branch in the Git repository, and combined with the baseline package corresponding to the hot update fix branch, a hot update fix package to be tested is generated. The SVN repository and the Git repository correspond to the same application. After the hot update fix package is successfully tested, the hot update fix file is merged into the corresponding main branch of the Git repository, and a corresponding target package for external release is generated. This embodiment combines the advantages of SVN and Git repositories, achieving both compliance with the usage habits of most users of SVN repositories and improved testing efficiency and reduced probability of code errors in external packages through the branch management function of Git repositories.

[0081] The hot update test method in this exemplary embodiment will now be further described.

[0082] In step 101, in response to a hot update command for the SVN repository, a corresponding hot update repair file is generated according to the hot update command.

[0083] In this embodiment, the hot update testing system can connect to the target server running the target application via a wireless or wired network. When the application developers determine that the target application requires a hot update, the planners among the developers can submit corresponding hot update request forms for each hot update requirement. The programmers then write the corresponding hot update fix code for each hot update requirement. After completing the hot update fix code, the programmers send a hot update command to the SVN repository via a corresponding terminal device to submit the completed hot update fix code to the SVN repository.

[0084] After detecting a hot update command for an SVN repository, the hot update testing system generates a corresponding hot update repair file based on the command, so that subsequent steps such as testing and packaging of the hot update repair file can be performed.

[0085] To make the hot update testing process transparent and facilitate information synchronization, in an optional embodiment of this application, the process of generating the corresponding hot update repair file according to the hot update instruction may specifically include:

[0086] Determine whether the hot update instruction carries hot update order number information;

[0087] If so, then obtain the hot update repair code corresponding to the hot update order number information;

[0088] Generate the corresponding hot update repair file based on the hot update repair code.

[0089] In this embodiment of the application, it is necessary to ensure that the hot update repair code submitted to the SVN repository is traceable. Therefore, it is necessary to determine whether the hot update command carries hot update order number information. If the hot update command carries hot update order number information, the corresponding hot update repair code can be obtained according to the hot update order number information, and then the hot update repair file corresponding to the hot update order number information can be generated by executing the generation script.

[0090] Specifically, when submitting a hot update fix file, programmers need to specify the corresponding hot update request, i.e., specify the hot update request form. Therefore, it can be determined whether the hot update command carries a hot update request number by checking whether the commit log corresponding to the hot update command contains a hot update request number.

[0091] It should be noted that the same hot update order number corresponds to the same hot update requirement, and the same hot update order number can correspond to multiple hot update commands. In other words, the same hot update order number can correspond to multiple hot update fix codes. Therefore, it is possible to obtain all hot update fix codes associated with the hot update order number in the hot update command, and generate the hot update fix file corresponding to that hot update order number based on the obtained hot update fix codes.

[0092] For example, programmer A modifies lines 10-12 of the file a.py for a specific hot update requirement; programmer B, also modifying lines 15-16 of the same file for the same hot update requirement. Therefore, the hot update commands sent by programmers A and B to the SVN repository carry the same hot update tracking number. If programmer A sends the hot update command to the SVN repository later than programmer B, upon detecting programmer A's hot update command for the SVN repository, the hot update tracking number corresponding to that command can be used to obtain the hot update fix code, including lines 10-12 and lines 15-16 of the a.py file. Finally, a corresponding hot update fix file is generated using a script.

[0093] Furthermore, if the hot update instruction does not carry hot update order number information, a first prompt message is generated, which is used to indicate that there is an error in the hot update instruction.

[0094] In this embodiment, when a programmer submits a hot update repair file, if no corresponding hot update request is specified (i.e., the hot update instruction does not carry a hot update request number), a first prompt message will be generated. This first prompt message indicates that the hot update instruction contains an error; more specifically, it can indicate that the hot update instruction lacks a hot update request number. This first prompt message can be displayed on the screen of the terminal device corresponding to the hot update instruction, so that the programmer can modify and resubmit it.

[0095] In step 102, the hot update repair file is sent to the hot update repair branch corresponding to the Git repository, so as to generate a hot update repair package to be tested by combining it with the baseline package corresponding to the hot update repair branch; the SVN repository and the Git repository correspond to the same application.

[0096] This application uses a Git repository to manage hot updates of the target application. Therefore, after generating the hot update fix file, it needs to be sent to the corresponding hot update fix branch in the Git repository to trigger GitLab to combine the baseline package corresponding to that hot update fix branch and generate the hot update fix package to be tested. It should be noted that this hot update fix branch is a copy of the main hot update fix branch in the Git repository. One hot update requirement corresponds to one hot update fix branch.

[0097] In an optional embodiment of this application, before sending the hot update fix file to the hot update fix branch corresponding to the Git repository, and combining it with the baseline package corresponding to the hot update fix branch to generate the hot update fix package to be tested, the method further includes:

[0098] Create a hot update repair branch corresponding to the current hot update cycle. The baseline package corresponding to the hot update repair branch is the package obtained at the end of the previous hot update cycle for external release.

[0099] The package body used for external release refers to the package body sent to the target server running the application during the hot update process. At the end of each hot update cycle, the package body used for external release for that cycle is obtained. In this embodiment, the package body used for external release obtained at the end of each hot update cycle is used as the baseline package body for the next adjacent hot update cycle.

[0100] In this embodiment, at the end of the previous hot update cycle (i.e., at the beginning of the current hot update cycle), a hot update repair branch corresponding to the current hot update cycle is created locally on the terminal device used by the programmer. The baseline package corresponding to this hot update repair branch is the package obtained at the end of the previous hot update cycle for external release. It should be noted that in other examples, the hot update repair branch corresponding to the current hot update cycle can also be created when a hot update requirement arises during the current hot update cycle; this application does not limit this.

[0101] It is understandable that the baseline package remains unchanged during a hot update cycle; that is, during a hot update cycle, different hot update requirements correspond to different hot update repair branches, but the baseline package corresponding to different hot update repair branches is the same.

[0102] In step 103, after the hot update repair package test is successful, the hot update repair file is merged into the main branch corresponding to the Git repository, and a corresponding target package for external release is generated.

[0103] In this embodiment, after the hot update patch package test is successful, the hot update patch file corresponding to the hot update patch package can be merged into the main branch of the Git repository, and a corresponding target package for external release can be generated. It can be understood that before merging the hot update patch file, the package corresponding to the main branch of the Git repository is consistent with the package used by the target server.

[0104] For example, after generating the hot update patch package to be tested, the program tester can synchronize the hot update patch package to be tested to the terminal device they are using, so as to test the hot update patch package to be tested on the terminal device they are using.

[0105] When a test is successful, the tester can send feedback information indicating the success via their terminal device. When the hot update testing system receives this feedback, it can determine the corresponding hot update fix package, and based on the hot update fix file, merge the hot update fix file into the corresponding main branch of the Git repository, and generate the corresponding target package for external release.

[0106] In an optional embodiment, the process of merging the hot update repair file into the main branch corresponding to the Git repository and generating a corresponding target package for external release after the hot update repair package test is successful includes:

[0107] After the hot update repair package body test is successful, a request to merge the hot update repair file is received.

[0108] Based on the merge request, the hot update fix file is merged into the main branch corresponding to the Git repository, and a corresponding target package for external release is generated.

[0109] In this embodiment, the generation of the target package is based on a received merge request, which is typically sent by the programmer through their terminal device. This allows the programmer to further determine whether to continue generating the corresponding target package.

[0110] For example, after a hot update patch package test is successful, the terminal device used by the programmer corresponding to the hot update patch package can display feedback information indicating the test success. For instance, the test result can be displayed through the status of the hot update request form corresponding to the hot update patch package. When the programmer sees the feedback information indicating the hot update patch package test is successful, they can further determine whether it is necessary to generate the target package corresponding to the hot update file of the hot update patch package. When the programmer determines that it is necessary to generate the target package, they can send a merge request through their terminal device to trigger the hot update test system to merge the corresponding hot update patch file into the main branch of the Git repository, and then package it to generate the corresponding target package.

[0111] Furthermore, to prevent programmers from sending merge requests for untested or untested hot update files, which could lead to the release of erroneous code and cause product quality risks, in an optional embodiment of this application, the merge request needs to carry the corresponding hot update order number information. Based on the merge request, the hot update fix file is merged into the main branch corresponding to the Git repository, and a corresponding target package for external release is generated, including:

[0112] Determine whether the status information of the hot update request order corresponding to the hot update order number is "test successful";

[0113] If so, based on the merge request, the hot update fix file is merged into the main branch corresponding to the Git repository, and a corresponding target package for external release is generated.

[0114] There is a one-to-one correspondence between the hot update order number and the hot update request. In this embodiment, the corresponding hot update request can be determined by the hot update order number carried in the merge request, and then it can be determined whether the status information of the hot update request is that the test is successful. If so, the hot update repair file corresponding to the hot update order number can be obtained, and the hot update repair file can be merged into the corresponding main branch of the Git repository, and then the corresponding target package for external release can be generated.

[0115] Furthermore, in an optional embodiment of this application, after generating the target package, the target package can be sent to the target server to perform a hot update of the target application. Therefore, the above method may further include:

[0116] The target package is sent to the corresponding target server to trigger the target server to perform a hot update of the application based on the target package.

[0117] To prevent the hot update repair files in the target package from changing before being sent to the target server, thus causing errors in the target package, in an optional embodiment of this application, before sending the target package to the corresponding target server, the following is further included:

[0118] Determine whether the status information of the hot update request corresponding to the target package is "test successful";

[0119] If so, the target packet body is sent to the corresponding target server.

[0120] Before sending the target package to the corresponding target server, this embodiment determines the hot update request form corresponding to the target package based on the hot update repair file corresponding to the target package, and then determines whether the hot update request form has been successfully tested. If so, the target package is sent to the corresponding target server.

[0121] Furthermore, the above method may also include:

[0122] If the hot update repair package test fails, roll back the code in the SVN repository corresponding to the hot update instruction.

[0123] In this embodiment of the application, when the hot update repair package fails to pass the test, the test failure information can be displayed on the terminal device used by the corresponding programmer and / or the terminal device used by the program tester, and the hot update code corresponding to the hot update repair package that has been submitted to the SVN repository can be rolled back to prevent the final state of the SVN repository from containing code that has failed the test.

[0124] This embodiment of the application, in response to a hot update command for an SVN repository, generates a corresponding hot update fix file based on the hot update command; sends the hot update fix file to the corresponding hot update fix branch of the Git repository, and combines it with the baseline package corresponding to the hot update fix branch to generate a hot update fix package to be tested; the SVN repository and the Git repository correspond to the same application; after the hot update fix package is successfully tested, the hot update fix file is merged into the corresponding main branch of the Git repository, and a corresponding target package for external release is generated. This embodiment of the application combines the advantages of SVN repositories and Git repositories, achieving both compliance with the usage habits of most users of SVN repositories and the ability to improve testing efficiency and reduce the probability of code errors in external packages through the branch management function of Git repositories.

[0125] To enable those skilled in the art to better understand the embodiments of this application, the following will be combined with Figures 2 to 4 This paper describes the hot update testing method in the embodiments of this application from the aspects of package management, hot update repair package generation process and testing process.

[0126] like Figure 2 As shown, Figure 2 This diagram illustrates package body management in one embodiment of this application. To isolate hot update content (i.e., hot update requirements) and manage it in a Git repository, this embodiment introduces the concept of a baseline package. Taking weekly updates as an example, once the weekly maintenance content is completed, the baseline package remains unchanged. All subsequent hot update content is generated by merging the patch file (i.e., hot update fix file) with the baseline package. Package body management involves a baseline package repository, a patch package repository, a test repository, and an external package repository, as detailed below:

[0127] Baseline package repository: Each week, a corresponding folder is created for releasing branches to store all process packages, such as... Figure 2 The files are named `release_20210714` and `release_202107287`. Each folder stores all the corresponding process packages. During testing, the process packages will continuously increase. When all maintenance content for the week is completed, the final baseline package, also known as the Base package, will be generated. After that, no more packages will be compiled on this branch. For example, `release_20210728-xxx18` in the figure is the last baseline package generated on the `release_20210728` branch.

[0128] The patch repository stores all patch packages to be tested (i.e., hot-update fixes). Each patch package is generated from a patch file submitted by the programmer and a baseline package. Programmers can specify the patch packages to be synchronized from the patch repository for internal testing. The contents of each patch package are independent and do not affect others.

[0129] Test Repository: Used to map various packages required by program testers. This includes the latest packages (QcRelease) in the baseline package repository for daily testing; packages (Release) currently running on the target server for building the same environment as the target server during hot updates; and hot update packages (Patch) in the Patch package repository for synchronization when testing hot update content.

[0130] External package repository: Used to store the package bodies used by the target server, and automatically updated when new content is externalized; such as Figure 2 As shown, the target server initially uses the package body release_20210728-xxx18. After a hot update is released, it is automatically updated to the corresponding hot update package release_20210728-xxx01p.

[0131] like Figure 3 As shown, Figure 3 A schematic diagram of the hot update repair package generation process in one embodiment of this application is shown.

[0132] In this example, the patch package (i.e., the hot update fix package) is generated using a baseline package + patch file approach. The SVN repository is used for daily code maintenance, and all daily commits are made there. The Git repository is dedicated to hot updates; all hot update content is committed to the Git repository for packaging and testing. Each maintenance branch corresponds to a baseline Master branch (i.e., the main branch), as shown in the figure: [master]release_20210728. The basic process of generating the patch package is as follows:

[0133] 1. Programmers submit the necessary bug fix code (i.e., hot update fix code) to the SVN repository. The commit log will specify the tracking number (i.e., the hot update tracking number), such as #10379. It's important to note that the hot update process does not involve compiling the package on the SVN repository. Therefore, the submitted fix code is only used to generate patch files and will not affect the baseline package.

[0134] 2. Execute the patch generation script to generate the corresponding patch file based on the specified tracking number. This script will find all associated files in the SVN Log based on the tracking number and restore the corresponding path structure. For example, if two files A and B were committed using tracking number #10379, the script will generate the corresponding path files logic / entities / A.py and logic / game / B.py; then, it will combine files A and B to generate the patch file, patch_10379.py.

[0135] While generating the patch file, the script will automatically switch to the corresponding hot update fix branch from the remote Git repository, as shown in the figure [10379_for_release_20210728]; after generating the local patch file, the programmer can push the corresponding patch file to this branch.

[0136] 3. After the push is completed, GitLab's CI mechanism (an automatic compilation mechanism) will be automatically triggered to pull the baseline package (as shown in [10379_for_release_20210728]) and combine it with the Patch file to generate the Patch package body to be tested.

[0137] like Figure 4 As shown, Figure 4 A schematic diagram of a test process according to an embodiment of this application is shown, including the following steps:

[0138] 1. Programmers submit fix code to the SVN repository; when submitting fix code, check if the log contains a tracking number, as well as the type, status, and follow-up person of the tracking number, to ensure that the submitted content is traceable and followed up by someone.

[0139] 2. Execute the Patch generation script to generate Patch files, and simultaneously create a hot update fix branch from the remote Git repository;

[0140] 3. Submit the Patch file to the local hotfix branch, synchronize it to the remote Git repository in real time, trigger GitLab packaging, generate the Patch package body, and then push it from the remote Git repository to the Patch package repository as the package body to be tested;

[0141] 4. Program testers synchronize the patch package to be tested from the patch package repository to their local machine for testing;

[0142] 5. After testing is completed, the programmer initiates a Merge Request. Once the Merge Request is approved, the patched code is merged into Master from the hotfix branch, triggering GitLab packaging and generating the external package (i.e., the target package). During the Merge Request review, the status of the requirement form for the corresponding branch is checked to ensure that only content that has been tested can be merged into Master.

[0143] 6. Upload the external release package to the external service platform (i.e., the target server) and execute the external release operation. The test is now complete. Before uploading the external release package to the external service platform, it is necessary to check the status of all patch files within the package corresponding to the relevant request form to ensure that all external release content has been tested and no errors have been submitted.

[0144] This embodiment employs two independent version control repositories, with all hot-update requests running on independent test branches, eliminating the possibility of mutual interference and exhibiting high parallel efficiency. The external package repository and patch repository are independent, ensuring that only content that has completed testing enters the Master branch. Simultaneously, the external package body is updated synchronously with the external release status, allowing testers to easily access it for reproducing exceptions, thus minimizing rollback costs. All hot-update content in this embodiment is performed on branches, and only after successful testing is it merged into Master. Furthermore, before merging into Master, testers must send a merge request, ensuring that all code merged into Master has successfully passed testing, providing double verification. This embodiment performs tracking number checks when submitting code to the SVN repository, ensuring traceable submissions; and the aforementioned double verification of submitted code avoids the need for testers to repeatedly confirm and synchronize, achieving information transparency.

[0145] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of this application are not limited to the described order of actions, because according to the embodiments of this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of this application.

[0146] Reference Figure 5 The diagram shows a structural block diagram of an embodiment of a hot update testing device according to this application. In this embodiment, the device may specifically include the following modules:

[0147] The hot update repair file generation module 501 is used to generate a corresponding hot update repair file in response to a hot update command for an SVN repository, based on the hot update command.

[0148] The hot update repair package generation module 502 is used to send the hot update repair file to the hot update repair branch corresponding to the Git repository, so as to generate a hot update repair package to be tested by combining it with the baseline package corresponding to the hot update repair branch; the SVN repository and the Git repository correspond to the same application;

[0149] The target package generation module 503 is used to merge the hot update repair file into the main branch corresponding to the Git repository after the hot update repair package test is successful, and generate the corresponding target package for external release.

[0150] Optionally, the hot update repair file generation module 501 further includes:

[0151] The first judgment module is used to determine whether the hot update instruction carries hot update order number information;

[0152] The hot update repair code acquisition module is used to acquire the hot update repair code corresponding to the hot update order number information if the condition is met.

[0153] The hot update repair file determination module is used to generate the corresponding hot update repair file based on the hot update repair code.

[0154] Optionally, the device further includes:

[0155] The hot update repair branch creation module is used to create a hot update repair branch corresponding to the current hot update cycle. The baseline package corresponding to the hot update repair branch is the package obtained at the end of the previous hot update cycle for external release.

[0156] Optionally, the target package generation module 503 includes:

[0157] The merge request receiving module is used to receive a merge request for the hot update repair file after the hot update repair package body test is successful.

[0158] The hot update fix file merging module is used to merge the hot update fix file into the main branch corresponding to the Git repository based on the merging request, and generate the corresponding target package for external release.

[0159] Optionally, the merge request carries the hot update order number information, and the hot update repair file merge module includes:

[0160] The second judgment module is used to determine whether the status information of the hot update request order corresponding to the hot update order number information is "test successful";

[0161] The file merging module is used to merge the hot update fix file into the main branch corresponding to the Git repository based on the merging request if the request is true, and generate a corresponding target package for external release.

[0162] Optionally, the device further includes:

[0163] The target package external release module is used to send the target package to the corresponding target server to trigger the target server to perform a hot update of the application based on the target package.

[0164] Optionally, the target package external projection module further includes:

[0165] The third judgment module is used to determine whether the status information of the hot update request corresponding to the target package is "test successful";

[0166] The target packet sending module is used to send the target packet to the corresponding target server if the condition is met.

[0167] Optionally, the device further includes:

[0168] The failure rollback module is used to roll back the code corresponding to the hot update instruction in the SVN repository after the hot update repair package test fails.

[0169] Optionally, the hot update repair file generation module 501 further includes:

[0170] The error message module is used to generate a first message if the hot update instruction does not carry a hot update order number. The first message indicates that there is an error in the hot update instruction.

[0171] In this embodiment, the hot update fix file generation module responds to a hot update command for the SVN repository and generates a corresponding hot update fix file based on the command. The hot update fix package generation module sends the hot update fix file to the corresponding hot update fix branch of the Git repository, and combines it with the baseline package corresponding to the hot update fix branch to generate a hot update fix package to be tested. The SVN repository and the Git repository correspond to the same application. After the hot update fix package is successfully tested, the target package generation module merges the hot update fix file into the main branch of the Git repository and generates a corresponding target package for external release. This embodiment combines the advantages of SVN and Git repositories, achieving both compliance with the usage habits of most users of SVN repositories and improved testing efficiency and reduced probability of code errors in external packages through the branch management function of Git repositories.

[0172] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0173] This application also discloses an electronic device, including a processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein the computer program, when executed by the processor, implements the steps of the hot update test method as described above.

[0174] This application also discloses a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the hot update test method described above.

[0175] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0176] Those skilled in the art will understand that embodiments of this application can be provided as methods, apparatus, or computer program products. Therefore, embodiments of this application can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of this application can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0177] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0178] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0179] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0180] Although preferred embodiments of the present application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present application.

[0181] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0182] The above provides a detailed description of the hot update testing method, apparatus, electronic device, and storage medium provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A hot update test method, characterized in that, The method includes: In response to a hot update command for an SVN repository, a corresponding hot update repair file is generated based on the hot update command. The hot update repair file is generated based on all hot update repair codes associated with the hot update order number information in the hot update command, and one hot update order number information corresponds to at least one hot update repair code. The hot update fix file is sent to the hot update fix branch corresponding to the Git repository, and combined with the baseline package corresponding to the hot update fix branch, a hot update fix package to be tested is generated; the SVN repository and the Git repository correspond to the same application; the hot update fix branch corresponds one-to-one with the hot update order number information; After the hot update repair package is successfully tested, the hot update repair file is merged into the main branch corresponding to the Git repository, and a corresponding target package for external release is generated.

2. The method according to claim 1, characterized in that, The step of responding to a hot update command for an SVN repository and generating a corresponding hot update repair file based on the hot update command further includes: Determine whether the hot update instruction carries hot update order number information; If so, then obtain the hot update repair code corresponding to the hot update order number information; Generate the corresponding hot update repair file based on the hot update repair code.

3. The method according to claim 2, characterized in that, Before sending the hot update fix file to the corresponding hot update fix branch in the Git repository, and combining it with the baseline package corresponding to the hot update fix branch to generate the hot update fix package to be tested, the following steps are also included: Create a hot update repair branch corresponding to the current hot update cycle. The baseline package corresponding to the hot update repair branch is the package obtained at the end of the previous hot update cycle for external release.

4. The method according to claim 2 or 3, characterized in that, After the hot update repair package is successfully tested, the hot update repair file is merged into the main branch corresponding to the Git repository, and a corresponding target package for external release is generated, including: After the hot update repair package body test is successful, a request to merge the hot update repair file is received. Based on the merge request, the hot update fix file is merged into the main branch corresponding to the Git repository, and a corresponding target package for external release is generated.

5. The method according to claim 4, characterized in that, The merge request carries the hot update order number information. Based on the merge request, the hot update fix file is merged into the main branch corresponding to the Git repository, and a corresponding target package for external release is generated, including: Determine whether the status information of the hot update request order corresponding to the hot update order number is "test successful"; If so, based on the merge request, the hot update fix file is merged into the main branch corresponding to the Git repository, and a corresponding target package for external release is generated.

6. The method according to claim 5, characterized in that, After merging the hot update fix file into the main branch corresponding to the Git repository based on the merge request, and generating the corresponding target package for external release, the process further includes: The target package is sent to the corresponding target server to trigger the target server to perform a hot update of the application based on the target package.

7. The method according to claim 6, characterized in that, Sending the target packet body to the corresponding target server further includes: Determine whether the status information of the hot update request corresponding to the target package is "test successful"; If so, the target packet body is sent to the corresponding target server.

8. The method according to claim 1, characterized in that, The method further includes: If the hot update repair package test fails, roll back the code in the SVN repository corresponding to the hot update instruction.

9. The method according to claim 2, characterized in that, The step of responding to a hot update command for an SVN repository and generating a corresponding hot update repair file based on the hot update command further includes: If the hot update command does not carry hot update order number information, a first prompt message is generated, which is used to indicate that there is an error in the hot update command.

10. A hot-renewal testing device, characterized in that, The device includes: The hot update repair file generation module is used to respond to a hot update command for an SVN repository and generate a corresponding hot update repair file according to the hot update command. The hot update repair file is generated based on all hot update repair codes associated with the hot update order number information in the hot update command, and one hot update order number information corresponds to at least one hot update repair code. The hot update repair package generation module is used to send the hot update repair file to the hot update repair branch corresponding to the Git repository, so as to generate a hot update repair package to be tested by combining it with the baseline package corresponding to the hot update repair branch; the SVN repository and the Git repository correspond to the same application; the hot update repair branch corresponds one-to-one with the hot update order number information; The target package generation module is used to merge the hot update repair file into the main branch corresponding to the Git repository after the hot update repair package test is successful, and generate the corresponding target package for external release.

11. An electronic device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein the computer program, when executed by the processor, implements the steps of the hot update test method as described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, A computer program is stored on the computer-readable storage medium, which, when executed by a processor, implements the steps of the hot update test method as described in any one of claims 1 to 9.

Images