Software release method and device, equipment and medium

Abstract

The invention discloses a software release method and device, equipment and a medium, and the method comprises the steps: obtaining a software release request which comprises a first version number; the uniqueness and validity of a first version number in the software release request are verified, and the to-be-released software with the uniqueness and validity of the first version number serves as first target release software; enabling the first target release software to enter an approval process, and obtaining second target release software according to an approval result; comparing the version number of the second target release software with the first version number, and taking the second target release software with the same version number as the first version number as final target release software; and executing the release process according to the final target release software. According to the method, software release can be automatically carried out, the possibility of misoperation or wrong version release is reduced, the user experience is improved, and service interruption is avoided.

Description

[0001] Technology Neighborhood

[0002] The present application relates to the field of software development, and in particular to a software publishing method, device, equipment and medium. Background Art

[0003] In a fast-iterating software development environment, with the increasing frequency of function updates and bug fixes, the frequency of software releases has increased significantly, which places higher demands on system stability and efficiency. The traditional release process requires manual operations at every stage. This highly manual approach is not only inefficient, but also very likely to lead to misoperations or wrong versions due to human factors, which in turn affects user experience and even causes business interruptions. Summary of the invention

[0004] The present application aims to propose a software publishing method, apparatus, device and medium, which can automatically publish software, reduce the possibility of misoperation or wrong version release, improve user experience and avoid business interruption.

[0005] In a first aspect, an embodiment of the present application provides a software publishing method, comprising the following steps:

[0006] Obtaining a software release request, wherein the software release request includes a first version number, and the first version number is used to indicate a version corresponding to the software to be released;

[0007] Verify the uniqueness and validity of the first version number in the software release request, and use the to-be-released software with the first version number having uniqueness and validity as the first target release software;

[0008] The first target release software enters the approval process, and the second target release software is obtained according to the approval result, wherein the second target release software is the approved first target release software;

[0009] Compare the version number of the second target release software with the first version number, and use the second target release software having the same version number as the first version number as the final target release software;

[0010] Release the software according to the final goal and execute the release process.

[0011] According to some embodiments of the present application, the software release request also includes a second version number, where the second version number is used to indicate a rollback version of the software;

[0012] The verifying the uniqueness and validity of the first version number in the software release request and taking the to-be-released software with uniqueness and validity as the first target release software includes:

[0013] Verifying the uniqueness and validity of the first version number in the software release request;

[0014] Verifying the validity of the second version number in the software release request;

[0015] The software to be released whose first version number is unique and valid and whose second version number is valid is used as the first target released software.

[0016] According to some embodiments of the present application, the approval process is a multi-level approval process, and the first target release software is put into the approval process, and the second target release software is obtained according to the approval result, including:

[0017] Obtaining the approval rules of the approval process, wherein the approval rules are used to indicate the approval order of different approvers in multi-level approval;

[0018] According to the approval rules, the first target release software is sent to different approvers in the approval order for approval;

[0019] The second target release software is obtained according to the approval result, where the second target release software is the first target release software that has passed the multi-level approval.

[0020] According to some embodiments of the present application, the executing a release process according to the final target release software includes:

[0021] Obtain the code corresponding to the final target release software;

[0022] Automatically build according to the code to obtain a program package corresponding to the final target release software;

[0023] A release process is performed according to the package.

[0024] According to some embodiments of the present application, in the case where the automatic construction fails, obtaining the program package corresponding to the final target release software includes:

[0025] Get a retry strategy, where the retry strategy is used to indicate a build retry handler when an automatic build fails;

[0026] According to the retry strategy, the build retry handler is authorized to perform build retries to obtain the program package corresponding to the final target release software.

[0027] According to some embodiments of the present application, the executing a release process according to the final target release software includes:

[0028] Obtaining first pilot information, where the first pilot information is used to indicate a first pilot range and at least one first terminal corresponding to the first pilot range;

[0029] Sending the final target release software to the corresponding first terminal according to the first pilot information;

[0030] A first pilot result fed back by the first terminal is obtained, and a publishing process is executed according to the first pilot result.

