Applet automatic construction method and device, computer device and medium

Abstract

This application relates to a method, apparatus, computer device, and medium for automated mini-program construction. The method includes: receiving a mini-program construction request from a mini-program configuration center, the mini-program construction request including a tenant identifier and a mini-program platform identifier; obtaining mini-program template code from a code repository, and obtaining mini-program customized data corresponding to the tenant identifier from the mini-program configuration center, denoted as target customized data; dynamically injecting the target customized data into the mini-program template code to generate customized mini-program code; performing multi-dimensional verification on the customized mini-program code; and after passing the verification, constructing a mini-program code package based on the customized mini-program code, and uploading the mini-program code package to the mini-program platform corresponding to the mini-program platform identifier. This application can achieve separation of tenant configuration and core code, support dynamic injection of differentiated configurations for different tenants, and improve the reliability of the construction operation through pre-verification.

Description

Technical Field

[0001] This application relates to the field of mini-program building technology, and in particular to a method, apparatus, computer equipment and medium for automated mini-program building. Background Technology

[0002] With the development of mobile internet, mini-programs have become an important carrier connecting users and services. In the enterprise service sector, the SaaS (Software as a Service) model is becoming increasingly popular, and service providers typically need to provide mini-program applications with brand, function, or interface differences to a large number of different tenants (enterprise customers). In this multi-tenant scenario, how to efficiently and reliably build and deliver mini-programs for each tenant has become a pressing technical problem to be solved.

[0003] Currently, common mini-program building and delivery solutions in the industry mainly have the following shortcomings: 1. Many solutions achieve differences between tenants by maintaining multiple copies of the code or by pre-setting a large number of conditional judgments in the code. This approach leads to a bloated codebase, high maintenance costs, and when tenants need to adjust themes, text, or feature switches, it often requires rewriting or compiling the code, resulting in low flexibility and efficiency. 2. Existing automated build tools (such as Jenkins, GitLabCI, etc.) are mostly focused on continuous integration and deployment of single applications. When dealing with dozens or hundreds of tenants, it is necessary to configure and maintain a separate build pipeline for each tenant. This process is not only cumbersome and difficult to scale, but also the pipelines are independent of each other, making it impossible to achieve unified configuration management, task scheduling, and quality control. 3. After obtaining the tenant configuration, the existing process usually goes directly to the compilation stage. If configuration errors or resource shortages occur during the build process, the build operation needs to be re-executed, which wastes a lot of build time and computing resources and complicates the troubleshooting process. Summary of the Invention

[0004] In response to the above-mentioned deficiencies or disadvantages, this application provides a method, apparatus, computer equipment, and medium for automated construction of mini-programs.

[0005] This application provides a method for automatically building a mini-program according to a first aspect. The method includes: receiving a mini-program build request from a mini-program configuration center, the mini-program build request including a tenant identifier and a mini-program platform identifier; obtaining mini-program template code from a code repository, and obtaining mini-program customized data corresponding to the tenant identifier from the mini-program configuration center, denoted as target customized data; dynamically injecting the target customized data into the mini-program template code to generate customized mini-program code; performing multi-dimensional verification on the customized mini-program code; and after the verification is passed, building a mini-program code package based on the customized mini-program code, and uploading the mini-program code package to the mini-program platform corresponding to the mini-program platform identifier.

[0006] In some embodiments, the target customization data includes tenant configuration files and theme configuration information; dynamically injecting the target customization data into the mini-program template code to generate customized mini-program code includes: merging the tenant configuration file in the target customization data with the default configuration file in the mini-program template code, and writing the merged configuration file into the mini-program template code; generating a customized theme variable configuration file based on the theme configuration information in the target customization data, and replacing the default theme variable configuration file in the mini-program template code with the customized theme variable configuration file.

[0007] In some embodiments, the target customization data further includes resource files; dynamically injecting the target customization data into the mini-program template code to generate customized mini-program code further includes: copying the resource files in the target customization data to the resource directory in the mini-program template code.

[0008] In some embodiments, building a mini-program code package based on customized mini-program code includes: determining the corresponding platform-specific build command according to the mini-program platform identifier, and executing the platform-specific build command to compile and package the customized mini-program code to generate a mini-program code package.

[0009] In some embodiments, determining the corresponding platform-specific build command based on the mini-program platform identifier and executing the platform-specific build command includes: calling a unified scheduling interface based on the mini-program platform identifier to obtain a target build adapter; the target build adapter is a platform build adapter corresponding to the mini-program platform identifier among a plurality of pre-set platform build adapters; each platform build adapter encapsulates the platform-specific build command for the corresponding mini-program platform; and calling the build interface of the target build adapter to execute the platform-specific build command.

[0010] In some embodiments, multi-dimensional verification is performed on the customized mini-program code, including: verifying whether the configuration fields in the target customized data are complete and the data types are correct; verifying whether the resource files in the target customized data exist; and calling the verification interface of the mini-program platform to verify the validity of the mini-program platform authentication information in the target customized data.

