Software component release full-process automatic management method, system, equipment and medium

Abstract

The invention discloses a software component release full-process automatic management method, system and device and a medium, and the method comprises the following steps: obtaining to-be-released version information at a front end, and generating a release request based on the to-be-released version information; performing stability verification on the release request at the rear end, updating a version number after the verification is passed, and constructing a release task; in response to release task construction, software package release is carried out based on the updated code, the construction script and the release script, and visual tracking supervision is carried out; in response to a release failure result released by the software package, executing an old version automatic rollback operation; in response to a release success result released by the software package, executing automatic updating and pushing operation of the new version associated item; the method can realize full-flow release automation, liberates both hands of developers, and improves the efficiency; and human errors are reduced based on a unified operation entrance and a standardized process, and the publishing standardization is guaranteed.

Description

Technical Field

[0001] This invention relates to the field of software development technology, and in particular to a method, system, device, and medium for automating the entire software component release process. Background Technology

[0002] In modern front-end development, software packages need to be provided to projects through artifact libraries. Their release involves multiple stages such as version updates, building, and testing, which directly affects development efficiency.

[0003] Existing deployment methods are mainly divided into two categories: manual deployment and basic CI / CD automation.

[0004] (1) Manual release: This solution requires developers to perform version modification, build, release and other operations locally, and then manually write logs and create MR.

[0005] (2) Basic CI / CD Automation: This solution configures tasks on the server and automatically executes the build and release scripts when the code is pushed.

[0006] However, manual processes are cumbersome and error-prone, rely on the accuracy of developers' operations, and are inefficient; basic CI / CD automation is insufficient, lacks real-time status feedback, and operations such as writing logs after release still need to be done manually; there is no automatic recovery mechanism for release failures, which can easily lead to inconsistencies between code repository and artifact repository versions; and the synchronization of process status information relies on manual notifications, which are delayed and prone to omissions. Summary of the Invention

[0007] The purpose of this invention is to provide a method, system, device, and medium for automated management of the entire software component release process, thereby solving all or one of the aforementioned problems in the prior art.

[0008] To solve the above-mentioned technical problems, the specific technical solution of the present invention is as follows:

[0009] On the one hand, this invention provides a method for automating the entire software component release process, including the following steps:

[0010] Request initiation steps:

[0011] The front end obtains the information of the version to be released and generates a release request based on the information of the version to be released.

[0012] Preprocessing and build triggering steps:

[0013] The backend performs stability verification on the release request, and after the verification passes, updates the version number and builds the release task.

[0014] Build and release steps:

[0015] In response to the release task, the package is released based on the updated code, build script, and release script, and visual tracking and supervision are performed.

[0016] Closed-loop feedback steps:

[0017] In response to a failed release of the software package, an automatic rollback operation to the old version is performed.

[0018] In response to the successful release of the software package, perform automatic update and push operations for the new version's associated items.

[0019] Furthermore, obtaining the information of the version to be released further includes:

[0020] Responding to the user login front end, display a list of projects that can be published to the user;

[0021] In response to the user's selection of a project and the code branch to be released, a corresponding request is sent to the backend. After receiving the request, the backend uses the GitLab API to retrieve the current version number of the version configuration file under the user's selected branch and returns it to the frontend as the version information to be released.

[0022] Furthermore, the step of generating a release request based on the version information to be released further includes:

[0023] On the front end, select the version upgrade strategy corresponding to the version information to be released, fill in the update log, and submit.

[0024] The project ID, branch, new version number, and changelog are integrated into the release request and synchronized to the backend.

[0025] Furthermore, the step of performing stability verification on the release request in the backend, and updating the version number and building the release task after the verification passes, further includes:

[0026] In response to the backend receiving the request, the backend calls the GitLab API to check if there is an unmerged MapReduce for the branch corresponding to the release request. If there is no unmerged MapReduce, the check is considered to have passed.

[0027] In response to the successful check, the backend calls the GitLab API to update the version number of the corresponding code branch to the version specified by the user and commits the changes.

[0028] The backend stores the task information in the database, marks the task status, and then calls the Jenkins API to trigger the preset build task, passing the corresponding necessary task parameters.

[0029] Furthermore, the step of responding to the release task by releasing the software package based on the updated code, build script, and release script, and performing visual tracking and supervision, further includes:

[0030] Jenkins pulls the updated code from the specified branch of GitLab, executes the build script and the release script, and releases the package to Nexus;

[0031] During execution, the backend establishes a long connection with the frontend through the SSE interface, retrieves build logs from Jenkins in real time, and streams them to the frontend for display.

[0032] Furthermore, the step of performing an automatic rollback operation on the old version in response to the failure of the software package release further includes:

[0033] If an error occurs while Jenkins is executing a build script or release script, the task is determined to have failed.

[0034] In response to task execution failure, a failure notification and the corresponding task ID are sent to a specific backend API via a Webhook or callback mechanism. After receiving the notification, the backend updates the corresponding task status, then retrieves the previous version number of the corresponding task from the database, calls the GitLab API to automatically roll back the package.json version number to the pre-release state, and submits a reason annotation.

[0035] Furthermore, the step of automatically updating and pushing new version-related items in response to the successful release result of the software package further includes:

[0036] The task is considered to have executed successfully in response to Jenkins successfully sending the package.

[0037] In response to successful task execution, Nexus receives the package from Jenkins and sends a success notification and package information to a specific backend API via a webhook. The backend updates the task status based on the package name and version number, then calls the GitLab API to update CHANGELOG.md based on the changelog, and calls the GitLab API to create a MapReduce (MR) branch from the development branch to the main branch, including update information in the title and description. Finally, it calls the API of the communication app to push formatted information including the project name, version number, changelog, and MR link to the corresponding communication group chat.

[0038] On the other hand, the present invention also provides a fully automated management system for the software component release process, comprising:

[0039] The request initiation module is used to: obtain the version information to be released from the front end, and generate a release request based on the version information to be released;

[0040] The preprocessing and build triggering module is used to: perform stability verification on the release request in the backend, update the version number and build the release task after the verification is passed;

[0041] The build and release module is used to: respond to the release task by releasing the software package based on the updated code, build script, and release script, and perform visual tracking and supervision;

[0042] The closed-loop feedback module is used to: automatically roll back the old version in response to the release failure of the software package; and automatically update and push the new version's associated items in response to the release success of the software package.

[0043] On the other hand, the present invention also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of the fully automated management method for the software component release process.

[0044] On the other hand, the present invention also provides a computer device, the computer device including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; wherein:

[0045] The memory is used to store computer programs;

[0046] The processor is used to execute the steps of the fully automated management method for the software component release process by running programs stored in the memory.

[0047] The beneficial effects of the technical solution of this invention are:

[0048] 1. The software component release full-process automated management method described in this invention can realize full-process automation of release, freeing developers' hands and improving efficiency; reduce human error based on unified operation entry and standardized process, and ensure release standardization; display logs in real time based on web interface, and achieve status transparency by combining notification push; automatically roll back the version if release fails, avoid data inconsistency, reduce repair costs and risks, make up for the defects of the prior art, and have high application value.

[0049] 2. The software component release full-process automated management system described in this invention can realize the software component release full-process automated management method described in this invention through the cooperation of system modules.

[0050] 3. The computer-readable storage medium of the present invention can enable the boot system module to cooperate, thereby realizing the software component release full-process automated management method of the present invention. In addition, the computer-readable storage medium of the present invention also effectively improves the operability of the software component release full-process automated management method.

[0051] 4. The computer device described in this invention can store and execute the computer-readable storage medium, thereby realizing the fully automated management method for the software component release process described in this invention. Attached Figure Description

[0052] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0053] Figure 1 This is a flowchart illustrating the fully automated management method for software component release as described in Embodiment 1 of the present invention;

[0054] Figure 2 This is a schematic diagram of the logical architecture of the software component release full-process automated management method described in Embodiment 1 of the present invention;

[0055] Figure 3 This is a schematic diagram of the logical flow of the fully automated management method for software component release described in Embodiment 1 of the present invention;

[0056] Figure 4 This is a schematic diagram of the logic flow of the release failure handling steps in the software component release full-process automated management method described in Embodiment 1 of the present invention;

[0057] Figure 5 This is a schematic diagram of the logical flow of the successful release processing steps in the software component release full-process automated management method described in Embodiment 1 of the present invention;

