Multi-developer applet development preview code management method and device, and electronic device

Abstract

The embodiment of the application provides a kind of multiple developer applet development preview code management method, device and electronic equipment, it is related to computer technology field, method includes: receiving multiple developers through developer interface initiated multiple applet construction requests;Multiple applet construction requests corresponding multiple construction tasks are sequentially placed in global serial construction queue maintained by server according to initiation time sequence;Global serial construction queue is used to control only one construction task is executed at the same time;The construction task currently executed in global serial construction queue is processed in whole link;Whole link processing includes product upload, product upload uses the unique upload robot number that is pre-allocated for the developer corresponding to construction task;After uploading successfully, the development preview code corresponding to construction task is generated, and the development preview code is sent to the developer interface.The method provided by the embodiment of the application guarantees the continuity of development preview code generation and test verification in multiple developer collaboration scenario.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus and electronic device for managing preview codes of multi-developer mini-programs. Background Technology

[0002] With the widespread use of mobile internet mini-programs, collaborative development of the same mini-program by multiple developers has become a common team work model. During the development process, developers need to frequently obtain development preview code in order to verify code modifications in real time.

[0003] In existing technologies, developers typically configure their own build environments and continuous integration tools on their local computers, manually execute compilation scripts, and upload the build artifacts to the mini-program developer platform to obtain the development preview code. However, this independent uploading method has significant drawbacks: when multiple developers simultaneously upload to the same target mini-program, the mini-program developer platform has limitations on concurrent uploads of the same application identifier, causing later-uploaded build artifacts to overwrite earlier-generated development preview codes, forcing other developers to interrupt their testing and verification; simultaneously, differences in local build environments among developers can easily lead to build failures due to inconsistencies, increasing troubleshooting costs; furthermore, development preview codes have an expiration date, and existing solutions lack a unified tracking and intuitive display of the development preview code's generation time and expiration status, requiring developers to manually record and judge, resulting in low management efficiency. These problems are particularly pronounced when team size increases and build requests become more frequent, severely restricting the development efficiency of mini-programs in multi-developer collaborative scenarios.

[0004] Therefore, a solution is urgently needed to address the above problems. Summary of the Invention

[0005] This application provides a method, apparatus, and electronic device for managing preview codes of multi-developer mini-programs, in order to address the deficiencies existing in the prior art.

[0006] This application provides a method for managing preview codes for multi-developer mini-programs, the method including: Receive multiple mini-program build requests initiated by multiple developers through the developer interface; wherein, the mini-program build request includes developer identifier, target mini-program identifier, and target code branch information; The multiple build tasks corresponding to the multiple mini-program build requests are sequentially placed into a global serial build queue maintained by the server according to the initiation time; wherein, the global serial build queue is used to control that only one build task is executed at any given time. The current build task in the global serial build queue is processed in a full-link manner; wherein, the full-link processing includes product uploading, and the product uploading uses a unique upload robot number pre-assigned to the developer corresponding to the build task; After successful upload based on the unique upload robot number, a development preview code corresponding to the construction task is generated and sent to the developer interface.

[0007] According to an embodiment of this application, a method for managing preview codes of multi-developer mini-programs is provided, wherein the end-to-end processing further includes: code retrieval operation, dependency installation command, and compilation command; The process of performing end-to-end processing on the currently executing build tasks in the global serial build queue includes: Check if the code repository cache corresponding to the target mini-program identifier already exists locally on the server; If the code repository cache corresponding to the target mini-program identifier already exists locally on the server, perform the code fetch operation on the code repository cache and switch to the target code branch indicated by the target code branch information; Create an isolated working directory corresponding to the currently executing build task, and copy the source code after switching to the target code branch to the isolated working directory; In the isolated working directory, the dependency installation command and the compilation command corresponding to the build environment are executed in sequence to generate build artifacts, and the build artifacts are uploaded to the mini program developer platform.

[0008] According to an embodiment of this application, a method for managing development preview codes for multi-developer mini-programs is provided, wherein generating a development preview code corresponding to the build task includes: Receive the development preview code image data returned by the mini-program developer platform after successful upload; The development preview code image data is saved as an image file, and an access address corresponding to the image file is generated; wherein, the access address is used by the developer interface to display the development preview code.

[0009] According to an embodiment of this application, a method for managing development preview codes for multi-developer mini-programs includes sending the development preview code to the developer interface, which comprises: The access address, build completion time, and expiration time of the development preview code are written into the build record; wherein, the expiration time is determined based on the build completion time plus a preset valid duration; The information in the build record is pushed to the developer interface so that the developer interface displays the development preview code and the corresponding remaining validity period.

[0010] According to an embodiment of this application, a method for managing development preview codes for multiple developers of a mini-program is provided. The developer interface displays the current validity status of the development preview codes corresponding to the multiple developers and multiple target mini-programs in a real-time countdown format. When the development preview code is found to have expired, interactive elements are displayed in the developer interface to guide the developer to re-initiate a build request.

[0011] According to an embodiment of this application, a method for managing development preview codes for multi-developer mini-programs, after generating the development preview code corresponding to the build task, the method further includes: Calculate and record the package size corresponding to the target mini-program identifier; The package volume data of each build is associated with the corresponding build time and stored to generate package volume change trend data; The data on the change in package volume is sent to the developer interface so that the developer interface can display the change in package volume in the form of a trend chart and issue an early warning when the package volume exceeds a preset limit threshold.

[0012] According to an embodiment of this application, a method for managing preview codes for multi-developer mini-programs includes the following steps in the execution of the global serial construction queue: After retrieving the construction task at the head of the queue, update the status of the construction task at the head of the queue to "in execution", and after the entire chain processing of the construction task at the head of the queue is completed, update the final status of the construction task at the head of the queue. Once the final state of the build task at the head of the queue is determined, the next build task is automatically retrieved and executed.