[0011] In some embodiments, the method further includes: collecting build results and build artifact metadata; the build artifact metadata includes the build results, build logs, package size and version number of the mini-program code package; and sending the build results and build artifact metadata back to the mini-program configuration center.

[0012] According to a second aspect, this application provides a mini-program automated build device, the device comprising: The request receiving module is used to receive mini-program build requests from the mini-program configuration center. The mini-program build request includes the tenant identifier and the mini-program platform identifier. The data acquisition module is used to obtain the mini-program template code from the code repository, and to obtain the mini-program customized data corresponding to the tenant identifier from the mini-program configuration center, which is referred to as the target customized data. The dynamic injection module is used to dynamically inject target customized data into the mini-program template code to generate customized mini-program code; The verification module is used to perform multi-dimensional verification on customized mini-program code; The automated build module is used to build a mini-program code package based on the customized mini-program code after the verification is passed, and then upload the mini-program code package to the mini-program platform corresponding to the mini-program platform identifier.

[0013] According to a third aspect, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements any of the applet automated construction methods described above.

[0014] According to a fourth aspect, this application provides a computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executed, implements any of the applet automation construction methods described above.

[0015] In this application, developers pre-develop and maintain a core set of mini-program code that does not contain any tenant information, namely mini-program template code, and store it in the code repository. Each tenant can configure its own unique mini-program customization data in the mini-program configuration center according to its own needs. Then, the tenant sends a mini-program build request to the automated build and deployment platform through the mini-program configuration center. After receiving the request, the automated build and deployment platform will automatically complete a series of operations for mini-program build, including: obtaining the mini-program template code from the code repository, obtaining the mini-program customization data corresponding to the tenant identifier from the mini-program configuration center as the target customization data, dynamically injecting the target customization data into the mini-program template code to generate customized mini-program code, performing multi-dimensional verification on the customized mini-program code, and after passing the verification, building a mini-program code package based on the customized mini-program code and uploading the mini-program code package to the mini-program platform corresponding to the mini-program platform identifier.

[0016] In this system, the mini-program template code and customized mini-program data are managed separately. During the automated build process, tenant-specific mini-program data is dynamically injected into the mini-program template code. This ensures the stability and reusability of core business logic. Furthermore, dynamic injection precisely integrates tenant-specific configurations, themes, and other information into designated locations within the mini-program template code during the build process. This allows a single set of source code to serve as a template, generating numerous tenant-specific applications with identical functionality but different interfaces and configurations by injecting different tenant configurations during the mini-program build process. This achieves the effect of a single codebase handling the diverse needs of multiple tenants, avoiding the exponential increase in development and maintenance costs associated with maintaining independent code branches for each tenant.

[0017] Furthermore, before executing the build operation based on the customized mini-program code, the customized mini-program code is proactively validated in multiple dimensions, such as verifying the legality of configuration data, the integrity of associated resource files, and the validity of key identity credentials. This allows errors that often surface in the later stages of the traditional build process or even the upload stage (such as incorrect configuration formats, missing images, and invalid keys) to be intercepted at the beginning of the build chain. By proactively detecting and preventing erroneous configurations from entering the subsequent time-consuming compilation and upload processes, the number of invalid builds caused by low-level errors can be effectively reduced, saving computing resources and waiting time, thereby improving the overall success rate and robustness of the build process. Attached Figure Description

[0018] Figure 1 This is a flowchart of an automated mini-program construction method according to one or more embodiments of this application; Figure 2 This is a schematic diagram of the structure of a mini-program automated construction device in another embodiment of this application; Figure 3 This is a schematic diagram of the internal structure of a computer device according to one or more embodiments of this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings. It should be understood that the described embodiments are merely some embodiments of this application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0020] In the following description, when referring to the accompanying drawings, the same numbers in different drawings denote the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0021] In the description of this application, it should be understood that the terms "first," "second," "third," etc., are used only to distinguish similar objects and are not necessarily used to describe a specific order or sequence, nor should they be construed as indicating or implying relative importance. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances. Furthermore, in the description of this application, unless otherwise stated, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0022] In response to the shortcomings or defects of related technologies, this application provides an automated method for building mini-programs, which is applicable to SaaS platforms for generating customized mini-programs for various tenants.

[0023] In some exemplary embodiments of this application, such as Figure 1 As shown, the method includes steps S110 to S150, and each step is described in detail below.

[0024] S110: Receives a mini-program build request from the mini-program configuration center. The mini-program build request includes the tenant identifier and the mini-program platform identifier.

[0025] In this application, the developers pre-develop and maintain a set of core mini-program code that does not contain any tenant information, namely mini-program template code, and store it in the code repository. Each tenant can configure its own unique mini-program customization data in the mini-program configuration center (hereinafter referred to as the configuration center) according to its own needs. Then, the mini-program configuration center sends a mini-program build request to the automated build and deployment platform (hereinafter referred to as the build platform). After receiving the request, the automated build and deployment platform will automatically complete a series of operations for mini-program build (including steps S110 to S150).

