Automatic delivery system and method for application products

Abstract

The embodiment of the invention provides an automatic delivery system and method of an application product, which can package a customization demand input by a user into an HTTPS request data packet after receiving the customization demand on an aPaaS webpage, send the HTTPS request data packet to a transit server, and trigger a CI / CD assembly line task preset by a GitLab server, thereby realizing automatic delivery of the application product. The method comprises the following steps: receiving an HTTPS request data packet from an aPaaS webpage, so as to inject the HTTPS request data packet into a GitLab server through a transit server to generate a corresponding APP, and feeding back an execution result to the aPaaS webpage through a Webhook mechanism, so that a downloading instruction input by a user is received through the aPaaS webpage, and a corresponding application product is downloaded from an assembly line product library of the GitLab server through a GitLab API. The problem that a GitLab server is difficult to realize complex user customized logic and real-time component linkage through a graphical interface, so that the user experience is poor is solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of information technology, and in particular, to an automatic delivery system and method of application products. BACKGROUND

[0002] Existing CI / CD (Continuous Integration / Continuous Delivery) platforms, such as platforms corresponding to GitLab servers, can significantly improve software delivery efficiency through automated build, test, and deployment processes. However, the inventors have found that existing pipeline parameters corresponding to GitLab servers usually only support string or simple data type injection, lacking the ability to dynamically upload and pass customized files. It is difficult for GitLab servers to implement complex user customization logic and real-time component linkage through graphical interfaces, resulting in poor user experience. SUMMARY

[0003] The purpose of the embodiments of the present application is to provide an automatic delivery system and method of application products to solve the problem that GitLab servers are difficult to implement complex user customization logic and real-time component linkage through graphical interfaces, resulting in poor user experience. The specific technical solutions are as follows: The first aspect of the embodiments of the present application provides an automatic delivery system of application products, which comprises an aPaaS webpage, a relay server, and a GitLab server. The aPaaS webpage is configured to receive user inputted customization requirements, encapsulate the customization requirements into an HTTPS request data packet, and send the HTTPS request data packet to the relay server. The customization requirements include structured parameters and unstructured files. The relay server is configured to receive the HTTPS request data packet, send the HTTPS request data packet to the GitLab server through a GitLab API to trigger a pre-set CI / CD pipeline task of the GitLab server. The GitLab server is configured to execute the pipeline task in response to the HTTPS request data packet, generate customized application products and store them in a pipeline product library if the pipeline task is executed successfully, and send pipeline execution results including execution status to the relay server through a Webhook mechanism after the pipeline task is executed. The relay server is further configured to receive and analyze the Webhook data to obtain the pipeline execution results, and forward the pipeline execution results to the aPaaS webpage. The aPaaS webpage is further configured to receive a download instruction initiated by a user and send the download instruction to the relay server if the pipeline execution results indicate that the task is executed successfully. The transfer server is further configured to, in response to the download instruction, download the corresponding application product from a pipeline artifact library of the GitLab server through a GitLab API, and forward the downloaded application product to the aPaaS webpage for user download.

[0004] In a possible implementation, the transfer server is further configured to, after downloading the application product from the pipeline artifact library of the GitLab server, temporarily store the downloaded application product locally, and clean up the locally stored application product according to a preset cleaning strategy after forwarding the application product to the aPaaS webpage, wherein the cleaning strategy includes at least one of the following: automatically deleting the application product when a storage time of the application product reaches a preset threshold; deleting the application product immediately after confirming that the application product has been successfully forwarded to the aPaaS webpage; deleting the earliest application product in a storage time order when a local storage space usage rate exceeds a preset threshold.

[0005] In a possible implementation, the aPaaS webpage is further configured to: receive the pipeline execution result synchronized by the transfer server; if the pipeline execution result indicates that the task execution is successful, dynamically update the webpage interface to display prompt information including a packaging success state and an application product download entry; if the pipeline execution result indicates that the task execution fails, display a failure reason and a retriggering option.