[0013] According to an embodiment of this application, a method for managing preview codes for multi-developer mini-programs, after performing end-to-end processing on the currently executing build tasks in the global serial build queue, the method further includes: If any step of the currently executing build task fails in the code pull operation, the dependency installation command, the compilation command, or the artifact upload, the build task will be marked as failed and error details will be recorded. After cleaning up the isolated working directory created for the build task, the next build task is retrieved from the global serial build queue and executed, ensuring that the global serial build queue is not blocked.

[0014] According to an embodiment of this application, a method for managing preview codes for multi-developer mini-programs, before performing the code retrieval operation on the code repository cache, the method further includes: Check the duration of the cached code repository; If the duration exceeds the preset cache retention period, delete the code repository cache and perform a code repository cloning operation.

[0015] This application embodiment also provides a multi-developer mini-program development preview code management device, the device comprising: The receiving module is used to receive multiple mini-program build requests initiated by multiple developers through the developer interface; wherein, the mini-program build request includes developer identifier, target mini-program identifier, and target code branch information; The storage module is used to sequentially place the multiple build tasks corresponding to the multiple mini-program build requests into a global serial build queue maintained by the server according to the initiation time; wherein, the global serial build queue is used to control that only one build task is executed at any given time. The processing module is used to perform end-to-end processing on the currently executing build tasks in the global serial build queue; wherein, the end-to-end processing includes product uploading, and the product uploading uses a unique upload robot number pre-assigned to the developer corresponding to the build task; The management module is used to generate a development preview code corresponding to the construction task after the upload is successful based on the unique upload robot number, and send the development preview code to the developer interface.

[0016] This application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the multi-developer applet development preview code management method described above.

[0017] This application also provides a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the multi-developer applet development preview code management method as described above.

[0018] This application also provides a computer program product, including a computer program, which, when executed by a processor, implements the multi-developer mini-program development preview code management method described above.

[0019] This application provides a method, apparatus, and electronic device for managing development preview codes for multi-developer mini-programs. It receives multiple mini-program build requests initiated by multiple developers through a developer interface. Each mini-program build request includes a developer identifier, a target mini-program identifier, and target code branch information. Multiple build tasks corresponding to these requests are sequentially placed into a globally serial build queue maintained by a server, according to their initiation order. This global serial build queue controls the execution of only one build task at a time. The currently executing build task in the global serial build queue undergoes end-to-end processing, including artifact uploading using a unique upload robot number pre-assigned to the developer corresponding to the build task. After successful uploading using the unique upload robot number, a development preview code corresponding to the build task is generated and sent to the developer interface. Therefore, this application, by combining a server-side global serial build queue with a pre-assigned unique upload robot number, completely eliminates the conflict problem of build artifacts overlapping during concurrent uploads by multiple developers, ensuring the continuity of development preview code generation and testing verification in multi-developer collaborative scenarios. Attached Figure Description

[0020] 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 some embodiments of the embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a flowchart illustrating the multi-developer mini-program development preview code management method provided in this application embodiment.

[0022] Figure 2 This is a complete flowchart of the multi-developer mini-program development preview code management method provided in the embodiments of this application.

[0023] Figure 3 This is a schematic diagram of the structure of the multi-developer mini-program development preview code management device provided in the embodiments of this application.

[0024] Figure 4 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, 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 the 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 without creative effort are within the protection scope of the embodiments of this application.

[0026] The following describes, with reference to the accompanying drawings, a method, apparatus, and electronic device for managing preview codes for multi-developer mini-programs according to embodiments of this application.

[0027] Figure 1 This is a flowchart illustrating the multi-developer mini-program development preview code management method provided in this application embodiment, such as... Figure 1 As shown, it includes the following: Step 100: Receive multiple mini-program build requests initiated by multiple developers through the developer interface; wherein, the mini-program build request includes developer identifier, target mini-program identifier, and target code branch information.

[0028] It should be noted that the implementing entity of this application can be a centralized management platform deployed on the server side. This platform runs in the form of a backend service and provides an interface to the frontend developer interface to realize unified construction scheduling and preview code management for multiple developers and multiple target mini-programs.

[0029] Specifically, the server first receives mini-program build requests initiated by multiple developers through the same developer interface. Each build request carries a developer identifier, a target mini-program identifier, and target code branch information. The developer identifier can be a unique ID or username on the platform, used to distinguish different developers' operations. The target mini-program identifier is the mini-program's unique identifier on the platform, such as the mini-program's AppID, used to indicate which mini-program needs to be built. The target code branch information points to a specific development branch of the mini-program in the code version management tool, such as a feature branch or hotfix branch in a Git repository, used to determine the source code version corresponding to this build.

[0030] Step 200: Place the multiple build tasks corresponding to the multiple mini-program build requests into the global serial build queue maintained by the server in the order of their initiation; wherein, the global serial build queue is used to control that only one build task is executed at any given time.

[0031] Specifically, when multiple build requests are received within a short period, the system does not process these requests in parallel. Instead, it encapsulates each request into a corresponding build task and places them sequentially into a global serial build queue maintained by the server, according to the order in which they were initiated. This global serial build queue is a task queue maintained in server memory or persistent storage. Its core scheduling rule is to strictly control that only one build task is allowed to enter the execution state at any given time, while the remaining tasks wait in the queue, thus forming the first layer of concurrency isolation at the server scheduling level.

[0032] Step 300: Perform end-to-end processing on the currently executing build tasks in the global serial build queue; wherein, the end-to-end processing includes product uploading, and the product uploading uses a unique upload robot number pre-assigned to the developer corresponding to the build task.