[0026] The code repository can be a remote repository (such as GitLab, GitHub, etc.) that hosts the mini-program template code using a version control system like Git. The configuration center is a SaaS platform module that centrally manages customized data for multi-tenant mini-programs. It is responsible for storing tenants' personalized configurations, themes, resource files, and other data, and provides a management interface and API (Application Programming Interface).

[0027] The mini-program build request is a request message initiated or triggered by the configuration center to request the build platform to execute build tasks.

[0028] The mini-program build request carries at least a tenant identifier and a mini-program platform identifier. The tenant identifier is a string used to uniquely identify a tenant (enterprise customer), such as tenant_001, and is used to distinguish data and operations from different tenants within the system. The tenant identifier carried in the mini-program build request refers to the target tenant's tenant identifier, which is the tenant that initiated or triggered the mini-program build request through the configuration center.

[0029] The mini-program platform identifier is a code that specifies the type of platform on which the mini-program runs, such as WeChat or Alipay.

[0030] For example, in this step, the configuration center can encapsulate a JSON (JavaScript Object Notation) request message after the tenant completes the configuration or clicks the "Publish" (or "Build") button. This message can be sent to the specified API interface of the build platform via HTTP (Hypertext Transfer Protocol) POST or a message queue (such as RabbitMQ).

[0031] The platform's scheduling service listens to this API interface. When it receives a mini-program build request, it parses the request and extracts the tenant identifier (such as the tenant_id field) and the mini-program platform identifier (such as the platformType field). The extracted information will be used as the context for this build task.

[0032] This step enables event-driven automated build triggering, reducing manual intervention, and clarifies the target tenant and mini-program platform for the build task, laying the foundation for accurate acquisition of tenant configuration and execution of build operations in the future.

[0033] S120: Obtain the mini-program template code from the code repository, and obtain the mini-program customization data corresponding to the tenant identifier from the mini-program configuration center, denoted as the target customization data.

[0034] The mini-program template code is a set of generic mini-program source code projects decoupled from specific tenants. It includes code for a basic framework layer, a general component layer, common logic modules, configuration and injection entry points, and a business layer. The basic framework layer serves as a unified entry point for component registration and routing configuration, encapsulating code for mini-program lifecycle management, page routing, global state management, and a unified API adaptation layer. The general component layer contains basic non-business UI (User Interface) components, such as navigation bars, bottom tabs, and form components. The common logic modules include code related to utility methods, network requests, user login, authentication, and other logic. The configuration and injection entry point is used to reserve an entry point for dynamically injecting tenant configuration files during the build phase. The business layer includes business pages and components shared by all tenants.

[0035] The configuration center stores pre-configured mini-program customization data for multiple tenants. This data refers to the set of differentiated information configured by a tenant in the configuration center to distinguish its mini-program from others, including but not limited to the mini-program's AppId, key, name, text, theme, UI style, and image resources. The mini-program customization data obtained in this step specifically refers to the data configured by the target tenant.

[0036] The target customized data is the customized data of the mini program obtained from the configuration center, which corresponds to the tenant identifier carried in the mini program build request.

[0037] For example, in this step, the build platform sends a request to the configuration query interface of the configuration center based on the tenant identifier carried in the mini-program build request, thereby obtaining the complete configuration data (usually in JSON format) and associated resource file packages of the target tenant. Simultaneously, the build platform executes the `git clone` or `git pull` command from the preset code repository address to pull the mini-program template code from the specified branch (e.g., `main`) to the build workspace. The data obtained from the configuration center (including JSON configuration and resource files) is the target customized data, which can be temporarily stored in a specific directory of the workspace for use in subsequent steps.

[0038] S130: Dynamically inject target customized data into the mini-program template code to generate customized mini-program code.

[0039] After obtaining the target customized data and the mini-program template code, the target customized data can be written, merged, or replaced into the specified location of the mini-program template code through a script program. The final code is the customized mini-program code.

[0040] This step uses a script to dynamically and precisely inject the tenant's customized mini-program data into a specified location in the general mini-program template code, thereby achieving the effect of generating N customized mini-programs from a single set of code.

[0041] S140: Perform multi-dimensional verification on customized mini-program code.

[0042] After generating the customized mini-program code, it undergoes multi-dimensional validation to ensure that the customized mini-program code meets the basic requirements for subsequent build and upload operations.

[0043] S150: After the verification is passed, a mini-program code package is built based on the customized mini-program code, and the mini-program code package is uploaded to the mini-program platform corresponding to the mini-program platform identifier.

[0044] This step will perform build and upload operations based on the customized mini-program code.

[0045] The build operation refers to the compilation and packaging process of a mini-program development framework (such as Taro or uni-app). This operation converts the source code into a code package that can run on the mini-program platform. The upload operation refers to submitting the mini-program code package generated through the build operation to the platform backend using the official tools or APIs provided by the mini-program platform, thus creating a new development version.