[0006] In a possible implementation, the GitLab server executes the pipeline task through one or more GitLab runners, and the GitLab runner is deployed on a separate build server; the build server is preconfigured with an application packaging environment, and the packaging environment includes at least one of xcode and nodejs; The pipeline task includes a preset packaging script, and the packaging script is configured to: receive custom parameters and files injected by the transfer server; perform configuration replacement and resource update on application source code based on the custom parameters and files; invoke the application packaging environment to perform compilation and construction operations, and generate a customized App installation package as a pipeline product.

[0007] In one possible implementation, the relay server is deployed as a network proxy gateway, the aPaaS webpage communicates with the relay server via the public network, and the relay server communicates with the GitLab server via the intranet, so as to achieve secure isolation between external users and the internal build environment.

[0008] A second aspect of this application provides an automated delivery method for application products, applied to an automated delivery system for application products, the system comprising: an aPaaS webpage, a relay server, and a GitLab server; The method includes: The system receives customized requirements input by the user through the aPaaS webpage; encapsulates the customized requirements into an HTTPS request data packet; and sends the HTTPS request data packet to a relay server. The customized requirements include structured parameters and unstructured files. The relay server receives the HTTPS request data packet; the GitLab API sends the HTTPS request data packet to the GitLab server to trigger the GitLab server's preset CI / CD pipeline task. The GitLab server responds to the HTTPS request data packet and executes the pipeline task; if the pipeline task is executed successfully, a customized application artifact is generated and stored in the pipeline artifact library; and after the pipeline task is completed, the pipeline execution result containing the execution status is sent to the relay server through the Webhook mechanism. The relay server receives and parses the Webhook data to obtain the execution result; then forwards the execution result to the aPaaS webpage. The relay server receives and parses the Webhook data to obtain the pipeline execution result; and forwards the pipeline execution result to the aPaaS webpage. When the pipeline execution result indicates that the task has been successfully executed, the aPaaS webpage receives the download instruction initiated by the user and sends the download instruction to the relay server. In response to the download command, the relay server downloads the corresponding application product from the GitLab server's pipeline product library via the GitLab API, and forwards the downloaded application product to the aPaaS webpage for users to download.

[0009] In one possible implementation, the method further includes: After downloading application products from the pipeline product library of the GitLab server via the relay server, the downloaded application products are temporarily stored locally. After forwarding the application products to the aPaaS webpage, the locally stored application products are cleaned up according to a preset cleanup strategy. The cleanup strategy includes at least one of the following: automatically deleting the application products after the storage time reaches a preset threshold; or deleting the application products immediately after confirming that they have been successfully forwarded to the aPaaS webpage. When the local storage space usage exceeds a preset threshold, the earliest application artifacts are deleted in order of storage time.

[0010] In one possible implementation, the method further includes: The aPaaS webpage receives the pipeline execution results synchronized by the relay server; if the pipeline execution result indicates that the task was executed successfully, the webpage interface is dynamically updated to display a prompt message including the packaging success status and the application artifact download entry; if the pipeline execution result indicates that the task failed, the reason for the failure and the re-trigger option are displayed.

[0011] In one possible implementation, the GitLab server executes the pipeline tasks via one or more GitLab Runners deployed on a separate build server; the build server is pre-configured with an application packaging environment, which includes at least one of Xcode and Node.js. The pipeline task includes a preset packaging script, which is configured as follows: Receive customized parameters and files injected by the relay server; Based on the customized parameters and files, the application source code is configured to be replaced and resources are updated. The application packaging environment is invoked to perform compilation and build operations, generating a customized App installation package as a pipeline product.

[0012] In one possible implementation, the relay server is deployed as a network proxy gateway, the aPaaS webpage communicates with the relay server via the public network, and the relay server communicates with the GitLab server via the intranet, so as to achieve secure isolation between external users and the internal build environment.

[0013] Another aspect of the application embodiments also provides an electronic device, including: Memory, used to store computer programs; A processor, used to execute programs stored in memory, implements an automated delivery method for any of the above-mentioned application products.

[0014] In another aspect of the embodiments of this application, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements an automated delivery method for any of the above-described application products.

[0015] In another aspect of the embodiments of this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute an automated delivery method for any of the above-described application products.