[0058] Figure 6 This is a schematic diagram of the architecture of the fully automated management system for software component release described in Embodiment 2 of the present invention;

[0059] Figure 7 This is a schematic diagram of the structure of the computer device described in Embodiment 4 of the present invention;

[0060] The markings in the attached diagram are explained as follows:

[0061] 1501. Processor; 1502. Communication interface; 1503. Memory; 1504. Communication bus. Detailed Implementation

[0062] The preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, so that the advantages and features of the present invention can be more easily understood by those skilled in the art, thereby providing a clearer and more explicit definition of the scope of protection of the present invention.

[0063] In the description of this invention, it should be noted that the embodiments described in this invention are only some embodiments of this invention, not all embodiments; based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0064] The terms "first," "second," etc., used in this specification, claims, and accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, apparatus, product, or device that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0065] In the description of this invention, it should be noted that:

[0066] CI (Continuous Integration) is a software development practice where team members frequently integrate their work.

[0067] CD (Continuous Delivery / Deployment) is based on CI and automatically deploys the integrated code to a "production-like environment" that is closer to the real operating environment.

[0068] VCS (Version Control System) is a version control system used to track changes to files and code, such as Git.

[0069] GitLab is an integrated software development platform based on Git.

[0070] Jenkins is an open-source automation server that can be used to implement CI / CD.

[0071] NPM (Node Package Manager) is the default package manager for Node.js.

[0072] An artifact repository is a repository used for storing, managing, and distributing software packages, such as Nexus and Artifactory.

[0073] A webhook is a mechanism that sends real-time data from one application to another via an HTTP POST request.

[0074] API (Application Programming Interface) is an interface for application programming.

[0075] MR (Merge Request) is a merge request, a feature on platforms like GitLab that requests the merging of code from one branch into another.

[0076] Example 1

[0077] This embodiment provides a method for automating the entire software component release process, such as... Figures 1-5 As shown, it includes the following steps:

[0078] The core functionality of this method lies in: using a web front-end as the operation entry point and a back-end service as the control core, integrating GitLab (VCS), Jenkins (CI server), Nexus (artifact repository), and WeChat Work (notification module), and achieving full-process automation through a closed-loop feedback mechanism, as detailed below:

[0079] S100, Request initiation steps, including:

[0080] S101. When a user logs in to the web front end, the system interface displays a list of publishable projects stored in the database.

[0081] S102. After the user selects the project and the code branch to be released, the front end sends the corresponding request to the back end.

[0082] S103. After receiving the request, the backend calls GitLab via API to obtain the current version number of the version configuration file (package.json) under that branch and returns it to the frontend for display.

[0083] S104. The user selects the version upgrade strategy (patch / minor version / major version) on the front end, fills in the change log and submits; the front end integrates information such as project ID, branch, new version number, and change log into a release request and synchronizes it to the back end.

[0084] S200, preprocessing and build triggering steps, include:

[0085] S201. After receiving the request, the backend first calls the GitLab API to check if there are any unmerged MapReduces in the corresponding branch. If so, the release request is rejected to ensure branch stability.

[0086] S202. After the check passes, the backend calls the GitLab API to update the version number of the package.json file corresponding to the branch in the code repository to the version specified by the user and then commits it.

[0087] S203. Subsequently, the backend stores the task information (task ID, project name, version number, update log, previous version number, etc.) in the database, marks the task status as "building", and then calls the Jenkins API to trigger the preset build task, passing the corresponding Git repository address, branch name, build command and other necessary parameters.

[0088] S300, build and release steps, including:

[0089] After receiving the above instructions, S301 and Jenkins pull the updated code from the specified branch from GitLab, execute the preset build script (such as npm run build) and release script (such as npm publish), and publish the package to Nexus.

[0090] S302. In the above process, the backend establishes a long connection with the frontend through the SSE interface, obtains build logs from Jenkins in real time and pushes them to the frontend for display, realizing process visualization and tracking.

[0091] S400, closed-loop feedback steps, including:

[0092] It should be noted that this step is the core step, and it performs differentiated processing based on the publishing results, using Webhook to enable callback communication between the external system and the backend, as follows:

[0093] S401, Handling Release Failures:

[0094] When Jenkins encounters an error while executing a build or release script, it determines that the task has failed. In response to the failure, it sends a failure notification and the corresponding task ID (in the form of an HTTP request) to a specific backend API via a pre-defined webhook or callback mechanism. After receiving the notification, the backend updates the corresponding task status in the database to "failed" and then performs the following key steps: the backend retrieves the previous version number of the corresponding task from the database, calls the GitLab API to automatically roll back the package.json version number to the pre-release state, and submits a record marked "rollback version due to publishfailure," thus completing the automated on-site recovery.

[0095] S402. Successful release processing:

[0096] Jenkins successfully sends the package, indicating successful task execution. In response, Nexus receives the package and sends a success notification and package information (in the form of an HTTP request) to a specific backend API via a pre-defined webhook. The backend matches the task in the database based on the package name and version number and marks the status as "successful." Subsequently, it executes a series of key automated operations: calls the GitLab API to update CHANGELOG.md (appending the update log to the file header or creating the file directly based on the current update log if it does not exist); calls the GitLab API to create a merge request (MR) from the development branch to the trunk branch, including version number and update log information in the title and description; and calls the WeChat Work API to push formatted information such as project name, version number, update log, and MR link to a specified WeChat Work group chat.

[0097] It should be noted that the above examples are merely for explaining the present invention and should not be construed as limiting the scope of protection of the present invention.

[0098] Example 2

[0099] This embodiment is based on the same inventive concept as the fully automated management method for software component release described in Embodiment 1, and provides a fully automated management system for software component release, such as... Figure 6 As shown, it includes:

[0100] The request initiation module is used to: obtain the version information to be released from the front end, and generate a release request based on the version information to be released;

[0101] The preprocessing and build triggering module is used to: perform stability verification on the release request in the backend, update the version number and build the release task after the verification is passed;

[0102] The build and release module is used to: respond to the release task by releasing the software package based on the updated code, build script, and release script, and perform visual tracking and supervision;

[0103] The closed-loop feedback module is used to: automatically roll back the old version in response to the release failure of the software package; and automatically update and push the new version's associated items in response to the release success of the software package.

[0104] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0105] Example 3

[0106] This embodiment provides a computer-readable storage medium, including:

[0107] The storage medium is used to store computer software instructions used to implement the software component release full-process automated management method described in Embodiment 1 above. It includes programs for executing the software component release full-process automated management method. Specifically, the executable program can be built into the software component release full-process automated management system described in Embodiment 2. In this way, the software component release full-process automated management system can implement the software component release full-process automated management method described in Embodiment 1 by executing the built-in executable program.

[0108] Furthermore, the computer-readable storage medium in this embodiment can be any combination of one or more readable storage media, wherein the readable storage medium includes an electrical, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof.

[0109] Example 4

[0110] This embodiment provides an electronic device, such as... Figure 7 As shown, the electronic device may include: a processor 1501, a communication interface 1502, a memory 1503, and a communication bus 1504, wherein the processor 1501, the communication interface 1502, and the memory 1503 communicate with each other through the communication bus 1504.

[0111] Memory 1503 is used to store computer programs;

[0112] When the processor 1501 executes the computer program stored in the memory 1503, it implements the steps of the fully automated management method for software component release described in Embodiment 1 above.

[0113] As one embodiment of the present invention, the communication bus mentioned in the terminal above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 7 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0114] As one embodiment of the present invention, the communication interface is used for communication between the aforementioned terminal and other devices.

[0115] In one embodiment of the present invention, the memory may include random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0116] As one embodiment of the present invention, the processor described above may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0117] It should be understood that in the various embodiments of this document, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this document.

[0118] It should also be understood that, in the embodiments herein, the term "and / or" is merely a description of the relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following associated objects have an "or" relationship.

[0119] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this document.

[0120] In the embodiments provided herein, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the couplings or direct couplings or communication connections shown or discussed may be indirect couplings or communication connections through some interfaces, devices, or units, or they may be electrical, mechanical, or other forms of connection.

[0121] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of the embodiments described herein, depending on actual needs.