[0031] According to some embodiments of the present application, second pilot information is further included, where the second pilot information is used to indicate a second pilot range and at least one second terminal corresponding to the second pilot range, and executing the release process according to the first pilot result includes:

[0032] Obtain the second pilot information;

[0033] Sending the final target release software to the corresponding second terminal according to the second pilot information;

[0034] A second pilot result fed back by the second terminal is obtained, and a publishing process is executed according to the second pilot result.

[0035] In a second aspect, an embodiment of the present application provides a software publishing device, including:

[0036] A request acquisition module, used to acquire a software release request, wherein the software release request includes a first version number, and the first version number is used to indicate a version corresponding to the software to be released;

[0037] A first verification module is used to verify the uniqueness and validity of the first version number in the software release request, and use the to-be-released software with the first version number having uniqueness and validity as the first target release software;

[0038] An approval process module, used to enter the first target release software into the approval process, and obtain the second target release software according to the approval result, wherein the second target release software is the approved first target release software;

[0039] A second verification module is used to compare the version number of the second target release software with the first version number, and use the second target release software with the same version number as the first version number as the final target release software;

[0040] The release process module is used to execute the release process according to the final target release software.

[0041] In a third aspect, an embodiment of the present application provides an electronic device, the device comprising: a processor and a memory storing computer program instructions;

[0042] When the processor executes the computer program instructions, the software publishing method as described in the first aspect is implemented.

[0043] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium having computer program instructions stored thereon, and when the computer program instructions are executed by a processor, the software publishing method as described in the first aspect is implemented.

[0044] The software publishing method, apparatus, device, and medium of the embodiments of the present application have at least the following beneficial effects:

[0045] In this implementation, by obtaining a software release request, the software release request includes a first version number; verifying the uniqueness and validity of the first version number in the software release request, taking the to-be-released software with the first version number having uniqueness and validity as the first target release software; entering the first target release software into the approval process, and obtaining the second target release software according to the approval result; comparing the version number of the second target release software with the first version number, taking the second target release software with the same version number as the first version number as the final target release software; and executing the release process according to the final target release software. Software release can be automatically performed, reducing the possibility of misoperation or wrong version release, improving user experience, and avoiding business interruption.

[0046] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become apparent from the description below, or will be learned through the practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] The present application is further described below with reference to the accompanying drawings and embodiments, wherein:

[0048] Figure 1 A flowchart of an embodiment of the software publishing method provided by the present application;

[0049] Figure 2 A schematic diagram of a software publishing device provided for this application;

[0050] Figure 3 A schematic diagram of the structure of the electronic device provided in this application. DETAILED DESCRIPTION

[0051] The features and exemplary embodiments of various aspects of the present application will be described in detail below. In order to make the purpose, technical solutions and advantages of the present application clearer, the present application will be further described in detail below in conjunction with the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain the present application, rather than to limit the present application. For those skilled in the art, the present application can be implemented without the need for some of these specific details. The following description of the embodiments is only to provide a better understanding of the present application by illustrating the examples of the present application.

[0052] In this article, relational terms such as first and second, etc. are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the statement "include..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.

[0053] In a fast-iterating software development environment, with the increasing frequency of function updates and bug fixes, the frequency of software releases has increased significantly, which places higher demands on system stability and efficiency. The traditional release process requires manual operations at every stage. This highly manual approach is not only inefficient, but also very likely to lead to misoperations or wrong versions due to human factors, which in turn affects user experience and even causes business interruptions.

[0054] In order to solve the problems of the prior art, the embodiments of the present application provide a software publishing method, apparatus, device and medium. The software publishing method provided by the embodiments of the present application is first introduced below.

[0055] Figure 1 The flowchart of the software publishing method provided by the embodiment of the present application is shown. The method is applied to a server, a software publishing method, comprising the following steps:

[0056] S101, obtaining a software release request, where the software release request includes a first version number, and the first version number is used to indicate a version corresponding to the software to be released;