[0046] For example, in this step, the build platform switches the corresponding Node.js environment or build toolchain in the build environment based on the mini-program platform identifier. Then, it executes the corresponding build command, such as `npm runbuild:weapp` for WeChat mini-programs and `npm run build:alipay` for Alipay mini-programs. Next, the build tool compiles and packages the customized mini-program code, generating a mini-program code package in the `dist / ` directory. Finally, it calls the corresponding platform's upload tool (such as WeChat's `miniprogram-ci` or Alipay's `minidev`), passing in the tenant's `appId`, key, and code package path, to perform the upload operation.

[0047] After a successful upload, the platform can extract information such as the version number and upload time from the results returned by the platform.

[0048] This step automates complex compilation, packaging, and uploading operations, shields the differences in commands across different platforms, provides a unified release outlet, and improves multi-platform release efficiency.

[0049] This embodiment constructs an automated build pipeline. Driven by events, it achieves end-to-end automation from personalized tenant configuration to multi-platform mini-program deployment through core mechanisms such as separating tenant configuration from core code, dynamically injecting customized mini-program data for target tenants, and performing pre-validation on customized mini-program code. This not only supports the concurrent build needs of a large number of tenants but also significantly reduces error rates and improves delivery efficiency and system maintainability through standardized processes.

[0050] In some embodiments, the method further includes: collecting build results and build artifact metadata; the build artifact metadata includes the build results, build logs, package size and version number of the mini-program code package; and sending the build results and build artifact metadata back to the mini-program configuration center.

[0051] The build result refers to the final execution status of the entire automated build and upload process, which is usually "successful" or "failed".

[0052] Build artifact metadata refers to a series of descriptive data generated along with the build artifact (mini-program code package), such as build logs, package size, and version number. Build logs are detailed text records output by various tools, scripts, and consoles during the build and upload process, including step information, warnings, and error details. The mini-program code package size refers to the compressed size of the mini-program code package, usually measured in kilobytes (KB). The version number is a unique version identifier (e.g., 1.2.0) automatically generated or assigned by the platform after the mini-program code package is uploaded to the platform backend.

[0053] For example, in this step, the build platform can collect logs generated during the build operation in real time and output them to a buffer. After the build operation is completed, the file size of the mini-program code package is obtained through file system operations. After the upload operation is successful, the response data returned by the mini-program platform API is parsed, and the version number is extracted. At the end of the process, the execution status of all steps (such as steps S110 to S150) is summarized, and the final build result (such as success or failure) is determined. The final build result, build logs, package size, and version number can be encapsulated into a structured data object (such as JSON format), and the status callback API provided by the mini-program configuration center is called to send the encapsulated data object back. The API call can include the tenant identifier carried in this build request as an association key. After receiving the data sent back by the build platform, the configuration center updates the data to the records of the corresponding tenant and this build task, and displays it visually on the management interface (such as a build history list, status tags, and log viewer) to facilitate tenants and operations to track the mini-program deployment status.

[0054] This embodiment unifies previously isolated information, scattered across build server logs and different platform backends, into a single configuration center, providing administrators with an end-to-end transparent view. Operations personnel can quickly view the build status of all tenants, download logs to pinpoint failure causes, and monitor version iteration history from within the configuration center without needing to log into multiple servers or platform backends. Furthermore, this embodiment achieves true automation, making configuration change -> triggering a build -> deployment -> status feedback a complete, self-reporting, and controllable cycle, significantly enhancing the professionalism and user experience of SaaS delivery services.

[0055] In some embodiments, the target customization data includes tenant configuration files and theme configuration information; dynamically injecting the target customization data into the mini-program template code to generate customized mini-program code includes: merging the tenant configuration file in the target customization data with the default configuration file in the mini-program template code, and writing the merged configuration file into the mini-program template code; generating a customized theme variable configuration file based on the theme configuration information in the target customization data, and replacing the default theme variable configuration file in the mini-program template code with the customized theme variable configuration file.

[0056] A tenant configuration file contains non-UI logic configuration information such as specific business parameters, function switches, page route lists, and network request addresses configured by the tenant. Specifically, it is a structured data file (such as a JSON file).

[0057] Theme configuration information is a set of variable values ​​used to define the visual style of a mini-program, typically including design tokens such as primary color, secondary color, font size, corner radius, and spacing.

[0058] The default configuration file refers to the baseline configuration file pre-set in the mini-program template code, which contains common default values ​​and configuration structure for all tenants.

[0059] The merged configuration file refers to the new configuration file generated by merging the tenant configuration file with the default configuration file.

[0060] A customized theme variable configuration file is a style preprocessor file (such as theme.less or theme.scss) that is dynamically generated based on theme configuration information, and contains the specific values ​​of all CSS variables.

[0061] The default theme variable configuration file refers to a style file predefined in the mini-program template code that contains a set of neutral or basic design variables.