[0033] Specifically, for the build tasks currently being executed in this global serial build queue, the system performs end-to-end processing, meaning that all key operations involved in the build process are centrally and automatically completed on the server side. This covers the entire process from code synchronization, dependency installation, compilation and building to artifact upload and preview code generation, allowing developers to complete the operations without configuring any build toolchain locally. In this end-to-end processing, the artifact upload step uses a unique upload robot number pre-assigned to the developer corresponding to the build task.

[0034] It should be noted that the unique upload robot number here refers to an independent upload channel identifier pre-registered for each developer on the WeChat Mini Program developer platform, such as robot_id in the WeChat Mini Program platform. Different developers each hold a different number, so that the upload operations of different developers are carried out through different channels on the platform side, without overlapping or interfering with each other, thus forming a second layer of concurrency isolation at the platform upload level.

[0035] Step 400: After successful upload based on the unique upload robot number, generate a development preview code corresponding to the construction task and send the development preview code to the developer interface.

[0036] Specifically, once the product upload operation based on the unique upload robot number is successful, the system automatically triggers the generation of the development preview code. This involves obtaining the development preview code image data returned by the mini-program developer platform and storing it persistently. Subsequently, the development preview code and its related information are pushed to the aforementioned developer interface for centralized display, allowing all developers to intuitively view the status of their own and other team members' latest generated development preview codes in a unified web dashboard.

[0037] The above describes the steps of the multi-developer mini-program development preview code management method provided in this application embodiment. As can be seen from the above description, according to the multi-developer mini-program development preview code management method provided in this application embodiment, multiple mini-program build requests initiated by multiple developers through the developer interface are received; wherein, the mini-program build request includes a developer identifier, a target mini-program identifier, and target code branch information; multiple build tasks corresponding to the multiple mini-program build requests are sequentially placed into a global serial build queue maintained by the server according to the initiation order; wherein, the global serial build queue is used to control that only one build task is executed at any given time; the currently executed build task in the global serial build queue is processed in its entirety; wherein, the entirety processing includes uploading artifacts, wherein the artifact uploading uses a unique upload robot number pre-assigned to the developer corresponding to the build task; after successful uploading based on the unique upload robot number, a development preview code corresponding to the build task is generated, and the development preview code is sent to the developer interface. Therefore, this application embodiment combines a server-side global serial build queue with a unique upload robot number pre-assigned to developers, completely eliminating the conflict problem of build artifacts overlapping when multiple developers upload concurrently from both the server-side scheduling and platform upload levels, ensuring the continuity of development preview code generation and testing verification in multi-developer collaborative scenarios.

[0038] Based on the above embodiments, in this embodiment, the end-to-end processing further includes: code retrieval operation, dependency installation command, and compilation command; Step 300 involves performing end-to-end processing on the currently executing build task in the global serial build queue, including: Step 310: Check whether the code repository cache corresponding to the target mini-program identifier already exists on the local server.

[0039] Step 320: If the code repository cache corresponding to the target mini-program identifier already exists on the local server, perform the code retrieval operation on the code repository cache and switch to the target code branch indicated by the target code branch information.

[0040] Step 330: Create an isolated working directory corresponding to the currently executed build task, and copy the source code after switching to the target code branch to the isolated working directory.

[0041] Step 340: In the isolated working directory, execute the dependency installation command and the compilation command corresponding to the build environment in sequence to generate the build artifacts, and upload the build artifacts to the mini-program developer platform.

[0042] Specifically, when the system retrieves a build task from the global serial build queue and begins execution, it first checks whether a code repository cache corresponding to the target mini-program identifier in the build request already exists locally on the server. This code repository cache refers to a copy of the source code cloned from a remote version control repository (such as GitLab or GitHub) to a specified directory on the server disk when the server first processes a build task for a mini-program. Its directory path can be associated with the mini-program's AppID for easy lookup. Subsequent build tasks for the same mini-program can directly reuse this cache without completely cloning the remote repository again, thus saving network overhead and total build time. If the code repository cache already exists locally on the server, a code fetch operation is performed on the cache directory. This involves sequentially executing the remote repository data fetch command and the local workspace switch command, switching the current workspace to the specific branch indicated by the aforementioned target code branch information, such as a feature development branch or fix branch specified by the developer, and fetching the latest commit record of that branch to ensure that the source code used in subsequent builds remains synchronized with the remote repository.

[0043] Subsequently, the system creates an isolated working directory uniquely corresponding to the currently executing build task. This isolated working directory is named using a combination of timestamps and random strings, exists independently of the code repository cache directory, and is specifically used to hold the source code and intermediate artifacts of the current build task. The system copies the source code after switching to the target code branch from the code repository cache to this isolated working directory. During copying, irrelevant content such as dependency storage directories can be excluded to reduce disk usage and copying time. Inside this isolated working directory, the system automatically executes dependency installation commands and compilation commands corresponding to the build environment in sequence. The dependency installation commands call the project's package manager (such as pnpm install) to automatically parse and download all third-party dependency libraries required by the project. The compilation commands select the corresponding build script according to the build environment specified in the build request. For example, in the test environment, the packaging and compilation instructions are executed to generate the dist build artifact for the WeChat Mini Program test environment, while in the production environment, another set of compilation instructions is executed to generate the build artifact for the production environment. After the build artifact is generated, the system immediately calls the Mini Program Continuous Integration Toolkit in the isolated working directory and uploads the build artifact to the Mini Program Developer Platform with the unique upload robot number in the above embodiment, completing the fully automated processing from code to remote platform artifact.

[0044] Optionally, before performing the code fetch operation on the code repository cache in step 320, the method further includes: Check the duration of the cached code repository; If the duration exceeds the preset cache retention period, delete the code repository cache and perform a code repository cloning operation.