[0057] S102, verifying the uniqueness and validity of the first version number in the software release request, and taking the to-be-released software whose first version number is unique and valid as the first target release software;

[0058] S103, the first target release software enters the approval process, and the second target release software is obtained according to the approval result, and the second target release software is the approved first target release software;

[0059] S104, comparing the version number of the second target release software with the first version number, and taking the second target release software having the same version number as the first version number as the final target release software;

[0060] S105, publishing the software according to the final goal and executing the publishing process.

[0061] In this implementation, by obtaining a software release request, the software release request includes a first version number; verifying the uniqueness and validity of the first version number in the software release request, taking the to-be-released software with the first version number having uniqueness and validity as the first target release software; entering the first target release software into the approval process, and obtaining the second target release software according to the approval result; comparing the version number of the second target release software with the first version number, taking the second target release software with the same version number as the first version number as the final target release software; and executing the release process according to the final target release software. Software release can be automatically performed, reducing the possibility of misoperation or release of wrong versions, improving user experience, and avoiding business interruption.

[0062] In the above step S101, obtaining a software release request refers to a software release application submitted by a user in the system according to the software project release requirements. The software release request in the embodiment of the present application refers to a release application for software iteration, that is, updating or upgrading the software. The software release request includes a first version number, which is used to indicate the version corresponding to the software to be released. The first version number refers to the unique Commit ID corresponding to the software applied for release, that is, the software release request must be accompanied by the unique Commit ID corresponding to the software applied for release as a code version identifier.

[0063] It should be noted that Commit ID refers to a hash value that uniquely identifies a commit in a code base. In a version control system (such as Git), each time you commit code, the system generates a unique identifier for the commit, namely Commit ID. With Commit ID, the system can easily roll back to a previous version or compare the differences between different versions. In addition to Commit ID, software release requests can also include other related parameters such as update description, software update size, and estimated update time.

[0064] In the above step S102, verifying the uniqueness and validity of the first version number in the software release request means that the system determines whether the Commit ID attached to the software release request is valid and unique. Verifying the validity means verifying whether the commitID exists in the matching code library. Verifying the uniqueness means verifying whether the software version corresponding to the Commit ID is unique, so as to avoid update confusion caused by different versions corresponding to the same Commit ID.

[0065] In this implementation, the system verifies the validity and uniqueness of the Commit ID through automated verification, which refers to automatically checking the correctness, compliance or completeness of input data or system status through preset rules and algorithms. In the release process, automated verification is used to ensure that the submitted Commit ID meets the specified requirements, that is, it has validity and uniqueness, thereby avoiding human errors or non-compliant operations.

[0066] In the step of using the to-be-released software with a first version number that is unique and valid as the first target release software, the first target release software refers to the to-be-released software that has a unique and valid Commit ID after verification.

[0067] In the above step S103, the first target release software enters the approval process, and the second target release software is obtained according to the approval result. The second target release software is the first target release software that has passed the approval, which means that if the CommitID is verified to be unique and valid, it will automatically enter the approval process. The approval process refers to the automatic flow according to the preset approval rules, and the approval information is sent to the approver with approval authority. The approver can be one or more. The first target release software that has passed the approval is used as the second target release software. Therefore, the second target release software refers to the software to be released that has passed the approval and has a unique and valid Commit ID.

[0068] In the above step S104, the second target release software is compared with the first version number, and the second target release software with the same version number as the first version number is used as the final target release software, which means that the Commit ID of the second target release software is verified twice to verify whether its version number is consistent with the first version number. It should be noted that the second target release software can usually be released directly because it has been approved and the Commit ID is unique and valid. However, in order to ensure that the software version to be released is consistent with the version submitted, the software is verified twice before release in this application, and the second target release software that passes the secondary verification is used as the final target release software, which can greatly reduce the possibility of releasing the wrong version.

[0069] It should be understood that, whether it is the primary verification performed in step S102 or the secondary verification performed in step S104, if at any stage it is found that the version of the software to be released is inconsistent or there are potential risks such as inconsistent functional expectations, the system automatically terminates the release process to prevent the non-compliant version from going online, thereby ensuring that business continuity is not affected.