[0016] Beneficial effects of the embodiments in this application: This application provides an automated delivery system and method for application artifacts. The system includes: an aPaaS webpage, a relay server, and a GitLab server. The aPaaS webpage receives customized requirements input by the user; encapsulates the customized requirements into an HTTPS request data packet; and sends the HTTPS request data packet to the relay server. The customized requirements include structured parameters and unstructured files. The relay server receives the HTTPS request data packet and sends it to the GitLab server via the GitLab API to trigger a preset CI / CD pipeline task on the GitLab server. The GitLab server responds to the HTTPS request data packet and executes the pipeline task. If the pipeline task executes successfully, a customized application artifact is generated and stored in the pipeline artifact library. After the pipeline task is completed, a pipeline execution result containing the execution status is sent to the relay server via a Webhook mechanism. The relay server is further configured to receive and parse Webhook data to obtain the pipeline execution result; and forward the pipeline execution result to the aPaaS webpage; the aPaaS webpage is further configured to receive a download instruction initiated by the user when the pipeline execution result indicates that the task has been successfully executed, and send the download instruction to the relay server; the relay server is further configured to respond to the download instruction, download the corresponding application product from the pipeline product library of the GitLab server through the GitLab API, and forward the downloaded application product to the aPaaS webpage for the user to download. The proposed solution, after receiving customized user input on the aPaaS webpage, encapsulates it into an HTTPS request data packet and sends it to a relay server. This triggers a pre-defined CI / CD pipeline task on the GitLab server, which then injects the HTTPS request data packet into the GitLab server to generate the corresponding app. The execution result is then fed back to the aPaaS webpage via a Webhook mechanism. The aPaaS webpage then receives the user's download command, downloads the corresponding application artifact from the GitLab server's pipeline artifact library via the GitLab API, and forwards the downloaded application artifact to the aPaaS webpage for user download. This allows for the generation of an app based on the user's customized input, solving the problem of GitLab servers struggling to implement complex user customization logic and real-time component interaction through a graphical interface, resulting in a poor user experience.

[0017] Of course, implementing any product or method of this application does not necessarily require achieving all of the advantages described above at the same time. Attached Figure Description

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

[0019] Figure 1 A schematic diagram of a structure for an automated delivery system of application products provided in an embodiment of this application; Figure 2 An interactive diagram of an automated delivery system for application products provided in an embodiment of this application; Figure 3 A flowchart illustrating an automated delivery method for application products provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0020] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art based on this application are within the scope of protection of this application.

[0021] The first aspect of this application provides an automated delivery system for application products, see [link to relevant documentation]. Figure 1 , Figure 1 This is a schematic diagram of an automated delivery system for application products provided in an embodiment of this application. The system includes: an aPaaS webpage (Application Platform as a Service, a cloud platform for rapidly building applications through low-code or model-driven methods) 101, a relay server 102, and a GitLab server (an integrated platform for managing the entire software development lifecycle, including code hosting, CI / CD (continuous integration / continuous delivery), and project management) 103. The aPaaS webpage 101 is used to receive customized requests input by the user; encapsulate the customized requests into an HTTPS (Hypertext Transfer Protocol Secure) request data packet; and send the HTTPS request data packet to a relay server; the customized requests include structured parameters and unstructured files; The relay server 102 is used to receive the HTTPS request data packet; and send the HTTPS request data packet to the GitLab server through the GitLab API (a programming interface provided by GitLab) to trigger the CI / CD pipeline task preset by the GitLab server. The GitLab server 103 is used to respond to the HTTPS request data packet and execute pipeline tasks; if the pipeline task is executed successfully, a customized application artifact is generated and stored in the pipeline artifact library; and after the pipeline task is executed, the pipeline execution result containing the execution status is sent to the relay server through the Webhook (web hook in web development) mechanism. The relay server 102 is also used to receive and parse Webhook data to obtain the pipeline execution result; and forward the pipeline execution result to the aPaaS webpage; The aPaaS webpage 101 is also used to receive a download instruction initiated by the user and send the download instruction to the relay server when the pipeline execution result indicates that the task has been successfully executed. The relay server 102 is also used to respond to the download command by downloading the corresponding application product from the pipeline product library of the GitLab server through the GitLab API, and forwarding the downloaded application product to the aPaaS webpage for users to download.