[0062] For example, in this embodiment, the build platform first reads the tenant configuration file (e.g., tenant-config.json) obtained from the configuration center and the default configuration file (e.g., src / config / default.json) in the mini-program template code project within the build workspace. Then, it executes a merge script (e.g., using the Node.js lodash.merge library for deep merging). This script recursively merges the key-value pairs of the tenant configuration file into the default configuration file, overriding the default value for conflicting keys. The final configuration file generated by the merge operation can be serialized and then written to the configuration file path loaded during application runtime in the mini-program template code (e.g., src / app.json or src / config / index.json) to complete the replacement. Then, it parses the theme configuration information in the target customized data. The theme configuration information can be a collection of key-value pairs (e.g., {"primary-color":"#00799E","font-size-large":"18px"}). Create a new style file (e.g., theme.less) containing a series of variable declaration statements. Each line binds a theme variable name (e.g., @primary-color) to its corresponding value (e.g., #00799E) obtained from the theme configuration information. This newly generated customized theme variable configuration file can be copied to the specified directory (e.g., src / styles / ) in the mini-program template code project, overwriting the original default theme variable configuration file. Finally, import other style files (e.g., app.less, component styles) from the mini-program template code into this theme file using @import, so that the new variable values ​​are used to generate the final CSS (Cascading Style Sheets) during compilation.

[0063] This embodiment enables flexible customization of business logic, allowing tenants to adjust application behavior (such as toggling functions or changing API addresses) by modifying JSON configuration files without altering the core code. This significantly improves configuration flexibility and management efficiency. Furthermore, by centrally replacing a single variable file, the entire mini-program's color scheme, fonts, and other visual styles can be globally changed, enabling rapid and consistent visual style switching. In addition, tenant administrators can adjust parameters such as colors through a visual interface in the configuration center, without the need for designers or front-end developers. The fully branded interface will be visible after the next build, greatly shortening the customization cycle.

[0064] In some embodiments, the target customization data further includes resource files; dynamically injecting the target customization data into the mini-program template code to generate customized mini-program code further includes: copying the resource files in the target customization data to the resource directory in the mini-program template code.

[0065] Resource files refer to static media files specific to the tenant, such as brand logos, background images, marketing banners, and landing page videos.

[0066] For example, in this embodiment, the build platform can read the tenant resource file directory obtained and decompressed from the configuration center in the build workspace, and determine the common directory path (e.g., src / static / or src / assets / ) used to store static resources in the mini-program template code. Then, all files in the tenant resource file directory (or files filtered according to a list) are recursively copied to the static resource directory of the mini-program template code, overwriting any existing files with the same name. After copying, these resources are referenced in the customized mini-program code via relative paths (e.g., ...).<imagesrc=”.. / .. / static / tenant-logo.png”> The statement can correctly point to the tenant's dedicated file.

[0067] This embodiment enables each tenant's mini-program to display its unique brand identity and promotional materials, enhancing the mini-program's exclusivity and brand recognition. This is key to SaaS services meeting enterprise customers' brand exposure needs. Furthermore, separating volatile, tenant-dependent resource files from stable program code reduces code repository redundancy, making resource uploading, updating, and management more independent and convenient.

[0068] In some embodiments, building a mini-program code package based on customized mini-program code includes: determining the corresponding platform-specific build command according to the mini-program platform identifier, and executing the platform-specific build command to compile and package the customized mini-program code to generate a mini-program code package.

[0069] Platform-specific build commands refer to code compilation and packaging instructions for specific mini-program platforms (such as WeChat and Alipay). These commands are usually provided by mini-program development frameworks (such as Taro and uni-app) or platform-specific toolchains, such as `npm run build:weapp` for WeChat mini-programs or `npm run build:alipay` for Alipay mini-programs.

[0070] Compilation refers to the process of converting the source code written by the developer (such as JavaScript, TypeScript, and style files) into a code format executable by the target mini-program platform. Packaging refers to organizing and compressing the compiled code files, template files, style files, and static resources according to the specifications of the mini-program platform, ultimately generating a code package that meets the upload requirements.

[0071] The mini-program code package is the final product of the build process. Specifically, it is a compressed file or directory that conforms to a specific platform format specification (such as .wxapkg or a specific directory structure) and can be directly uploaded to the mini-program platform backend.

[0072] For example, in this embodiment, the build platform executes a preset build script, which queries a preset platform command mapping table based on the mini-program platform identifier carried in the mini-program build request. This mapping table maintains the association between different platform identifiers and their corresponding specific build commands. Next, depending on the target platform (i.e., the mini-program platform corresponding to the mini-program platform identifier), specific environment preparation may be required, such as switching to the corresponding Node.js version or installing specific platform compilation dependencies (e.g., the corresponding versions of @tarojs / cli or miniprogram-ci). Then, in the prepared build environment, the build platform can execute the platform-specific build command found in the platform command mapping table as a subprocess. This command will run in the root directory of the customized mini-program code, initiating the framework's own compilation and packaging process. After the build framework completes its processing, it will generate the mini-program code package in the specified output directory (e.g., a platform-specific subdirectory under dist / or build / ).

[0073] This embodiment automates cross-platform builds. Specifically, by abstracting platform differences into a configurable command, the system can automatically execute the correct build process for mini-programs on different tenants and platforms, without requiring manual identification or command switching. Furthermore, regardless of the platform, this embodiment generates a standardized mini-program code package, providing consistent input for subsequent unified upload steps and simplifying process integration.

[0074] In some embodiments, determining the corresponding platform-specific build command based on the mini-program platform identifier and executing the platform-specific build command includes: calling a unified scheduling interface based on the mini-program platform identifier to obtain a target build adapter; the target build adapter is a platform build adapter corresponding to the mini-program platform identifier among a plurality of pre-set platform build adapters; each platform build adapter encapsulates the platform-specific build command for the corresponding mini-program platform; and calling the build interface of the target build adapter to execute the platform-specific build command.

[0075] The unified scheduling interface is a software interface that predefines standard build operation methods, such as `build()`. It provides a unified calling logic for all build operations, shielding them from the underlying implementation differences of different build operations.

[0076] The target build adapter refers to a specific object that is dynamically selected and instantiated at runtime based on the current mini-program platform identifier. This object implements the unified scheduling interface mentioned above.

[0077] Platform build adapters are software components that developers pre-implement for each specific supported mini-program platform (such as WeChat and Alipay). They encapsulate all the specific build details of the mini-program platform, including environment checks, command concatenation, error handling, etc., and provide services to the outside world by implementing a unified scheduling interface.

[0078] A build interface refers to the build methods exposed on the target build adapter object for external calls, such as the `build()` method mentioned above. Calling the build interface triggers the complete build logic encapsulated within the relevant platform's build adapter.

[0079] In this embodiment, when the process reaches the point where a build is required, the build script does not directly handle platform differences. Instead, it calls the unified scheduling interface of the build scheduler, passing the mini-program platform identifier carried in the mini-program build request as a parameter. The build scheduler internally maintains a factory (BuilderFactory) or registry, which can search for a matching adapter class in the pre-registered platform build adapter mapping based on the passed mini-program platform identifier and dynamically create its instance as the target build adapter for this build.

[0080] For example, a unified interface abstraction layer can be pre-established for the build and upload commands of different mini-program platforms. WeChat mini-programs and Alipay mini-programs implement this abstraction respectively. Finally, a unified scheduling entry point is used to achieve the purpose of shielding platform command differences and unifying build scheduling. A demonstration example is as follows: The following is an example of pseudocode for the abstraction layer: “interface IBuilder { build(): Promise <void>; upload(): Promise <void>; }".

[0081] The following is an example pseudocode for building an adapter in WeChat: "class WechatBuilder implements IBuilder { build() { execSync('npm run build:weapp');} upload() {} }".

[0082] The following is an example pseudocode for Alipay to build an adapter: "class AlipayBuilder implements IBuilder { build() { execSync('npm run build:alipay');} upload() {} }".

[0083] The unified scheduling entry point, BuilderFactory.create, can return a build adapter instance for the corresponding platform. An example pseudocode is as follows: "const builder = BuilderFactory.create(platformType); await builder.build(); await builder.upload();

[0084] Therefore, if wechat is passed in, WechatBuilder will be instantiated; if Alipay is passed in, AlipayBuilder will be instantiated.

[0085] Once the build script obtains an instance of the target build adapter, it doesn't need to know its specific type; it only needs to call its standard build interface, the `build()` method. The `build()` method of the target build adapter encapsulates all the build logic specific to that platform. This build logic includes at least: concatenating complete command-line arguments, setting platform-specific environment variables, executing platform-specific build commands in a safe manner, monitoring the build process, parsing build output logs, and converting platform-specific error messages into a standardized format. After the target build adapter completes execution, it returns the build success or failure status and standardized log information to the build script through the specified interface.

[0086] This embodiment enables unified management and scheduling of build logic, integrating scattered build scripts and logic for different platforms into a unified interface and adapter system. This makes the build platform's build script code clearer and more stable, requiring only interface-oriented programming and completely eliminating "if-else" conditional branches for different platforms, thus improving code maintainability. Furthermore, when supporting a new mini-program platform, developers only need to follow the unified scheduling interface specifications, implement an independent platform build adapter for that new platform, and register it in the build scheduler. No modifications to existing main process code, build logic, or other adapters are required, enabling the build platform to quickly and cost-effectively integrate into the new mini-program ecosystem. In addition, each platform build adapter can centrally handle exceptions and error code conversions for its corresponding platform, ensuring that errors are reported uniformly regardless of which platform the build fails, facilitating monitoring and alerting, and improving operational efficiency.

[0087] In some embodiments, multi-dimensional verification is performed on the customized mini-program code, including: verifying whether the configuration fields in the target customized data are complete and the data types are correct; verifying whether the resource files in the target customized data exist; and calling the verification interface of the mini-program platform to verify the validity of the mini-program platform authentication information in the target customized data.

[0088] Configuration fields refer to the various parameter items defined in the tenant configuration file, such as appId, pages (page list), window (window appearance), etc. Each field has an expected data type and format.

[0089] Correct data type means that the actual value of a configuration field conforms to its predefined type and format rules. For example, appId should be a string type and conform to the specific platform specification, color fields should be strings in the format #RRGGBB, and boolean switches should be true or false.

[0090] Resource files refer to static files referenced by paths in the configuration, such as images (.png, .jpg), icons, etc.

[0091] Mini Program platform authentication information refers to the credential pair used to prove the identity and permissions of an application to the mini program platform, which may include AppID (application unique identifier) ​​and AppSecret (application key).

[0092] The verification interface is an API provided by the WeChat Mini Program platform (such as WeChat and Alipay) to verify whether the AppID and AppSecret match and are valid.

[0093] For example, in this embodiment, regarding configuration field validation, the platform can read a predefined validation rule configuration file. This file predefines the names, types, formats (regular expressions), and whether empty fields are allowed for all required configuration fields. Then, the final configuration file (such as app.json) in the customized mini-program code is compared item by item with the validation rules to check whether all required fields exist and whether their values ​​conform to the defined data types and formats (for example, checking whether the value of the themeColor field is a valid hexadecimal color code). Any missing or incorrectly formatted fields will be recorded. If any field is found to be missing or incorrectly formatted, the validation is deemed to have failed.

[0094] Regarding resource file verification, the build platform can parse relevant configuration files and code to collect the relative paths of all referenced static resource files (such as the image path " / static / logo.png"). Then, in the customized mini-program's project directory, it checks one by one whether the corresponding file exists under each of the above paths. If any resource file path is missing, the verification is considered to have failed.

[0095] Regarding the verification of the platform's authentication information, the platform can extract the AppID and AppSecret from the tenant configuration file. Then, it constructs a request based on the extracted data to call the verification interface of the corresponding mini-program platform. If the verification interface can be successfully called (i.e., the verification interface returns a valid access token or a success response), it is determined that the AppID and AppSecret are valid and match.

[0096] This embodiment can proactively identify and intercept configuration errors, resource deficiencies, and invalid credentials that typically surface during compilation, uploading, or even runtime, before the build process begins. This avoids invalid compilation and uploading attempts due to basic errors, saving valuable computing resources and time, and making the build process more efficient and reliable. Furthermore, based on multi-dimensional verification results, it can accurately pinpoint whether the problem is a configuration error, resource loss, or key issue, greatly facilitating rapid troubleshooting for developers and operations personnel.

[0097] It should be noted that, regarding the steps included in the automated mini-program construction method provided in any of the above embodiments, unless otherwise explicitly stated herein, there is no strict order restriction on the execution of these steps; they can be executed in other orders. Furthermore, at least some of these steps may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is also not necessarily sequential, but can be performed alternately or in turn with other steps or at least a portion of the sub-steps or stages of other steps.

[0098] Based on the same inventive concept, this application also provides a device for automatically building mini-programs. In some embodiments, such as Figure 2 As shown, the automated mini-program building device includes the following modules: The request receiving module 110 is used to receive mini-program build requests from the mini-program configuration center. The mini-program build request includes the tenant identifier and the mini-program platform identifier. The data acquisition module 120 is used to obtain the mini-program template code from the code repository and to obtain the mini-program customized data corresponding to the tenant identifier from the mini-program configuration center, which is denoted as the target customized data. The dynamic injection module 130 is used to dynamically inject target customized data into the mini-program template code to generate customized mini-program code; Verification module 140 is used to perform multi-dimensional verification on customized mini-program code; The automated build module 150 is used to build a mini-program code package based on the customized mini-program code after the verification is passed, and upload the mini-program code package to the mini-program platform corresponding to the mini-program platform identifier.

[0099] In some embodiments, the target customization data includes tenant configuration files and theme configuration information. The dynamic injection module 130 is specifically used to: merge the tenant configuration file in the target customization data with the default configuration file in the mini-program template code, and write the merged configuration file into the mini-program template code; generate a customized theme variable configuration file based on the theme configuration information in the target customization data, and replace the default theme variable configuration file in the mini-program template code with the customized theme variable configuration file.

[0100] In some embodiments, the target customization data also includes resource files; correspondingly, the dynamic injection module 130 is also used to copy the resource files in the target customization data to the resource directory in the mini-program template code.

[0101] In some embodiments, the operation of the automated build module 150 to build a mini-program code package based on customized mini-program code includes: determining the corresponding platform-specific build command according to the mini-program platform identifier, and executing the platform-specific build command to compile and package the customized mini-program code to generate a mini-program code package.

[0102] In some embodiments, the automated build module 150 determines the corresponding platform-specific build command based on the mini-program platform identifier and executes the platform-specific build command, including: calling the unified scheduling interface based on the mini-program platform identifier to obtain the target build adapter; the target build adapter is the platform build adapter corresponding to the mini-program platform identifier among a plurality of pre-set platform build adapters; each platform build adapter encapsulates the platform-specific build command for the corresponding mini-program platform; and calling the build interface of the target build adapter to execute the platform-specific build command.

[0103] In some embodiments, the verification module 140 is specifically used to verify whether the configuration fields in the target customized data are complete and the data type is correct; to verify whether the resource files in the target customized data exist; and to call the verification interface of the mini-program platform to verify the validity of the mini-program platform authentication information in the target customized data.

[0104] In some embodiments, the apparatus further includes a data feedback module. The data feedback module is used to collect build results and build artifact metadata; the build artifact metadata includes the build results, build logs, package size, and version number of the mini-program code package; and to feed the build results and build artifact metadata back to the mini-program configuration center.

[0105] Specific limitations regarding the automated mini-program building device can be found in the limitations of the automated mini-program building method described above, and will not be repeated here. Each module in the aforementioned automated mini-program building device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0106] This application also provides a computer device. In some embodiments, the computer device includes 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 can implement the steps of the applet automation construction method provided in any of the above embodiments.