[0070] In the above step S105, the release process is executed according to the final target release software, which means that after the secondary verification is passed, the software to be released corresponding to the software release request is executed. The release process includes extracting the code corresponding to the software, executing the construction, packaging and other operations and deploying it on the corresponding terminal. The construction, packaging and other operations can be performed manually or automatically.

[0071] It should be noted that during steps S101-S105, the system records each operation in detail, including version change details, release success rate, build failure reasons, rollback records, approval records, verification results, build logs and exception information, and automatically generates key information such as release reports to provide a basis for subsequent optimization.

[0072] In some implementations, the software release request may further include a second version number, where the second version number is used to indicate a rollback version of the software;

[0073] Verifying the uniqueness and validity of the first version number in the software release request and using the to-be-released software with uniqueness and validity as the first target release software may include:

[0074] Verify the uniqueness and validity of the first version number in the software release request;

[0075] Verify the validity of the second version number in the software release request;

[0076] The software to be released whose first version number is unique and valid and whose second version number is valid is used as the first target released software.

[0077] In this implementation, the uniqueness and validity of the first version number in the software release request are first verified, and then the validity of the second version number in the software release request is verified, and the software to be released whose first version number is unique and valid and whose second version number is valid is used as the first target release software. If a problem occurs after the software is released, it can be rolled back to ensure that business continuity is not affected.

[0078] The second version number in the above step refers to the rollback Commit ID of the software. The rollback Commit ID serves as the reference point for emergency rollback of the software. When the released software has malicious BUGs or other functional defects, the system can directly perform the rollback operation based on the rollback Commit ID to ensure that business continuity is not affected.

[0079] It should be noted that verifying the validity of the second version number in the software release request refers to verifying the authenticity of the software version corresponding to the Commit ID. Therefore, in this embodiment, the software release request must be accompanied by the unique Commit ID of this software release as the code version identifier, and the preset rollback Commit ID as the reference point for emergency rollback. When submitting, the system automatically transmits the code version and rollback version data to the server for uniqueness and validity verification.

[0080] In some implementations, the approval process is a multi-level approval process, and the first target release software is put into the approval process, and the second target release software is obtained according to the approval result, which may include:

[0081] Get the approval rules of the approval process. The approval rules are used to indicate the approval order of different approvers in multi-level approval.

[0082] According to the approval rules, the first target release software is sent to different approvers in the approval order for approval;

[0083] The second target release software is obtained according to the approval result, and the second target release software is the first target release software that has passed the multi-level approval.

[0084] In this embodiment, when the approval process is multi-level approval, the approval rules of the approval process are first obtained, and the approval rules are used to indicate the approval order of different approvers in the multi-level approval. Then, according to the approval rules, the first target release software is sent to different approvers in the approval order for approval, and finally the second target release software is obtained according to the approval result. It can be automatically transferred level by level according to the preset approval rules, thereby improving the efficiency of approval.

[0085] In the above steps, the first target release software is sent to different approvers for approval in the approval order according to the approval rules, which means that the system automatically sends the approval process to the corresponding approvers according to the approval order in the approval rules. For example, if there are three approvers A, B, and C, and the approval order in the approval rules is ABC, the approval process is first sent to approver A. When A approves, the system automatically sends the approval process to approver B. When B approves, it is sent to approver C. When approver C approves, the approval ends and enters the next process.

[0086] In some implementations, executing a release process according to a final target release software may include:

[0087] Get the code corresponding to the final target release software;

[0088] Automatically build according to the code to obtain the program package corresponding to the final target release software;

[0089] Execute the release process according to the package.

[0090] In this embodiment, the code corresponding to the final target release software is first obtained, and then automatically constructed according to the code to obtain the program package corresponding to the final target release software, and the release process is executed according to the program package, which can further improve the efficiency of software release.

[0091] The above-mentioned automatic building based on code refers to the system automatically pulling the code and automatically building it. Specifically, automatic building refers to automatically executing the construction process such as code compilation, packaging, and testing through automation tools (such as Jenkins, Travis CI, etc.). The above-mentioned program package refers to a deployable application package. In the release process, the source code can be automatically converted into a deployable application package through automatic building for subsequent deployment and testing.