[0022] In this embodiment, when the aPaaS webpage receives customized requests input by the user, these requests may include, but are not limited to, the App (application) name, icon, launch image, version number, and selected packaging platform. The aPaaS webpage can encapsulate the received customized requests into an HTTPS request data packet and then send the HTTPS request data packet to a relay server. The customized requests may include structured parameters and unstructured files. Specifically, when encapsulating the HTTPS request data packet, existing solutions can be referenced.

[0023] During the app generation process, after receiving the HTTPS request data packet, the relay server can call the GitLab API to inject the HTTPS request data packet into the internal GitLab server to trigger the execution of a pre-configured packaging pipeline. The GitLab server is configured with Xcode (an integrated development environment) or Node.js (a service interface) as the app packaging environment. The GitLab server can receive and respond to the HTTPS request data packet, generate the app installation package, and then send Webhook data to the relay server via a Webhook mechanism to trigger the pre-set CI / CD pipeline task on the GitLab server. The Webhook data includes the execution result. In one example, the GitLab server pipeline is executed by a server with Git Runner installed, which is configured with Xcode, Node.js, and other relevant app packaging environments.

[0024] GitLab server 103 responds to the HTTPS request data packet and executes the pipeline task. If the pipeline task executes successfully, it generates customized application artifacts and stores them in the pipeline artifact repository. After the pipeline task execution is completed, it sends the pipeline execution result, including the execution status, to the relay server via a webhook mechanism. Specifically, the packaging script for the pipeline execution project, combined with injected customized parameters and files, generates a customized App installation package (pipeline artifacts / Artifacts (various output files summarizing the software development process)). Furthermore, after the pipeline execution is completed (or in progress), the GitLab server can also notify the relay server of the pipeline execution result via a webhook mechanism. This webhook is a lightweight, callback-based communication mechanism that allows the system to proactively send notifications when specific events occur, enabling real-time data interaction.

[0025] The relay server receives and parses the Webhook data to obtain the pipeline execution result, and then forwards the pipeline execution result to the aPaaS webpage. After the APP is generated, the relay server can receive and parse the Webhook data to obtain the execution result, and then forward the execution result to the aPaaS webpage. In actual use, this execution result can be information indicating successful or unsuccessful execution.

[0026] When the pipeline execution result indicates successful task execution, the aPaaS webpage receives the user-initiated download command and sends it to the relay server. After sending this information to the aPaaS webpage, the aPaaS webpage can parse and display it. Thus, after viewing the prompt information, the user can enter the download command through the aPaaS webpage.

[0027] In response to the download command, the relay server downloads the corresponding application artifact from the GitLab server's pipeline artifact library via the GitLab API, and forwards the downloaded application artifact to the aPaaS webpage for user download. In this application, after receiving the download command input by the user, the aPaaS webpage can send the download command to the relay server. The relay server then receives and responds to the download command, downloading the corresponding app from the GitLab server via the GitLab API.

[0028] As can be seen, the system of this application embodiment can encapsulate the user's customized input into an HTTPS request data packet and send it to a relay server after the aPaaS webpage receives the customized request. This triggers the pre-set CI / CD pipeline task of the GitLab server, which then injects the HTTPS request data packet into the GitLab server to generate the corresponding APP. The execution result is fed back to the aPaaS webpage through a Webhook mechanism. The aPaaS webpage receives the user's download instruction, downloads the corresponding application product from the GitLab server's pipeline product library through the GitLab API, and forwards the downloaded application product to the aPaaS webpage for the user to download. This enables the generation of corresponding APPs based on the user's customized input, solving the problem that GitLab server is difficult to implement complex user customization logic and real-time component linkage through a graphical interface, resulting in a poor user experience.