[0045] Specifically, in actual operation, the code repository cache stored locally on the server may expire due to prolonged inactivity, or the differences between it and the remote repository may accumulate to an excessive degree. Therefore, in this embodiment, after the system confirms that the code repository cache corresponding to the target mini-program identifier already exists locally on the server, and before performing the code fetch operation, it first checks the duration of the code repository cache. Duration refers to the length of time elapsed from the last time the code repository cache was used or updated to the current time, which can be obtained and calculated through timestamps recorded in the cache directory. The system compares this duration with a preset cache retention period, which is a time threshold that can be pre-configured by the platform administrator based on team collaboration frequency and server disk resources, for example, set to 24 hours or 48 hours. If the duration of existence does not exceed the preset threshold, it indicates that the cache is still in a relatively active state and can be directly reused to continue subsequent incremental fetch operations. If the duration of existence has exceeded the preset threshold, the code repository cache is identified as an expired cache. The system automatically deletes the cache directory to free up disk space and performs a complete code repository cloning operation on the remote repository corresponding to the target mini-program. That is, it downloads the latest complete source code copy of the target mini-program from the remote code version management repository to the local server to ensure that the local code base on which the subsequent build tasks depend is the latest, complete and reliable.

[0046] The multi-developer mini-program development preview code management method provided in this embodiment centralizes the entire chain of operations—code retrieval, dependency installation, compilation and building, and artifact uploading—onto the server side for automatic completion. By reusing existing code repository caches and creating isolated working directories, it eliminates differences in developers' local environments and avoids cross-interference of source code between multiple builds. By judging the duration of code repository caches and automatically cleaning up expired caches and re-executing cloning operations, it ensures that the local code base on the server side is always consistent with the remote repository and is complete and reliable, further improving the stability and build success rate of the continuous integration pipeline.

[0047] Based on the above embodiments, in this embodiment, step 400, generating the development preview code corresponding to the build task, includes: Step 410: Receive the development preview code image data returned by the mini-program developer platform after successful upload.

[0048] Step 420: Save the development preview code image data as an image file and generate an access address corresponding to the image file; wherein, the access address is used by the developer interface to display the development preview code.

[0049] Specifically, once the system successfully uploads the build artifact to the WeChat Mini Program developer platform using a unique upload robot ID, the platform returns a development preview code image, such as a PNG or JPEG encoded QR code, to the uploader. Testers or developers can scan the QR code using the Mini Program client to load the corresponding version of the code for real-time testing and verification. Upon receiving the image data, the system persistently saves it as an image file to the server's file storage system. After saving, the system generates an externally accessible address for the image file. The front-end developer interface can directly load and display the development preview code image in the browser by calling this address. This allows all team members to centrally view the latest development preview codes for each developer's branch in a unified web dashboard, without relying on the developer's local WeChat developer tools or manually transferring image files.

[0050] Further, in step 400, sending the development preview code to the developer interface includes: Step 430: Write the access address, build completion time, and expiration time of the development preview code into the build record; wherein, the expiration time is determined based on the build completion time plus a preset valid duration.

[0051] Step 440: Push the information in the build record to the developer interface so that the developer interface displays the development preview code and the corresponding remaining validity time; The developer interface displays the current validity status of the development preview codes for multiple developers and multiple target mini-programs in real-time countdown. If the development preview code is found to have expired, the developer interface displays interactive elements to guide the developer to re-initiate the build request.

[0052] Specifically, after each successful build and generation of an access address, the system writes the access address and the build completion time of this build into the corresponding build record in the database. Simultaneously, the system automatically calculates an expiration time based on the build completion time plus a preset validity period, and writes this expiration time into the build record as well. This preset validity period is the fixed validity period set by the WeChat Mini Program developer platform for the development preview code, such as the thirty minutes stipulated by the WeChat platform. Therefore, the expiration time can be obtained by adding thirty minutes to the build completion time.

[0053] Subsequently, the system proactively pushes this key information from the build records to the developer interface. Upon receiving the push data or obtaining the latest records through a polling interface, the developer interface displays the corresponding developer preview code image, generation time, and remaining validity period dynamically calculated based on the current time and expiration time for each build record on a unified developer code dashboard. This remaining validity period is presented as a real-time countdown, with the countdown value automatically decreasing every second, allowing all team members to intuitively and in real-time understand how long their own and others' developer preview codes remain valid. When the remaining validity period of a developer preview code reaches zero, indicating it has expired, the developer interface automatically switches to displaying interactive elements guiding developers to re-initiate a build request within the display area of ​​that developer preview code, such as "Rebuild" or "Generate New Code." Developers can directly jump to or trigger the build request submission process by clicking this button, without needing to manually record the time or switch to another interface for further operation. This significantly reduces test interruptions and management costs caused by expired developer preview codes in scenarios involving multiple developers collaborating in parallel.

[0054] The multi-developer mini-program development preview code management method provided in this embodiment enables multi-developer team members to intuitively grasp the validity of all preview codes without manually recording and tracking the status of development preview codes, thereby significantly reducing test interruptions and management costs caused by the expiration of development preview codes.

[0055] Based on the above embodiments, in this embodiment, after generating the development preview code corresponding to the build task in step 400, the method further includes: Calculate and record the package size corresponding to the target mini-program identifier; The package volume data of each build is associated with the corresponding build time and stored to generate package volume change trend data; The data on the change in package volume is sent to the developer interface so that the developer interface can display the change in package volume in the form of a trend chart and issue an early warning when the package volume exceeds a preset limit threshold.