[0092] In some implementations, when the automatic build fails, obtaining a program package corresponding to the final target release software includes:

[0093] Get a retry strategy, where the retry strategy is used to indicate a build retry handler when an automatic build fails;

[0094] According to the retry strategy, the build retry handler is authorized to perform build retries to obtain the program package corresponding to the final target release software.

[0095] In this implementation, when the automatic build fails, the retry strategy is first obtained, and then the retry authority is granted to the manual retry handler to obtain the program package corresponding to the final target release software. Retry can be performed when the automatic build fails, without the need to re-approve the approval process, further improving the efficiency of software release.

[0096] The above retry strategy refers to a strategy pre-set in the server system to deal with the failure of automatic build. Since the process of building the application package may fail due to various unexpected situations during the automatic build process, the failure of automatic build includes the build link and the release link in the pipeline. The build failure may be due to the failure of the network to pull the dependency package or the timeout caused by the resource preemption of the build machine. These failures can be automatically repaired by retrying. Therefore, a retry strategy is pre-set in this application, and a retry handler is designated. The retry handler refers to the user who triggers the retry process.

[0097] The above-mentioned granting of retry rights to the build retry handler according to the retry strategy and obtaining the corresponding package of the final target release software means that in the case of automatic build failure, the system grants the retry rights to the build retry handler according to the retry strategy, waiting for the retry handler to determine whether to retry the automatic build or terminate the automatic build process. When the self-purchased build fails, the system will output a failure log. The retry handler can determine whether the failure can be resolved by retrying based on the failure log. If it cannot be resolved, the process needs to be terminated, and the problem needs to be resolved at the code level before resubmitting the release application. When the retry handler determines that a retry is possible, the retry process can be triggered through simple operations without additional approval.

[0098] It should be noted that after the program package is generated, the system can automatically revoke the temporary permissions of the retry handler to ensure the security and standardization of permission management.

[0099] In some implementations, executing a release process according to a final target release software may include:

[0100] Obtaining first pilot information, where the first pilot information is used to indicate at least one first terminal for performing a pilot;

[0101] Sending the final target release software to the corresponding first terminal according to the first pilot information;

[0102] A first pilot result fed back by the first terminal is obtained, and a publishing process is executed according to the first pilot result.

[0103] In this implementation, the first pilot information is first obtained, and then the final target release software is sent to the corresponding first terminal according to the first pilot information, the first pilot result fed back by the first terminal is obtained, and the release process is executed according to the first pilot result. The probability of non-compliant versions going online can be reduced to ensure that business continuity is not affected.

[0104] The above-mentioned first pilot information refers to selecting a part of terminals as the first terminals as pilots among all terminals that need to update software; sending the final target release software to the corresponding first terminal according to the first pilot information, that is, the new version of the software is first deployed in a limited pilot environment, and its stability and performance are evaluated through preset monitoring and testing methods to obtain the first pilot result. For example, in the first terminal, there is real-time monitoring of arms applications, which can monitor the operating parameters and performance parameters of each version of the software to obtain the first pilot result. Alternatively, the first pilot result can be obtained through the effectiveness of the feedback function of the operator of the first terminal. Executing the release process according to the first pilot result means confirming whether to release the software or terminate the rollback based on the evaluation data fed back by the first terminal.

[0105] In some implementations, second pilot information is further included, where the second pilot information is used to indicate at least one second terminal other than the first terminal for the pilot. The release process is performed according to the first pilot result, including:

[0106] Obtain the second pilot information;

[0107] Sending the final target release software to the corresponding second terminal according to the second pilot information;

[0108] A second pilot result fed back by the second terminal is obtained, and a publishing process is executed according to the second pilot result.

[0109] In this implementation, the second pilot information is first obtained; then the final target release software is sent to the corresponding second terminal according to the second pilot information; the second pilot result fed back by the second terminal is obtained, and the release process is executed according to the second pilot result. By gradually expanding the scope of the pilot according to the pilot results, the probability of non-compliant versions going online can be further reduced, ensuring that business continuity is not affected.