[0029] In one possible implementation, the relay server is further configured to temporarily store the downloaded application products locally after downloading them from the GitLab server's pipeline product library, and clean up the locally stored application products according to a preset cleanup strategy after forwarding them to the aPaaS webpage. The cleanup strategy includes at least one of the following: automatically deleting the application products after their storage time reaches a preset threshold; deleting them immediately after confirming that they have been successfully forwarded to the aPaaS webpage; and deleting the earliest application products in storage time order when local storage space usage exceeds a preset threshold. Specifically, "local" in this embodiment can refer to the location of the aPaaS webpage, and the specific storage location in actual use can be set according to user needs. In one example, after the webpage displays "Packaging successful," the user triggers a product download command. After receiving the download command, the relay server can call the GitLab API to download the application products from the GitLab server's pipeline products and store them locally.

[0030] In one possible implementation, the aPaaS webpage is further used to: receive pipeline execution results synchronized by the relay server; if the pipeline execution result indicates successful task execution, dynamically update the webpage interface to display a prompt message including a successful packaging status and an application artifact download entry; if the pipeline execution result indicates task failure, display the failure reason and a re-trigger option. The execution result in this embodiment may include execution success or failure information. After receiving this execution success or failure information on the webpage, it can display the information so that the user can input relevant commands based on the displayed information. In one example, the relay server parses Webhook data and synchronously updates the pipeline execution result (such as "packaging successful / failed") to the aPaaS webpage, achieving real-time feedback on the user's page.

[0031] In one possible implementation, the GitLab server executes the pipeline tasks through one or more GitLab Runners deployed on a separate build server. The build server is pre-configured with an application packaging environment, including at least one of Xcode and Node.js. The pipeline tasks include preset packaging scripts configured to: receive customized parameters and files injected by the relay server; perform configuration replacements and resource updates on the application source code based on the customized parameters and files; and invoke the application packaging environment to perform compilation and build operations, generating a customized App installation package as the pipeline output. In another possible implementation, the relay server is deployed as a network proxy gateway. The aPaaS webpage communicates with the relay server via the public network, and the relay server communicates with the GitLab server via the intranet, thereby achieving secure isolation between external users and the internal build environment. In this embodiment, after the aPaaS webpage receives the execution result, it parses the result. If the result indicates that packaging is incomplete, the generation can be considered a failure. The HTTPS request data packet is then re-injected into the GitLab server on the intranet via the GitLab API to generate the app. In actual use, this loop can be monitored. If the number of loop iterations is reached without successful generation, the loop can be terminated, and the HTTPS request data packet will no longer be injected into the GitLab server on the intranet via the GitLab API. A generation failure message can be displayed. The user-inputted customization requirements received by the aPaaS webpage include: App name, icon, launch image, version number, and one or more of the selected packaging platform. In actual use, this information can be set according to the user's actual needs. For example, an ODM (Original Design Manufacturer) App customization webpage built on the aPaaS system receives user-inputted customization requirements, including but not limited to App name, icon, launch image, version number, and selected packaging platform. The obtained user requirements (including structured parameters and unstructured files) are then encapsulated into an HTTPS request data packet.

[0032] To illustrate the solutions of the embodiments of this application, the following description is provided in conjunction with a specific example. (See [link to example]). Figure 2 , Figure 2 An interaction diagram for an automated delivery system of application products provided in this application embodiment includes: 1. User Requirement Acquisition and Parameter Encapsulation: The ODMApp customization webpage, built on an aPaaS system, receives user-inputted customization requirements, including but not limited to App name, icon, splash screen, version number, and selected packaging platform. The acquired user requirements (including structured parameters and unstructured files) are then encapsulated into an HTTPS request data packet.

[0033] 2. Pipeline Triggering and Intranet Proxy: After receiving an HTTPS request, the relay server securely injects the encapsulated custom parameters into the GitLab server by calling the GitLab API, thereby triggering the execution of the pre-configured packaging pipeline (CI script).

[0034] 3. App Building and Artifact Generation: The GitLab pipeline is executed by a server with Git Runner (a component for automating build, test, and deployment tasks) installed. This server is configured with an app packaging environment such as Xcode and Node.js. The pipeline executes the project's packaging script, and, combined with injected custom parameters and files, generates a customized app installation package (pipeline artifacts).