[0056] Specifically, after each successful build task and the generation of development preview code, the system automatically calculates the package size of the build artifact corresponding to the target mini-program identifier. The calculated package size data is associated with the build time of each build and persistently stored in the database as a build record, thus accumulating into a time-series dataset of package sizes from all builds. Based on this historically associated data, the system generates trend data on the package size changes of the target mini-program.

[0057] Subsequently, the system sends the package size change trend data to the developer interface. Upon receiving this data, the developer interface visualizes it on the front-end page as a trend chart, such as a line chart or area chart, showing the change trajectory of package size over time or the number of builds. This allows developers to intuitively observe the evolution of code size. When the current build package size or historical trend indicates that the package size has exceeded the preset limit threshold, the system will automatically issue a warning on the developer interface. The warning may be displayed by marking the threshold position with a prominent warning line on the trend chart, along with text warning information or a pop-up notification, reminding developers to pay attention and optimize code size in a timely manner. This allows developers to avoid the risk of the mini-program failing to be submitted for review or released normally due to exceeding the package size limit during the development stage.

[0058] The multi-developer mini-program development preview code management method provided in this embodiment enables the development team to continuously track and quantify the changes in mini-program size during daily development, thereby discovering and avoiding the risk of being unable to submit for review or release normally due to exceeding the package size limit in advance.

[0059] Based on the above embodiments, in this embodiment, the execution process of the global serial construction queue includes: After retrieving the construction task at the head of the queue, update the status of the construction task at the head of the queue to "in execution", and after the entire chain processing of the construction task at the head of the queue is completed, update the final status of the construction task at the head of the queue. Once the final state of the build task at the head of the queue is determined, the next build task is automatically retrieved and executed.

[0060] Specifically, during system operation, a global serial build queue maintains a set of build tasks to be processed, arranged in chronological order of initiation. Each build task in the queue is associated with a status flag describing its current processing stage, such as not started, waiting in the queue, executing, successful execution, or failed execution. When the queue scheduler detects that no task is currently executing, it retrieves a build task from the head of the queue and updates its status flag to "in execution," indicating that the task has entered the full-link processing stage. Other tasks remain in the queue waiting state and will not be executed simultaneously. After the full-link processing of the head-of-the-queue build task is completed, the system updates its status flag to the corresponding final state based on the processing result. This final state can be success or failure, clearly identifying the final result of the build. Once the final state of the head-of-the-queue build task is determined and written to the database, the queue scheduler immediately and automatically retrieves the next build task from the queue, repeating the above status update and scheduling execution process.

[0061] Furthermore, after performing end-to-end processing on the currently executing build task in the global serial build queue in step 300, the method further includes: If any step of the currently executing build task fails in the code pull operation, the dependency installation command, the compilation command, or the artifact upload, the build task will be marked as failed and error details will be recorded. After cleaning up the isolated working directory created for the build task, the next build task is retrieved from the global serial build queue and executed, ensuring that the global serial build queue is not blocked.

[0062] Specifically, in actual operation, any step in the end-to-end processing—including code retrieval, dependency installation commands, compilation commands, and artifact upload—may fail due to network fluctuations, unreachable remote code repositories, dependency version conflicts, compilation syntax errors, or abnormalities in the mini-program developer platform interface. When a currently executing build task fails in any of the above steps, the system immediately terminates the subsequent processing flow of that task, updates the status of the build task to a failed state, and writes the error details generated by the failure into the build record. The error details may include the name of the failed step, the error code, and the error log text output to the console, so that developers can view the cause of the failure in the developer interface and perform targeted troubleshooting. After completing the status marking and error record writing for the build task, the system then performs a cleanup operation on the isolated working directory created by the build task on the server, deleting the temporary directory corresponding to the task and all files within it to free up disk space and prevent residual data from interfering with subsequent build tasks. After cleanup, the system automatically retrieves the next build task waiting to be executed from the global serial build queue in sequence and continues processing.

[0063] The multi-developer mini-program development preview code management method provided in this embodiment ensures that only one build task is in execution at any given time through a strict state-driven serial scheduling mechanism. This guarantees the consistency of concurrency control and the predictability of task execution order at the server-side scheduling level. It also ensures that the failure of a single task will not block build tasks submitted by other developers in the entire queue, thus ensuring the overall availability and robustness of the build service in multi-developer collaboration scenarios.

[0064] Figure 2 This is a complete flowchart of the multi-developer mini-program development preview code management method provided in the embodiments of this application. The following is a combination of... Figure 2 This application provides a complete description of the multi-developer mini-program development preview code management method provided in the embodiments.

[0065] Taking the WeChat Mini Program platform as an example, all steps involved in this process are executed centrally on the server side. Developers only need to operate through the web interface and do not need to configure any build environment locally.

[0066] Step 1: The user initiates a build request.

[0067] The process begins with the developer logging into the web management interface. The front end calls the GET / api / builds / all interface to obtain the latest build information for each mini-program and each developer, and renders and generates a matrix of developer cards with the developer as the row and the mini-program as the column. After the developer selects the target mini-program, target code branch and build environment in the developer card board, he / she clicks the build button. The front end then calls the POST / api / builds / build interface to submit a build request to the server.

[0068] Step 2: Parameter validation and enqueueing.

[0069] After receiving the request, the server verifies whether the target mini-program identifier exists, whether the developer identifier is valid, and whether the branch name format is legal. If the verification passes, a build record with a pending status is created in the `builds` table of the database. The task is then encapsulated and pushed into the global serial build queue by calling `buildQueue.add()`. The server then returns an enqueue confirmation and build ID to the client. If the verification fails, an error message is returned directly, and the process terminates.

[0070] Step 3: Queue scheduling and execution.