[0110] The above-mentioned second pilot information refers to the selection of some terminals other than the first terminal as the second terminal for the next stage of the pilot. It should be understood that the next stage of the pilot can only be carried out after the first pilot result is qualified, otherwise it needs to be terminated or rolled back. The second pilot result refers to the feedback after the second terminal is equipped with the new version of the software. The embodiment of the present application expands the release range of the new version in stages and gradually until it is fully upgraded.

[0111] It should be noted that the second pilot information may include one range or multiple ranges that increase step by step, that is, select second terminals of different ranges for multi-stage release. Therefore, multi-stage release of software release can be achieved through the first terminal and the second terminal. Multi-stage release refers to the process of gradually deciding to expand the scope of use of the new version to a larger user group based on the results and feedback of the use of the new version in a small user group. It aims to reduce the risks that may be brought about by the launch of the new version by gradually increasing the exposure area, and ensure that the new version has been fully verified and tuned before full promotion. Therefore, this application reduces risks and ensures that business continuity is not affected by gradually expanding the release range.

[0112] In summary, the embodiment of the present application reduces manual intervention and duplication of work through automated process control, and significantly improves the efficiency of software release. Through automated verification, approval and execution processes, the software release process is made smoother and faster. In addition, it is mandatory to attach the unique Commit ID and rollback version number of the code version to ensure the version traceability and rollback during the release process. Through the double verification mechanism of step S102 and step S104, the launch of non-compliant versions is effectively prevented, the release risk is reduced, and business continuity is ensured to be unaffected. In addition, through real-time verification and automatic construction mechanisms, it is possible to ensure that the code version used in the release process is accurate, avoiding release failures or performance problems caused by human errors or version confusion. The embodiment of the present application adopts an automated multi-stage release strategy, so that the new version can be tested and verified in a pilot environment first, and the release range is gradually expanded, thereby optimizing resource utilization and reducing the risks that may be caused by the comprehensive replacement of the old version. The present application automatically authorizes the builder to retry when the automatic build fails, and has good flexibility.

[0113] Based on the software publishing method provided in the above embodiment, the present application also provides a specific implementation method of the software publishing device.

[0114] like Figure 2 As shown, a software publishing device 200 may include:

[0115] The request acquisition module 201 is used to acquire a software release request, wherein the software release request includes a first version number, and the first version number is used to indicate a version corresponding to the software to be released;

[0116] The first verification module 202 is used to verify the uniqueness and validity of the first version number in the software release request, and use the to-be-released software with the first version number having uniqueness and validity as the first target release software;

[0117] The approval process module 203 is used to enter the first target release software into the approval process, and obtain the second target release software according to the approval result, and the second target release software is the first target release software that has passed the approval;

[0118] The second verification module 204 is used to compare the version number of the second target release software with the first version number, and use the second target release software with the same version number as the first version number as the final target release software;

[0119] The release process module 205 is used to execute the release process according to the final target release software.

[0120] The software publishing device 200 of the embodiment of the present application is used to execute the software publishing method in the above embodiment. Its specific processing process is the same as the software publishing method in the above embodiment, and will not be repeated here.

[0121] Figure 3 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present application is shown.

[0122] The electronic device may include a processor 301 and a memory 302 storing computer program instructions.

[0123] Specifically, the processor 301 may include a central processing unit (CPU), or an application specific integrated circuit (ASIC), or may be configured to implement one or more integrated circuits of the embodiments of the present application.

[0124] The memory 302 may include a large capacity memory for data or instructions. By way of example and not limitation, the memory 302 may include a hard disk drive (HDD), a floppy disk drive, a flash memory, an optical disk, a magneto-optical disk, a magnetic tape, or a universal serial bus (USB) drive or a combination of two or more of these. In appropriate cases, the memory 302 may include a removable or non-removable (or fixed) medium. In appropriate cases, the memory 302 may be inside or outside the integrated gateway disaster recovery device. In a specific embodiment, the memory 302 is a non-volatile solid-state memory.