[0035] 4. Status Feedback and Webpage Synchronization: After the GitLab server completes (or is in the process of) the pipeline execution, it notifies the relay server of the pipeline execution result via a Webhook mechanism. The relay server parses the Webhook data and synchronously updates the pipeline execution result (such as "packaging successful / failed") to the aPaaS webpage, enabling real-time feedback to the user's page.

[0036] 5. Product Download Transfer and Local Storage: After the webpage displays "Packaging Successful," the user triggers a product download command. Upon receiving the download command, the transfer server calls the GitLab API to download the product from the GitLab server pipeline and store it locally.

[0037] 6. Secure distribution and final delivery: The relay server sends the locally stored product to the web page, ultimately allowing users to receive the customized App installation package.

[0038] A second aspect of this application provides an automated delivery method for application products, applied to an automated delivery system for application products, the system comprising: an aPaaS webpage, a relay server, and a GitLab server; See Figure 3 , Figure 3 A flowchart illustrating an automated delivery method for application products provided in this application embodiment, the method comprising: Step S31: Receive user-inputted customization requirements through the aPaaS webpage; encapsulate the customization requirements into an HTTPS request data packet; send the HTTPS request data packet to the relay server; the customization requirements include structured parameters and unstructured files; Step S32: Receive the HTTPS request data packet through the relay server; send the HTTPS request data packet to the GitLab server through the GitLab API to trigger the preset CI / CD pipeline task of the GitLab server; Step S33: The GitLab server responds to the HTTPS request data packet and executes the pipeline task; if the pipeline task is executed successfully, a customized application artifact is generated and stored in the pipeline artifact library; and after the pipeline task is completed, the pipeline execution result containing the execution status is sent to the relay server through the Webhook mechanism. Step S34: Receive and parse the Webhook data through the relay server to obtain the execution result; forward the execution result to the aPaaS webpage; Step S35: Receive and parse Webhook data through the relay server to obtain the pipeline execution result; and forward the pipeline execution result to the aPaaS webpage; Step S36: If the pipeline execution result indicates that the task has been successfully executed, the aPaaS webpage receives the download instruction initiated by the user and sends the download instruction to the relay server. Step S37: In response to the download command, the relay server downloads the corresponding application product from the pipeline product library of the GitLab server via the GitLab API, and forwards the downloaded application product to the aPaaS webpage for the user to download.

[0039] In one possible implementation, the method further includes: After downloading application products from the pipeline product library of the GitLab server via the relay server, the downloaded application products are temporarily stored locally. After forwarding the application products to the aPaaS webpage, the locally stored application products are cleaned up according to a preset cleanup strategy. The cleanup strategy includes at least one of the following: automatically deleting the application products after the storage time reaches a preset threshold; or deleting the application products immediately after confirming that they have been successfully forwarded to the aPaaS webpage. When the local storage space usage exceeds a preset threshold, the earliest application artifacts are deleted in order of storage time.

[0040] In one possible implementation, the method further includes: The aPaaS webpage receives the pipeline execution results synchronized by the relay server; if the pipeline execution result indicates that the task was executed successfully, the webpage interface is dynamically updated to display a prompt message including the packaging success status and the application artifact download entry; if the pipeline execution result indicates that the task failed, the reason for the failure and the re-trigger option are displayed.

[0041] In one possible implementation, the GitLab server executes the pipeline tasks via one or more GitLab Runners deployed on a separate build server; the build server is pre-configured with an application packaging environment, which includes at least one of Xcode and Node.js. The pipeline task includes a preset packaging script, which is configured as follows: Receive customized parameters and files injected by the relay server; Based on the customized parameters and files, the application source code is configured to be replaced and resources are updated. The application packaging environment is invoked to perform compilation and build operations, generating a customized App installation package as a pipeline product.

[0042] In one possible implementation, the relay server is deployed as a network proxy gateway, the aPaaS webpage communicates with the relay server via the public network, and the relay server communicates with the GitLab server via the intranet, so as to achieve secure isolation between external users and the internal build environment.