[0071] The queue scheduler checks if any tasks are currently in execution. If not, it retrieves the task at the head of the queue and updates its status to "running" before starting execution. If a task is in execution, it waits in the queue, continuously checking until the preceding task is completed, times out, or is manually canceled before it can be dequeued for execution.

[0072] Step 4: Git code synchronization.

[0073] The build service checks if the code repository cache for the mini-program exists in the local repo / {appid} / directory on the server. If it does not exist, it executes `git clone` to clone the remote repository to the local machine; if it already exists, it executes `git fetch --all`, `git checkout {branch}`, and `git pull` in sequence to ensure that the local code is consistent with the remote target branch.

[0074] Step 5: Create an isolated build directory.

[0075] The system uses a timestamp plus a random string as a unique identifier to create an isolated working directory in the system's temporary directory. The source code synchronized to the target branch in step 4 is copied into this directory, excluding the node_modules directory during copying, to ensure that multiple builds do not interfere with each other.

[0076] Step 6: Dependency installation and compilation.

[0077] In the isolated directory, execute `pnpm install` to install third-party dependencies, and then select the corresponding compilation command according to the build environment (e.g., `pnpm run build:mp-weixin:test`) to generate the dist build artifact required by WeChat Mini Program.

[0078] Step 7: Upload to WeChat platform.

[0079] The miniprogram-ci SDK is invoked to upload the dist artifact to the WeChat Developer Platform using the unique upload robot ID (range 10 to 30) and corresponding CI private key pre-assigned by the developer. Optional launch page path and query parameters can also be passed in.

[0080] Step 8: QR code generation and persistence.

[0081] After successful upload, receive the development preview code image data returned by the SDK, save it as a PNG file, organize the storage path in the format qrcodes / {appid}_{developerId}_{timestamp}.png, and expose the accessible URL address to the outside world through static routing.

[0082] Step 9: Packet volume record and database update.

[0083] Read the total size of the dist directory as the package size, update the build record to status=success, and write the QR code access address, build completion time, expiration time (completion time plus 30 minutes) and package size data.

[0084] Step 10, Cleanup and Notification.

[0085] Delete the temporary isolated working directory to free up disk space. The frontend calls the GET / api / builds / queue interface to poll the queue status and update the queue panel every 5 seconds. Simultaneously, the frontend starts a setInterval timer for each card on the developer code dashboard to refresh the countdown every second, focusing on checking the expire_time recorded in each card: if the current preview code has not expired, a QR code image is displayed with the remaining valid time (formatted to MM:SS); if it is identified as expired, an expiration message is displayed with an interactive element to "Click to Rebuild"; if the build record itself is in a build failure state, an error message is displayed and the user is guided to "Click to view error / retry". Regardless of whether the status is expired or failed, when the user clicks the corresponding entry to trigger a rebuild, the frontend will uniformly call the POST / api / builds / rebuild interface to initiate a rebuild request; after the rebuild task is successfully added to the server queue, the system returns a queueing success message to the client, thus completing the complete closed-loop operation from card status check to re-triggering the build. In addition, the system provides management operation and maintenance functions. Administrators can call POST / api / builds / queue / cancel-running to cancel currently running tasks, or call POST / api / builds / queue / clear to clear all waiting tasks, so as to maintain the stable operation of the queue in a timely manner in case of abnormal situations.

[0086] When any step of code synchronization, dependency installation, compilation, or upload fails, the system marks the build record as status=failed and writes error details. Then, it cleans up the temporary directory and automatically retrieves the next task from the queue to continue execution, ensuring that a single failure does not block the entire queue.

[0087] The following describes the multi-developer mini-program development preview code management device provided in the embodiments of this application. The multi-developer mini-program development preview code management device described below can be referred to in correspondence with the multi-developer mini-program development preview code management method described above.

[0088] Figure 3 This is a schematic diagram of the structure of the multi-developer mini-program development preview code management device provided in the embodiments of this application, such as... Figure 3 As shown in the embodiment of this application, the multi-developer mini-program development preview code management device includes: The receiving module 301 is used to receive multiple mini-program build requests initiated by multiple developers through the developer interface; wherein, the mini-program build request includes developer identifier, target mini-program identifier and target code branch information; Storage module 302 is used to sequentially place the multiple build tasks corresponding to the multiple mini-program build requests into a global serial build queue maintained by the server according to the initiation time; wherein, the global serial build queue is used to control that only one build task is executed at the same time. The processing module 303 is used to perform end-to-end processing on the currently executing build task in the global serial build queue; wherein, the end-to-end processing includes product uploading, and the product uploading uses a unique upload robot number pre-assigned to the developer corresponding to the build task; The management module 304 is used to generate a development preview code corresponding to the construction task after the upload is successful based on the unique upload robot number, and send the development preview code to the developer interface.

[0089] The multi-developer mini-program development preview code management device provided in this application embodiment receives multiple mini-program build requests initiated by multiple developers through the developer interface. Each mini-program build request includes a developer identifier, a target mini-program identifier, and target code branch information. Multiple build tasks corresponding to the multiple mini-program build requests are sequentially placed into a global serial build queue maintained by the server according to their initiation order. The global serial build queue is used to control that only one build task is executed at a time. The device performs end-to-end processing on the currently executing build task in the global serial build queue. This end-to-end processing includes artifact uploading, where the artifact uploading uses a unique upload robot number pre-assigned to the developer corresponding to the build task. After successful uploading based on the unique upload robot number, a development preview code corresponding to the build task is generated and sent to the developer interface. Therefore, this application embodiment, by combining the server-side global serial build queue with the unique upload robot number pre-assigned to the developer, completely eliminates the conflict problem of build artifacts overlapping when multiple developers upload concurrently, ensuring the continuity of development preview code generation and testing verification in multi-developer collaborative scenarios.