[0125] In some embodiments, the memory 302 may include a read-only memory (ROM), a random access memory (RAM), a magnetic disk storage medium device, an optical storage medium device, a flash memory device, an electrical, optical or other physical / tangible memory storage device. Thus, in general, the memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., a memory device) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to an aspect of the present disclosure.

[0126] The processor 301 implements any one of the software publishing methods in the above embodiments by reading and executing computer program instructions stored in the memory 302 .

[0127] In one example, the electronic device may further include a communication interface 303 and a bus 310. Figure 3 As shown, the processor 301, the memory 302, and the communication interface 303 are connected via a bus 310 and communicate with each other.

[0128] The communication interface 303 is mainly used to implement communication between various modules, devices, units and / or equipment in the embodiments of the present application.

[0129] Bus 310 includes hardware, software or both, and the parts of online data flow billing equipment are coupled to each other. For example, but not limitation, bus may include accelerated graphics port (AGP) or other graphics bus, enhanced industrial standard architecture (EISA) bus, front-end bus (FSB), hypertransport (HT) interconnection, industrial standard architecture (ISA) bus, infinite bandwidth interconnection, low pin count (LPC) bus, memory bus, micro channel architecture (MCA) bus, peripheral component interconnection (PCI) bus, PCI-Express (PCI-X) bus, serial advanced technology attachment (SATA) bus, video electronics standard association local (VLB) bus or other suitable bus or two or more of these combinations. In appropriate cases, bus 310 may include one or more buses. Although the present application embodiment describes and shows a specific bus, the present application considers any suitable bus or interconnection.

[0130] In addition, in combination with the software publishing method in the above embodiment, the embodiment of the present application can provide a computer storage medium for implementation. The computer storage medium stores computer program instructions; when the computer program instructions are executed by a processor, any one of the software publishing methods in the above embodiment is implemented.

[0131] It should be clear that the present application is not limited to the specific configuration and processing described above and shown in the figures. For the sake of simplicity, a detailed description of the known method is omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present application is not limited to the specific steps described and shown, and those skilled in the art can make various changes, modifications and additions, or change the order between the steps after understanding the spirit of the present application.

[0132] The functional blocks shown in the above-described block diagram can be implemented as hardware, software, firmware or a combination thereof. When implemented in hardware, it can be, for example, an electronic circuit, an application-specific integrated circuit (ASIC), appropriate firmware, a plug-in, a function card, etc. When implemented in software, the elements of the present application are programs or code segments that are used to perform the required tasks. The program or code segment can be stored in a machine-readable medium, or transmitted on a transmission medium or a communication link by a data signal carried in a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, optical fiber media, radio frequency (RF) links, etc. The code segment can be downloaded via a computer network such as the Internet, an intranet, etc.

[0133] It should also be noted that the exemplary embodiments mentioned in this application describe some methods or systems based on a series of steps or devices. However, this application is not limited to the order of the above steps, that is, the steps can be performed in the order mentioned in the embodiment, or in a different order from the embodiment, or several steps can be performed simultaneously.

[0134] Aspects of the present disclosure are described above with reference to the flowchart and / or block diagram of the method, device (system) and computer program product according to the embodiment of the present disclosure. It should be understood that each box in the flowchart and / or block diagram and the combination of each box in the flowchart and / or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine so that these instructions executed by the processor of the computer or other programmable data processing device enable the implementation of the function / action specified in one or more boxes of the flowchart and / or block diagram. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field programmable logic circuit. It can also be understood that each box in the block diagram and / or flowchart and the combination of boxes in the block diagram and / or flowchart can also be implemented by dedicated hardware that performs a specified function or action, or can be implemented by a combination of dedicated hardware and computer instructions.