[0107] In some embodiments, the internal structure diagram of a computer device may be as follows: Figure 3 As shown, the computer device includes a processor, memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage medium. The database stores customized data such as pre-configured applets for each tenant; the specific data stored can be further specified in the above method embodiments. The network interface communicates with external terminals via a network connection. When the computer program is executed by the processor, it implements an automated applet construction method.

[0108] Those skilled in the art will understand that Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0109] This application also provides a computer-readable storage medium, in some embodiments of which a computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, it implements the steps of the applet automated construction method provided in any of the above embodiments.

[0110] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0111] Those skilled in the art will understand that implementing all or part of the processes in the above method embodiments can be accomplished by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), Synchlink, DRAM (SLDRAM), memory bus, direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0112] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0113] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.< / void> < / void>

Claims

1. A method for automatically building a mini-program, characterized in that, The method includes: Receive a mini-program build request from the mini-program configuration center. The mini-program build request includes a tenant identifier and a mini-program platform identifier. Obtain the mini-program template code from the code repository, and obtain the mini-program customization data corresponding to the tenant identifier from the mini-program configuration center, denoted as the target customization data; The target customized data is dynamically injected into the mini-program template code to generate customized mini-program code; The customized mini-program code was validated from multiple dimensions. After the verification is passed, a mini-program code package is built based on the customized mini-program code, and the mini-program code package is uploaded to the mini-program platform corresponding to the mini-program platform identifier.