[0043] As can be seen, the method of this application embodiment can encapsulate the user's customized input into an HTTPS request data packet and send it to a relay server after the aPaaS webpage receives the customized request. This triggers the pre-set CI / CD pipeline task of the GitLab server, thereby injecting the HTTPS request data packet into the GitLab server through the relay server to generate the corresponding APP. The execution result is fed back to the aPaaS webpage through a Webhook mechanism. The aPaaS webpage then receives the user's download instruction, downloads the corresponding application product from the GitLab server's pipeline product library through the GitLab API, and forwards the downloaded application product to the aPaaS webpage for the user to download. This enables the generation of corresponding APPs based on the user's customized input, solving the problem that GitLab server is difficult to implement complex user customization logic and real-time component linkage through a graphical interface, resulting in a poor user experience.

[0044] In another aspect of the embodiments of this application, an electronic device is also provided, see [link to relevant documentation]. Figure 4 ,include: Memory 401 is used to store computer programs; When processor 402 executes a program stored in memory, it implements the following: The system receives customized requirements input by the user through the aPaaS webpage; encapsulates the customized requirements into an HTTPS request data packet; and sends the HTTPS request data packet to a relay server. The customized requirements include structured parameters and unstructured files. The relay server receives the HTTPS request data packet; the GitLab API sends the HTTPS request data packet to the GitLab server to trigger the GitLab server's preset CI / CD pipeline task. The GitLab server responds to the HTTPS request data packet and executes the pipeline task; if the pipeline task is executed successfully, a customized application artifact is generated and stored in the pipeline artifact library; and after the pipeline task is completed, the pipeline execution result containing the execution status is sent to the relay server through the Webhook mechanism. The relay server receives and parses the Webhook data to obtain the execution result; then forwards the execution result to the aPaaS webpage. The relay server receives and parses the Webhook data to obtain the pipeline execution result; and forwards the pipeline execution result to the aPaaS webpage. When the pipeline execution result indicates that the task has been successfully executed, the aPaaS webpage receives the download instruction initiated by the user and sends the download instruction to the relay server. In response to the download command, the relay server downloads the corresponding application product from the GitLab server's pipeline product library via the GitLab API, and forwards the downloaded application product to the aPaaS webpage for users to download.

[0045] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0046] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0047] The memory may include random access memory (RAM) or non-volatile memory (NVM), 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.

[0048] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0049] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores a computer program that, when executed by a processor, implements an automated delivery method for any of the above-described application products.

[0050] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, enables the computer to implement an automated delivery method for any of the above-described application products.

[0051] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a solid-state drive (SSD), etc.

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

[0053] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. Related parts can be found in the descriptions of the system embodiments.

[0054] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the scope of protection of this application.

Claims

1. An automated delivery system for application products, characterized by, The system comprises an aPaaS webpage, a relay server and a GitLab server; The aPaaS webpage is configured to receive a customized requirement input by a user, encapsulate the customized requirement into an HTTPS request data packet, and send the HTTPS request data packet to the relay server, wherein the customized requirement comprises structured parameters and unstructured files; The relay server is configured to receive the HTTPS request data packet, and send the HTTPS request data packet to the GitLab server through a GitLab API to trigger a preset CI / CD pipeline task of the GitLab server; The GitLab server is configured to execute the pipeline task in response to the HTTPS request data packet, generate a customized application product and store the customized application product in a pipeline product library if the pipeline task is executed successfully, and send a pipeline execution result comprising an execution status to the relay server through a Webhook mechanism after the pipeline task is executed; The relay server is further configured to receive and analyze the Webhook data to obtain the pipeline execution result, and forward the pipeline execution result to the aPaaS webpage; The aPaaS webpage is further configured to receive a download instruction initiated by the user and send the download instruction to the relay server if the pipeline execution result indicates that the task is executed successfully; The relay server is further configured to download the corresponding application product from the pipeline product library of the GitLab server through the GitLab API in response to the download instruction, and forward the downloaded application product to the aPaaS webpage for the user to download.