[0135] The above is only a specific implementation of the present application. Those skilled in the art can clearly understand that for the convenience and simplicity of description, the specific working processes of the systems, modules and units described above can refer to the corresponding processes in the aforementioned method embodiments, and will not be repeated here. It should be understood that the protection scope of the present application is not limited to this. Any technician familiar with the technical field can easily think of various equivalent modifications or replacements within the technical scope disclosed in this application, and these modifications or replacements should be included in the protection scope of this application.

Claims

1. A software publishing method, characterized in that: The following steps are involved: Obtaining a software release request, wherein the software release request includes a first version number, and the first version number is used to indicate a version corresponding to the software to be released; Verify the uniqueness and validity of the first version number in the software release request, and use the to-be-released software with the first version number having uniqueness and validity as the first target release software; The first target release software enters the approval process, and the second target release software is obtained according to the approval result, wherein the second target release software is the approved first target release software; Compare the version number of the second target release software with the first version number, and use the second target release software having the same version number as the first version number as the final target release software; Release the software according to the final goal and execute the release process.

2. The software publishing method according to claim 1, characterized in that: The software release request also includes a second version number, where the second version number is used to indicate a rollback version of the software; The verifying the uniqueness and validity of the first version number in the software release request and taking the to-be-released software with uniqueness and validity as the first target release software includes: Verifying the uniqueness and validity of the first version number in the software release request; Verifying the validity of the second version number in the software release request; The software to be released whose first version number is unique and valid and whose second version number is valid is used as the first target released software.

3. The software publishing method according to claim 1, characterized in that: The approval process is a multi-level approval process, wherein the first target release software enters the approval process, and the second target release software is obtained according to the approval result, including: Obtaining the approval rules of the approval process, wherein the approval rules are used to indicate the approval order of different approvers in multi-level approval; According to the approval rules, the first target release software is sent to different approvers in the approval order for approval; The second target release software is obtained according to the approval result, where the second target release software is the first target release software that has passed the multi-level approval.

4. The software publishing method according to claim 1, characterized in that: The executing release process of releasing the software according to the final target includes: Obtain the code corresponding to the final target release software; Automatically build according to the code to obtain a program package corresponding to the final target release software; A release process is performed according to the package.

5. The software publishing method according to claim 4, characterized in that: In the case where the automatic build fails, obtaining the program package corresponding to the final target release software includes: Get a retry strategy, where the retry strategy is used to indicate a build retry handler when an automatic build fails; According to the retry strategy, the build retry handler is authorized to perform build retries to obtain the program package corresponding to the final target release software.

6. The software publishing method according to claim 1, characterized in that: The software release process according to the final target includes: Obtaining first pilot information, where the first pilot information is used to indicate a first pilot range and at least one first terminal corresponding to the first pilot range; Sending the final target release software to the corresponding first terminal according to the first pilot information; A first pilot result fed back by the first terminal is obtained, and a publishing process is executed according to the first pilot result.

7. The software publishing method according to claim 6, characterized in that: The method further includes second pilot information, where the second pilot information is used to indicate a second pilot range and at least one second terminal corresponding to the second pilot range. The method further includes: executing the release process according to the first pilot result, including: Obtain the second pilot information; Sending the final target release software to the corresponding second terminal according to the second pilot information; A second pilot result fed back by the second terminal is obtained, and a publishing process is executed according to the second pilot result.

8. A software publishing device, characterized in that: include: A request acquisition module, used to acquire a software release request, wherein the software release request includes a first version number, and the first version number is used to indicate a version corresponding to the software to be released; A first verification module is used to verify the uniqueness and validity of the first version number in the software release request, and use the to-be-released software with the first version number having uniqueness and validity as the first target release software; An approval process module, used to enter the first target release software into the approval process, and obtain the second target release software according to the approval result, wherein the second target release software is the approved first target release software; A second verification module is used to compare the version number of the second target release software with the first version number, and use the second target release software with the same version number as the first version number as the final target release software; The release process module is used to execute the release process according to the final target release software.

9. An electronic device, characterized in that: The device comprises: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, the software publishing method according to any one of claims 1 to 7 is implemented.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer program instructions, and when the computer program instructions are executed by a processor, the software publishing method according to any one of claims 1 to 7 is implemented.

Images