2. The method according to claim 1, characterized in that, The target customization data includes tenant configuration files and theme configuration information; The step of dynamically injecting the target customized data into the mini-program template code to generate customized mini-program code includes: Merge the tenant configuration file in the target customized data with the default configuration file in the mini program template code, and write the merged configuration file into the mini program template code; A customized theme variable configuration file is generated based on the theme configuration information in the target customized data, and the default theme variable configuration file in the mini program template code is replaced with the customized theme variable configuration file.

3. The method according to claim 2, characterized in that, The target customization data also includes resource files; The step of dynamically injecting the target customized data into the mini-program template code to generate customized mini-program code further includes: Copy the resource files from the target customized data to the resource directory in the mini-program template code.

4. The method according to claim 1, characterized in that, The mini-program code package built based on the customized mini-program code includes: The platform-specific build command is determined based on the mini-program platform identifier, and the platform-specific build command is executed to compile and package the customized mini-program code to generate the mini-program code package.

5. The method according to claim 4, characterized in that, The step of determining the corresponding platform-specific build command based on the mini-program platform identifier and executing the platform-specific build command includes: The unified scheduling interface is invoked according to the mini-program platform identifier to obtain the target build adapter; the target build adapter is the platform build adapter corresponding to the mini-program platform identifier among a plurality of pre-set platform build adapters; each platform build adapter encapsulates the dedicated build commands for the corresponding mini-program platform; The target build adapter's build interface is invoked to execute the platform-specific build command.