[0090] Based on the above embodiments, in this embodiment, the end-to-end processing further includes: code retrieval operation, dependency installation command, and compilation command; The processing module 303 is specifically used for: Check if the code repository cache corresponding to the target mini-program identifier already exists locally on the server; If the code repository cache corresponding to the target mini-program identifier already exists locally on the server, perform the code fetch operation on the code repository cache and switch to the target code branch indicated by the target code branch information; Create an isolated working directory corresponding to the currently executing build task, and copy the source code after switching to the target code branch to the isolated working directory; In the isolated working directory, the dependency installation command and the compilation command corresponding to the build environment are executed in sequence to generate build artifacts, and the build artifacts are uploaded to the mini program developer platform.

[0091] Based on the above embodiments, in this embodiment, the management module 304 is specifically used for: Receive the development preview code image data returned by the mini-program developer platform after successful upload; The development preview code image data is saved as an image file, and an access address corresponding to the image file is generated; wherein, the access address is used by the developer interface to display the development preview code.

[0092] Based on the above embodiments, in this embodiment, the management module 304 is further configured to: The access address, build completion time, and expiration time of the development preview code are written into the build record; wherein, the expiration time is determined based on the build completion time plus a preset valid duration; The information in the build record is pushed to the developer interface so that the developer interface displays the development preview code and the corresponding remaining validity period.

[0093] Based on the above embodiments, in this embodiment, the developer interface displays the current validity status of the development preview codes corresponding to the multiple developers and multiple target mini-programs in the form of a real-time countdown. When the development preview code is found to have expired, interactive elements are displayed in the developer interface to guide the developer to re-initiate the build request.

[0094] Based on the above embodiments, in this embodiment, the device further includes a computing module, specifically used for: After generating the development preview code corresponding to the build task. Calculate and record the package size corresponding to the target mini-program identifier; The package volume data of each build is associated with the corresponding build time and stored to generate package volume change trend data; The data on the change in package volume is sent to the developer interface so that the developer interface can display the change in package volume in the form of a trend chart and issue an early warning when the package volume exceeds a preset limit threshold.

[0095] Based on the above embodiments, in this embodiment, the execution process of the global serial construction queue includes: After retrieving the construction task at the head of the queue, update the status of the construction task at the head of the queue to "in execution", and after the entire chain processing of the construction task at the head of the queue is completed, update the final status of the construction task at the head of the queue. Once the final state of the build task at the head of the queue is determined, the next build task is automatically retrieved and executed.

[0096] Based on the above embodiments, in this embodiment, the device further includes a marking module, specifically used for: After performing end-to-end processing on the currently executing build tasks in the global serial build queue, If any step of the currently executing build task fails in the code pull operation, the dependency installation command, the compilation command, or the artifact upload, the build task will be marked as failed and error details will be recorded. After cleaning up the isolated working directory created for the build task, the next build task is retrieved from the global serial build queue and executed, ensuring that the global serial build queue is not blocked.

[0097] Based on the above embodiments, in this embodiment, the device further includes an inspection module, specifically used for: Before performing the code fetch operation on the code repository cache. Check the duration of the cached code repository; If the duration exceeds the preset cache retention period, delete the code repository cache and perform a code repository cloning operation.

[0098] Figure 4 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 4 As shown, the electronic device can be a robot or other electronic device. This electronic device may include: a processor 410, a communications interface 420, a memory 430, and a communication bus 440. The processor 410, communications interface 420, and memory 430 communicate with each other via the communication bus 440. The processor 410 can call logical instructions from the memory 430 to execute a multi-developer mini-program development preview code management method, including: Receive multiple mini-program build requests initiated by multiple developers through the developer interface; wherein, the mini-program build request includes developer identifier, target mini-program identifier, and target code branch information; The multiple build tasks corresponding to the multiple mini-program build requests are sequentially placed into a global serial build queue maintained by the server according to the initiation time; wherein, the global serial build queue is used to control that only one build task is executed at any given time. The current build task in the global serial build queue is processed in a full-link manner; wherein, the full-link processing includes product uploading, and the product uploading uses a unique upload robot number pre-assigned to the developer corresponding to the build task; After successful upload based on the unique upload robot number, a development preview code corresponding to the construction task is generated and sent to the developer interface.

[0099] Furthermore, the logical instructions in the aforementioned memory 430 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application embodiment, essentially, or the part that contributes to the prior art, or a 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 method described in at least one embodiment of this application embodiment. 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.

[0100] On the other hand, embodiments of this application also provide a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the multi-developer applet development preview code management method provided by the above methods, including: Receive multiple mini-program build requests initiated by multiple developers through the developer interface; wherein, the mini-program build request includes developer identifier, target mini-program identifier, and target code branch information; The multiple build tasks corresponding to the multiple mini-program build requests are sequentially placed into a global serial build queue maintained by the server according to the initiation time; wherein, the global serial build queue is used to control that only one build task is executed at any given time. The current build task in the global serial build queue is processed in a full-link manner; wherein, the full-link processing includes product uploading, and the product uploading uses a unique upload robot number pre-assigned to the developer corresponding to the build task; After successful upload based on the unique upload robot number, a development preview code corresponding to the construction task is generated and sent to the developer interface.

[0101] In another aspect, embodiments of this application also provide a non-transitory computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements the multi-developer applet development preview code management method provided by the above methods, including: Receive multiple mini-program build requests initiated by multiple developers through the developer interface; wherein, the mini-program build request includes developer identifier, target mini-program identifier, and target code branch information; The multiple build tasks corresponding to the multiple mini-program build requests are sequentially placed into a global serial build queue maintained by the server according to the initiation time; wherein, the global serial build queue is used to control that only one build task is executed at any given time. The current build task in the global serial build queue is processed in a full-link manner; wherein, the full-link processing includes product uploading, and the product uploading uses a unique upload robot number pre-assigned to the developer corresponding to the build task; After successful upload based on the unique upload robot number, a development preview code corresponding to the construction task is generated and sent to the developer interface.