[0122] Furthermore, the functional units in the various embodiments of this document can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0123] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this paper, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this paper. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0124] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for automating the entire software component release process, characterized in that, Includes the following steps: Request initiation steps: The front end obtains the information of the version to be released and generates a release request based on the information of the version to be released. Preprocessing and build triggering steps: The backend performs stability verification on the release request, and after the verification passes, updates the version number and builds the release task. Build and release steps: In response to the release task, the package is released based on the updated code, build script, and release script, and visual tracking and supervision are performed. Closed-loop feedback steps: In response to a failed release of the software package, an automatic rollback of the old version is performed; in response to a successful release of the software package, an automatic update and push operation of the new version's associated items is performed.

2. The method for automated management of the entire software component release process according to claim 1, characterized in that: The step of obtaining the information of the version to be released further includes: Responding to the user login front end, display a list of projects that can be published to the user; In response to the user's selection of a project and the code branch to be released, a corresponding request is sent to the backend. After receiving the request, the backend uses the GitLab API to retrieve the current version number of the version configuration file under the user's selected branch and returns it to the frontend as the version information to be released.

3. The method for automated management of the entire software component release process according to claim 1, characterized in that: The step of generating a release request based on the version information to be released further includes: On the front end, select the version upgrade strategy corresponding to the version information to be released, fill in the update log, and submit. The project ID, branch, new version number, and changelog are integrated into the release request and synchronized to the backend.

4. The method for automated management of the entire software component release process according to claim 1, characterized in that: The step of performing stability verification on the release request in the backend, updating the version number and building the release task after the verification passes, further includes: In response to the backend receiving the request, the backend calls the GitLab API to check if there is an unmerged MapReduce for the branch corresponding to the release request. If there is no unmerged MapReduce, the check is considered to have passed. In response to the successful check, the backend calls the GitLab API to update the version number of the corresponding code branch to the version specified by the user and commits the changes. The backend stores the task information in the database, marks the task status, and then calls the Jenkins API to trigger the preset build task, passing the corresponding necessary task parameters.

5. The method for automated management of the entire software component release process according to claim 1, characterized in that: The response to the release task build, based on the updated code, build script, and release script, involves releasing the software package and performing visual tracking and supervision, further including: Jenkins pulls the updated code from the specified branch of GitLab, executes the build script and the release script, and releases the package to Nexus; During execution, the backend establishes a long connection with the frontend through the SSE interface, retrieves build logs from Jenkins in real time, and streams them to the frontend for display.

6. The method for fully automated management of software component release according to claim 1, characterized in that: The step of performing an automatic rollback operation on the old version in response to the release failure of the software package further includes: If an error occurs while Jenkins is executing a build script or release script, the task is determined to have failed. In response to task execution failure, a failure notification and the corresponding task ID are sent to a specific backend API via a Webhook or callback mechanism. After receiving the notification, the backend updates the corresponding task status, then retrieves the previous version number of the corresponding task from the database, calls the GitLab API to automatically roll back the package.json version number to the pre-release state, and submits a reason annotation.

7. The method for fully automated management of software component release according to claim 1, characterized in that: The step of responding to the successful release result of the software package by performing automatic update and push operations for new version-related items further includes: The task is considered to have executed successfully in response to Jenkins successfully sending the package. In response to successful task execution, Nexus receives the package from Jenkins and sends a success notification and package information to a specific backend API via a webhook. The backend updates the task status based on the package name and version number, then calls the GitLab API to update CHANGELOG.md based on the changelog, and calls the GitLab API to create a development branch to the main branch's MapReduce (MR), including update information in the title and description. Finally, it calls the communication app's API to push formatted information including the project name, version number, changelog, and MR link to the corresponding communication group chat.

8. A fully automated management system for the software component release process, characterized in that, include: The request initiation module is used to: obtain the version information to be released from the front end, and generate a release request based on the version information to be released; The preprocessing and build triggering module is used to: perform stability verification on the release request in the backend, update the version number and build the release task after the verification is passed; The build and release module is used to: respond to the release task by releasing the software package based on the updated code, build script, and release script, and perform visual tracking and supervision; The closed-loop feedback module is used to: automatically roll back the old version in response to the release failure of the software package; and automatically update and push the new version's associated items in response to the release success of the software package.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of the software component release full-process automated management method according to any one of claims 1 to 7.

10. A computer device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; wherein: The memory is used to store computer programs; The processor is configured to execute the steps of the software component release full-process automated management method according to any one of claims 1 to 7 by running the program stored in the memory.

Images