6. The method according to claim 2, characterized in that, The multi-dimensional verification of the customized mini-program code includes: Verify that the configuration fields in the target customized data are complete and of correct data type; Verify that the resource files in the target customized data exist; The verification interface of the mini-program platform is invoked to verify the validity of the mini-program platform authentication information in the target customized data.

7. The method according to claim 1, characterized in that, The method further includes: Collect build results and build artifact metadata; the build artifact metadata includes the build results, build logs, package size, and version number of the mini-program code package; The construction results and the metadata of the construction products are sent back to the mini-program configuration center.

8. A mini-program automated build device, characterized in that, The device includes: The request receiving module is used to receive mini-program build requests from the mini-program configuration center. The mini-program build request includes a tenant identifier and a mini-program platform identifier. The data acquisition module is used to obtain the mini-program template code from the code repository and to obtain the mini-program customized data corresponding to the tenant identifier from the mini-program configuration center, which is denoted as the target customized data. The dynamic injection module is used to dynamically inject the target customized data into the mini-program template code to generate customized mini-program code; The verification module is used to perform multi-dimensional verification on the customized mini-program code; An automated build module is used to build a mini-program code package based on the customized mini-program code after verification, and upload the mini-program code package to the mini-program platform corresponding to the mini-program platform identifier.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.

10. A computer 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 method according to any one of claims 1 to 7.

Images