[0102] The device embodiments described above are merely illustrative. 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 modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0103] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0104] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the embodiments of this application, and are not intended to limit them; although the embodiments of this application have been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for managing preview codes for multi-developer mini-programs, characterized in that, include: Receive multiple mini-program build requests initiated by multiple developers through the developer interface; wherein, the mini-program build request includes developer identifier, target mini-program identifier, and target code branch information; The multiple build tasks corresponding to the multiple mini-program build requests are sequentially placed into a global serial build queue maintained by the server according to the initiation time; wherein, the global serial build queue is used to control that only one build task is executed at any given time. The current build task in the global serial build queue is processed in a full-link manner; wherein, the full-link processing includes product uploading, and the product uploading uses a unique upload robot number pre-assigned to the developer corresponding to the build task; After successful upload based on the unique upload robot number, a development preview code corresponding to the construction task is generated and sent to the developer interface.

2. The method for managing preview codes for multi-developer mini-programs according to claim 1, characterized in that, The end-to-end processing also includes: code retrieval operations, dependency installation commands, and compilation commands; The process of performing end-to-end processing on the currently executing build tasks in the global serial build queue includes: Check if the code repository cache corresponding to the target mini-program identifier already exists locally on the server; If the code repository cache corresponding to the target mini-program identifier already exists locally on the server, perform the code fetch operation on the code repository cache and switch to the target code branch indicated by the target code branch information; Create an isolated working directory corresponding to the currently executing build task, and copy the source code after switching to the target code branch to the isolated working directory; In the isolated working directory, the dependency installation command and the compilation command corresponding to the build environment are executed in sequence to generate build artifacts, and the build artifacts are uploaded to the mini program developer platform.

3. The method for managing preview codes for multi-developer mini-programs according to claim 2, characterized in that, The generation of the development preview code corresponding to the build task includes: Receive the development preview code image data returned by the mini-program developer platform after successful upload; The development preview code image data is saved as an image file, and an access address corresponding to the image file is generated; wherein, the access address is used by the developer interface to display the development preview code.

4. The method for managing preview codes for multi-developer mini-programs according to claim 3, characterized in that, Sending the development preview code to the developer interface includes: The access address, build completion time, and expiration time of the development preview code are written into the build record; wherein, the expiration time is determined based on the build completion time plus a preset valid duration; The information in the build record is pushed to the developer interface so that the developer interface displays the development preview code and the corresponding remaining validity period.

5. The method for managing preview codes for multi-developer mini-programs according to claim 4, characterized in that, The developer interface displays the current validity status of the development preview codes for the multiple developers and multiple target mini-programs in real time countdown. If the development preview code is found to have expired, the developer interface displays interactive elements to guide the developer to re-initiate the build request.

6. The method for managing preview codes for multi-developer mini-programs according to claim 4, characterized in that, After generating the development preview code corresponding to the build task, the method further includes: Calculate and record the package size corresponding to the target mini-program identifier; The package volume data of each build is associated with the corresponding build time and stored to generate package volume change trend data; The data on the change in package volume is sent to the developer interface so that the developer interface can display the change in package volume in the form of a trend chart and issue an early warning when the package volume exceeds a preset limit threshold.

7. The method for managing preview codes for multi-developer mini-programs according to claim 2, characterized in that, The execution process of the global serial construction queue includes: After retrieving the construction task at the head of the queue, update the status of the construction task at the head of the queue to "in execution", and after the entire chain processing of the construction task at the head of the queue is completed, update the final status of the construction task at the head of the queue. Once the final state of the build task at the head of the queue is determined, the next build task is automatically retrieved and executed.

8. The method for managing preview codes for multi-developer mini-programs according to claim 7, characterized in that, After performing end-to-end processing on the currently executing build tasks in the global serial build queue, the method further includes: If any step of the currently executing build task fails in the code pull operation, the dependency installation command, the compilation command, or the artifact upload, the build task will be marked as failed and error details will be recorded. After cleaning up the isolated working directory created for the build task, the next build task is retrieved from the global serial build queue and executed, ensuring that the global serial build queue is not blocked.

9. The method for managing preview codes for multi-developer mini-programs according to claim 2, characterized in that, Before performing the code fetch operation on the code repository cache, the method further includes: Check the duration of the cached code repository; If the duration exceeds the preset cache retention period, delete the code repository cache and perform a code repository cloning operation.

10. A multi-developer mini-program development preview code management device, characterized in that, include: The receiving module is used to receive multiple mini-program build requests initiated by multiple developers through the developer interface; wherein, the mini-program build request includes developer identifier, target mini-program identifier, and target code branch information; The storage module is used to sequentially place the multiple build tasks corresponding to the multiple mini-program build requests into a global serial build queue maintained by the server according to the initiation time; wherein, the global serial build queue is used to control that only one build task is executed at any given time. The processing module is used to perform end-to-end processing on the currently executing build tasks in the global serial build queue; wherein, the end-to-end processing includes product uploading, and the product uploading uses a unique upload robot number pre-assigned to the developer corresponding to the build task; The management module is used to generate a development preview code corresponding to the construction task after the upload is successful based on the unique upload robot number, and send the development preview code to the developer interface.

11. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the multi-developer mini-program development preview code management method as described in any one of claims 1 to 9.

12. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the multi-developer mini-program development preview code management method as described in any one of claims 1 to 9.

Images