2. The system of claim 1, wherein The relay server is further configured to temporarily store the downloaded application product in the local storage after downloading the application product from the pipeline product library of the GitLab server, and clean up the application product stored in the local storage according to a preset cleaning strategy after forwarding the application product to the aPaaS webpage, wherein the cleaning strategy comprises at least one of the following: automatically deleting the application product after a storage time of the application product reaches a preset threshold; deleting the application product immediately after confirming that the application product has been successfully forwarded to the aPaaS webpage; deleting the earliest application product in a storage time order when a local storage space usage rate exceeds a preset threshold.

3. The system of any one of claims 1-2, wherein The aPaaS webpage is further configured to: receive the pipeline execution result synchronized by the relay server; if the pipeline execution result indicates that the task is executed successfully, dynamically update a webpage interface to display prompt information comprising a packaging success status and an application product download entry; and if the pipeline execution result indicates that the task is executed unsuccessfully, display a failure reason and a retriggering option.

4. The system of claim 1, wherein The GitLab server executes the pipeline task through one or more GitLab Runners, which are deployed on independent build servers; the build servers are pre-configured with an application packaging environment, which includes at least one of xcode and nodejs; The pipeline task includes a preset packaging script, which is configured to: Receive custom parameters and files injected by the relay server; Based on the custom parameters and files, perform configuration replacement and resource update on the application source code; Invoke the application packaging environment to perform compilation and construction operations to generate a customized App installation package as a pipeline product.

5. The system of claim 1, wherein: The relay server is deployed as a network proxy gateway, the aPaaS web page communicates with the relay server through a public network, and the relay server communicates with the GitLab server through an internal network to achieve secure isolation of external users and internal build environments.

6. An automated delivery method of an application product, characterized by, An automatic delivery system for application products, the system comprising an aPaaS web page, a relay server, and a GitLab server; The method comprises: Receiving custom requirements input by a user through the aPaaS web page; packaging the custom requirements into an HTTPS request data packet; and sending the HTTPS request data packet to the relay server; the custom requirements include structured parameters and unstructured files; Receiving the HTTPS request data packet through the relay server; sending the HTTPS request data packet to the GitLab server through a GitLab API to trigger a preset CI / CD pipeline task of the GitLab server; Executing the pipeline task in response to the HTTPS request data packet through the GitLab server; if the pipeline task is executed successfully, generating a customized application product and storing it in a pipeline product library; and after the pipeline task is executed, sending a pipeline execution result including an execution status to the relay server through a Webhook mechanism; Receiving and parsing Webhook data through the relay server to obtain the execution result; and forwarding the execution result to the aPaaS web page; Receiving and parsing Webhook data through the relay server to obtain the pipeline execution result; and forwarding the pipeline execution result to the aPaaS web page; In the case where the pipeline execution result indicates that the task is executed successfully, receiving a download instruction initiated by a user through the aPaaS web page, and sending the download instruction to the relay server; In response to the download instruction, downloading a corresponding application product from the pipeline product library of the GitLab server through a GitLab API, and forwarding the downloaded application product to the aPaaS web page for user download through the relay server.

7. The method of claim 6, wherein, The method further comprises: The application product downloaded from the pipeline product library of the GitLab server is temporarily stored locally through the transfer server after the downloading, and the application product is cleaned according to a preset cleaning strategy after the application product is forwarded to the aPaaS webpage, wherein the cleaning strategy comprises at least one of the following: the application product is automatically deleted when the storage time of the application product reaches a preset threshold; the application product is deleted immediately after it is confirmed that the application product has been successfully forwarded to the aPaaS webpage. When the local storage space usage rate exceeds a preset threshold, the earliest application product is deleted in the order of storage time.

8. The method of claim 7, wherein, The method further comprises: The aPaaS webpage receives the pipeline execution result synchronized by the transfer server; if the pipeline execution result indicates that the task execution is successful, the webpage interface is dynamically updated to display prompt information containing a packing success state and an application product download entrance; if the pipeline execution result indicates that the task execution fails, the failure reason and a retriggering option are displayed.

9. An electronic device, comprising: It comprises: A memory for storing a computer program; A processor for executing the program stored on the memory to implement the method of any one of claims 6-8.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program, and the computer program is executed by the processor to implement the method of any one of claims 6-8.

Images