Multi-version control and management method based on monorepo

Abstract

The invention relates to the technical field of software configuration management, and discloses a monorepo-based multi-version control and management method, which comprises the following steps: receiving a version switching instruction containing a target global version identifier and an environment identifier; loading the physically isolated environment version configuration file from a preset path according to the environment identifier; a target configuration node corresponding to the target global version identifier is positioned in the configuration file, recursive branch information merging operation is executed based on inheritance attributes and branch attributes in the node, and a final branch configuration set containing all sub-module target states is generated; and traversing the final branch configuration set, and calling a version control tool to switch the working area state of each sub-module to the corresponding target sub-module version identifier. Through the environment isolation and increment inheritance model, the problems of version definition redundancy and environment confusion in a multi-module warehouse are solved, and accurate backtracking and atomization switching of sub-module states are achieved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of software configuration management, in particular to a multi-version control and management method based on monorepo. BACKGROUND

[0002] With the rapid development of Internet technology, the architecture of software systems is becoming increasingly complex, and microservices architecture has become the mainstream choice for building large-scale enterprise applications. In order to facilitate code sharing, unified construction and dependency management, more and more development teams adopt the strategy of multi-module unified repository (Monorepo) to manage large projects containing hundreds or even thousands of sub-modules (or sub-services). Under the Monorepo architecture, it is usually necessary to use customized version control tools (such as Git Submodules, Google Repo or various custom scripts) to coordinate the version correspondence between the main repository and each sub-module.

[0003] In actual engineering practice, the existing multi-module version management technology faces many challenges. At the configuration management level, the existing mainstream solutions mostly use the full snapshot method to define the version, that is, each global version number needs to record the commit hash or tag corresponding to all sub-modules under the current system. When the number of sub-modules contained in the system is large, even if only the function of one sub-module is upgraded, the information of hundreds of sub-modules that have not changed needs to be repeated in the new version configuration file. This full recording method not only causes the volume of the configuration file to grow exponentially with the version iteration, resulting in serious data redundancy, but also greatly increases the difficulty of manual maintenance and comparison, making it difficult for developers to quickly identify the real change point from thousands of lines of configuration.

[0004] At the environmental safety level, the existing version management tools often lack strict physical isolation mechanisms for multiple environments such as production, testing, and development. Usually, all version definitions are mixed in the same configuration file or the same branch structure, relying on human naming conventions (such as adding a suffix to the branch name) to distinguish between environments. This weak constraint mechanism is prone to human operational errors, such as mistakenly referencing unstable sub-module versions that are still in the testing phase when building production environment release packages, resulting in serious online failures. The lack of dynamic routing and physical blocking mechanisms based on environmental context makes the software release process vulnerable in terms of compliance and security.

[0005] In the execution stability level, the version switching operation involves file system read and write and network requests of a large number of sub-modules. The existing version control tools usually adopt serial or simple parallel processing logic when performing batch updates, and lack atomicity guarantee mechanism similar to database transactions. Once an abnormal situation such as network interruption, file lock conflict or insufficient permission occurs in the updating process, the operation is often directly terminated, resulting in that the warehouse is in an intermediate inconsistent state of partial update and partial old version. Such dirty state is not only difficult to repair manually, but also causes the local development environment or automatic construction pipeline to crash, which seriously affects the research and development efficiency. Therefore, a monorepo multi-version control method capable of efficiently managing incremental configuration, strictly isolating environmental risks and having transactional execution capability is urgently needed. SUMMARY

[0006] In view of the deficiencies of the prior art, the present application provides a monorepo-based multi-version control and management method, which solves the problems of complex sub-module version combination management, high configuration data redundancy and easy confusion of multi-environment version definition under the monorepo architecture.

[0007] To achieve the above purpose, the present application is implemented by the following technical solutions: The present application provides a monorepo-based multi-version control and management method. The method is based on a hierarchical inheritance configuration model and is started by analyzing a version switching instruction containing a target global version identifier and an environment identifier. The core mechanism is to dynamically map and load the corresponding environment version configuration file according to the environment identifier, and in this file, the logical mapping relationship between the global version identifier and the configuration node is pre-constructed. Each configuration node is designed as a data structure containing inheritance attributes and branch attributes, wherein the inheritance attributes are used to establish a logical link of the current node pointing to the parent global version identifier, and the branch attributes are used to record the incremental changes of the current node relative to the parent node at the sub-module level.

[0008] After locating the target configuration node corresponding to the target global version identifier, the method does not directly read the static configuration, but triggers a recursive branch information merging operation. The logic of this operation is to backtrack along the path defined by the inheritance attribute, recursively obtain the configuration results of the parent configuration node to construct the basic configuration set, and according to the order from the parent node to the child node, use the sub-module branch information defined in the branch attribute of the target configuration node to update the same sub-module information in the basic configuration set. Through this dynamic calculation, the final branch configuration set containing the explicit state of all sub-modules is generated. Then, the system traverses the set and calls the version control tool to accurately switch each sub-module in the monorepo to the corresponding target state.

[0009] Further, to ensure the specification of version identification, the system performs format checking logic on the target global version identification before loading the environment version configuration file. This logic verifies whether the identification strictly follows the preset hierarchical definition format, i.e., sequentially contains the major version number, minor version number, patch version number, and hotfix version number, to ensure that the global version identification has a clear semantic level.

[0010] Further, in the implementation of multi-environment isolation, the method constructs independent production environment, test environment, and development environment version configuration files in the physical storage layer in advance. The system loads the configuration file of the corresponding environment according to the environment identification in the instruction as the routing basis. This mechanism ensures that the configuration node inheritance relationship in different environments is physically isolated and does not interfere with each other.

[0011] Further, the specific implementation logic of the recursive branch information merging operation adopts a dictionary coverage strategy. The system traverses the branch attribute of the target configuration node, and for each submodule configuration item in it, checks whether it already exists in the recursively obtained base configuration set. If there is a record with the same name, a replacement operation is performed to update the base configuration set with the submodule version identification of the current node; if not, an addition operation is performed to add the new submodule name and version identification as a new record to the set. This process ensures that the configuration priority of the child node is higher than that of the parent node.

[0012] Further, the recursive logic includes an explicit termination determination mechanism. When tracing back to a configuration node that does not exist or has an empty inheritance attribute, the node is determined to be a root configuration node. At this time, the system directly extracts its branch attribute as the initial base configuration set and returns layer by layer, thereby ending the upward search process and preventing infinite loops.

[0013] Further, to ensure the safety of the switching operation, the method introduces an integrity check mechanism before switching. Before performing the actual Git operation, the system pre-traverses the final branch configuration set and performs a double check on each submodule: on the one hand, it checks whether the physical path of the submodule in the local file system exists, and on the other hand, it checks whether the target version identification of the submodule is valid in the repository record of the version control system. Only submodules that pass the above double checks will be included in the subsequent switching execution list, otherwise the system will record exception logs and automatically skip the submodule.

[0014] Further, when executing the switching instruction, the system has the ability to adapt to different types of version identification. The system analyzes the specific type of each submodule version identification in the final branch configuration set (including branch name, tag name, commit hash, or custom branch name), and constructs a Git switching command matching the type for execution, thereby compatible with various version reference methods.

[0015] Further, the method integrates an abnormal rollback mechanism to maintain the consistency of the system state. During the switching process, the system monitors the operation state in real time. Once any submodule switching failure is monitored, the interrupt logic is triggered immediately, and the version control tool is called reversely to restore all changed submodules to the initial version state before operation by using the pre-recorded original state information.

[0016] Further, the method includes the persistence processing of version information. After the switching process is completed, the system collects the current global version identifier, environment identifier, timestamp, and the effective final branch configuration set, serializes these runtime data into structured data objects, and writes them into the preset metadata file of the build product, thereby realizing the version self-description and traceability of the build product.

[0017] The application provides a monorepo-based multi-version control and management method. The method has the following beneficial effects: 1. The application sets an inheritance attribute pointing to the parent global version identifier in the configuration node and records the branch attribute with changes, thereby constructing a version inheritance model based on incremental update. This mechanism makes the child version only need to define the difference part relative to the parent version, and the unchanged submodules automatically inherit the parent configuration, thereby avoiding the repeated recording of all submodule full information, reducing the size and maintenance cost of the configuration file, and solving the management problem caused by excessive submodule combination under the monorepo architecture.

[0018] 2. The application realizes dynamic configuration routing based on environment context by analyzing the environment identifier and loading the physically isolated production, test, or development environment version configuration file from the preset path. This design ensures that different environments independently maintain their version inheritance trees, thereby blocking the risk of unstable configuration misrelease from the test or development environment to the production environment from the physical storage level, effectively improving the safety and standardization of the software release process.

[0019] 3. The application pre-checks the validity of the physical path and version identifier before executing the submodule switching, and automatically calls the version control tool to restore the changed modules to the original state when any submodule switching failure is monitored. This mechanism converts the complex batch switching operation into an atomic transaction operation, thereby preventing the code repository state inconsistency problem caused by partial submodule switching failure and ensuring the stability of the development environment. BRIEF DESCRIPTION OF DRAWINGS

[0020] Figure 1 The method flowchart of the application is shown in the figure. DETAILED DESCRIPTION

[0021] With reference to the drawings of the embodiments of the present application, the technical solutions in the embodiments of the present application will be clearly and completely described. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments of the present application, all the other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of the present application.

[0022] With reference to the drawings of the embodiments of the present application, the technical solutions in the embodiments of the present application will be clearly and completely described. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments of the present application, all the other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of the present application. Figure 1 The present application provides a monorepo-based multi-version control and management method, which is run on a computer device comprising a processor and a memory, and is used for version management of a software project under a multi-module unified repository (Monorepo) architecture. The multi-module unified repository comprises a plurality of physically path-separated and functionally independent sub-modules.

[0023] The method of the present embodiment is executed by a multi-version control system, which is logically divided into an instruction receiving module, an environment configuration loading module, a recursive merging calculation module, and a switching execution module.

[0024] Firstly, the instruction receiving module executes the step of receiving a version switching instruction. A user inputs a version switching instruction through a command line interface (CLI), and the instruction receiving module is responsible for capturing and parsing the instruction. The version switching instruction adopts a predefined parameter structure, which comprises a target global version identifier (i.e. CX version number) for specifying the overall state that the system expects to achieve, and an environment identifier for specifying the current operation context. In the present embodiment, the specific format of the version switching instruction is yarn checkout -- ver=[TargetVersion] -- env=[Environment].

[0025] The instruction receiving module parses the value of the --ver parameter from the above instruction as the target global version identifier, and parses the value of the --env parameter as the environment identifier. For example, when the instruction is yarn checkout --ver=CX2.0.4.0 --env=fat, the target global version identifier obtained by parsing is CX2.0.4.0, and the environment identifier is fat.

[0026] Then, the environment configuration loading module performs a configuration loading step according to the parsed environment identifier. In order to realize configuration isolation of different development stages, the system pre-constructs a plurality of physically isolated environment version configuration files in a preset storage path. These files correspond to different environment identifiers respectively. In this embodiment, the preset mapping rule is as follows: if the environment identifier is prod (production environment), the configuration file named prod-versions.json is loaded; if the environment identifier is fat (test environment), the configuration file named fat-versions.json is loaded; if the environment identifier is dev (development environment), the configuration file named dev-versions.json is loaded.

[0027] The environment configuration loading module matches the environment identifier to the corresponding file name, and reads the JSON format environment version configuration file from the file system into the memory. The environment version configuration file maintains a plurality of global version identifier (Key) and configuration node (Value) key-value pair mapping relationships. Each configuration node is a JSON object, which contains an extends attribute for pointing to the parent global version identifier, and a branches attribute for recording the existence of changes of the sub-modules under the current configuration node.

[0028] Subsequently, the recursive merging calculation module searches for a target configuration node corresponding to the target global version identifier in the environment version configuration file loaded into the memory. After positioning successfully, the recursive merging calculation module performs a recursive branch information merging operation on the target configuration node. The module first checks whether the target configuration node contains an extends attribute. If yes, the parent configuration node is recursively searched according to the value of the extends attribute until the root node without the extends attribute is found.

[0029] The recursive merging calculation module merges the sub-module branch information contained in the branches attribute of each node in the order from the parent node to the child node. During the merging process, if the branches attribute of the child node contains the same sub-module name as the parent node, the version identifier defined in the child node is used to overwrite the corresponding information in the parent node. After complete recursive merging calculation, a final branch configuration set containing all sub-module names and their final target version identifiers is generated.

[0030] Finally, the switch execution module executes the physical switch operation according to the final branch configuration set. The switch execution module traverses each submodule record in the set, obtains the relative path of the submodule in the Monorepo repository, and the target submodule version identifier. The target submodule version identifier supports multiple Git reference types, including branch name (Branch), tag name (Tag), or commit hash (CommitHash). The switch execution module sequentially calls the switch command of the version control tool (Git) for each submodule, updates the workspace of each submodule to the target state, and thus completes the version switch of the entire Monorepo system.

[0031] Referring to the accompanying drawings Figure 1 , the embodiment details the specification of version definition in the system, the internal logical structure of the configuration file, and the data organization form of the version inheritance model.

[0032] In the embodiment, the system uses a unified global version identifier (i.e., CX version number) to uniquely index the overall snapshot state of the multi-module unified repository. The global version identifier strictly follows a preset hierarchical definition format, which consists of a prefix character CX and four segments of numerical sequences, and is defined in the form of CX{major}.{minor}.{patch}.{hotfix}. Among them, major represents the major version number, which is used to identify major changes or incompatible updates at the architecture level; minor represents the minor version number, which is used to identify functional iterative updates; patch represents the patch version number, which is used to identify regular defect fixes; and hotfix represents the hotfix version number, which is used to identify the emergency release of the repair version. After receiving the version switch instruction, the system will first perform format verification logic to parse whether the input string conforms to the above regular rules, to ensure the semantic accuracy of the version identifier.

[0033] The environment version configuration file (such as prod-versions.json, fat-versions.json, or dev-versions.json) in the embodiment uses the standard JSON (Java Script Object Notation) data exchange format for storage. The file internally constructs a key-value mapping table, where the key (Key) is the CX version number described above, and the value (Value) is the corresponding configuration node object (Version Log Object). Each configuration node object defines the state of the version through two core attributes, extends and branches.

[0034] The `extends` attribute is used to construct inheritance chains between versions. Its value is a string pointing to another existing CX version number (i.e., the parent version). Through this relationship, the current version node implicitly inherits the state of all submodules defined in the parent version. This chained structure allows the system to build a version inheritance tree, where nodes without an `extends` attribute or with an empty `extends` attribute are defined as the root version. By tracing the `extends` attribute, the system can trace back from any child node to the root node, thus obtaining the complete configuration context.

[0035] The `branches` property defines the incremental changes of the current version relative to its parent version. The value of this property is a nested dictionary object where the keys are the relative paths of the submodules in the Monorepo repository (e.g., `packages / components` or `services / jssdk`), and the values ​​are the specific version identifiers that the submodule should be in this CX version. This design allows configuration nodes to record only the submodules that have changed; submodules not listed in `branches` will automatically use the configuration from the parent version, thus achieving redundant storage of configuration information.

[0036] Specifically, the data structure in the environment version configuration file is shown in the following example: { "CX1.18.3.4":{ "branches":{ "packages / components":"v1.0.0_base", "services / jssdk":"v3.0.0_base" } }, "CX2.0.0.0":{ "extends":"CX1.18.3.4", "branches":{ "packages / components":"v2.0.0_feature_A", "services / jssdk":"v3.1.0_fix_B" } }, "CX2.0.0.1":{ "extends":"CX2.0.0.0", "branches":{ "services / jssdk":"v3.1.1_hotfix" } } } In the data structure described above, version CX1.18.3.4 does not define the `extends` property; therefore, as the root node of the inheritance tree, its `branches` property defines the basic state of all submodules. Version CX2.0.0.0 points to CX1.18.3.4 through the `sextends` property and redefines the versions of `packages / components` and `services / jssdk` in `branches`, indicating that these two submodules have changed in this version. Version CX2.0.0.1 further inherits from CX2.0.0.0, and its `branches` only contain `services / jssdk`, meaning that in CX2.0.0.1, only the `services / jssdk` module has been updated to v3.1.1_hotfix, while `packages / components` maintains the v2.0.0_feature_A state defined in CX2.0.0.0.

[0037] Furthermore, the submodule version identifier recorded in the `branches` property supports multiple Git reference types to adapt to different development scenarios. Specifically, these include: Tag name: Used to point to a stable release state, such as v2.0.0_release; Branch name: Used to point to an ongoing development line, such as feature / login_module; Commit Hash: Used to point to a snapshot of the changed code commit, such as a1b2c3d; Custom branch name: An identifier used for temporary or special purposes, such as v3.1.1_zz.

[0038] During parsing, the system passes the aforementioned identifiers as parameters to Git commands, thereby precisely controlling the detection status of submodules. Through this flexible identifier support, this invention can simultaneously support stable version release management and dynamic debugging of development versions.

[0039] See attached document Figure 1 This embodiment elaborates on the core algorithm logic executed by the version calculation module, which aims to dynamically synthesize the incremental configurations scattered in each node of the inheritance tree into a complete system state description.

[0040] In this embodiment, the recursive branch information merging operation is a dynamically triggered computation process at runtime, rather than a static reading process. The algorithm logic is activated once the system locates the target configuration node corresponding to the target global version identifier. The algorithm employs a depth-first strategy to handle the inheritance relationships between configuration nodes. Specifically, the algorithm first reads the `extends` attribute of the currently processed configuration node and determines whether the attribute exists and has a non-null value.

[0041] If the current configuration node is found to contain a valid extends attribute, the system pushes the current node onto the logic call stack, extracts the parent global version identifier pointed to by the extends attribute, and then transfers the execution focus to the parent configuration node corresponding to the parent identifier, repeating the above check process.

[0042] Preferably, in order to prevent infinite loops in version inheritance due to configuration errors, the recursive branch information merging operation also includes a circular dependency detection mechanism.

[0043] Specifically, during the recursive search process, the system maintains a visited set in memory. Whenever the system reads a new global version identifier and is ready to load its corresponding configuration node, it first checks whether the global version identifier already exists in the visited set.

[0044] If it does not exist, the global version identifier is added to the set of visited nodes, and the search and loading of the parent node continues.

[0045] If the loop already exists, the current inheritance chain is determined to have a circular dependency. The system immediately terminates the recursive process, throws a configuration exception error, and outputs the specific loop path information, thereby preventing the program from getting stuck in an infinite loop and protecting the stability of system resources.

[0046] This backtracking process continues until a configuration node that does not contain an `extends` attribute or whose `extends` attribute is empty is located. This node is determined by the system to be the root node of the version inheritance tree, and the contents recorded in its `branches` attribute constitute the initial basic configuration set for this inheritance chain.

[0047] After determining the root node, the system enters the regression merging phase, sequentially performing branch information overwriting and merging operations according to the path order from the root node to the target child node (i.e., the pop order of the logical call stack). For each child node on the path, the system performs dictionary merging of the submodule branch information defined in its branches attribute with the intermediate configuration set calculated by the previous level.

[0048] Dictionary merging follows a child-first overwrite strategy, specifically including the following three processing logics: Update Override: The system iterates through each submodule configuration item in the `branches` property of the current child node. If the name of the submodule already exists in the intermediate configuration set, a configuration change is considered to have occurred. The system then forcibly replaces the original version identifier of the submodule with the same name in the intermediate configuration set with the version identifier recorded in the current child node. This logic ensures that modifications made by the child version to the parent version take effect.

[0049] Adding a new module: If the submodule name contained in the `branches` property of the current child node does not exist in the intermediate configuration set, it is considered a new module. The system adds the name of the submodule and its version identifier as a new key-value pair record to the intermediate configuration set. This logic supports scenarios where new functional modules are dynamically introduced during iteration.

[0050] Inheritance Preservation: For submodules that exist in the intermediate configuration set but are not mentioned in the `branches` attribute of the current child node, the system retains their original version identifier and directly preserves them for the next round of calculation. This logic enables automatic inheritance of unchanged modules and is key to reducing configuration redundancy.

[0051] To illustrate the above logic more intuitively, let's take a specific three-level inheritance structure as an example: Assume there is a root node (version A), intermediate nodes (version B), and a target node (version C). Version A is the root node, and its `branches` attribute defines submodules `Module_X` and `Module_Y` as v1.0. Version B's `extends` attribute points to version A, and its `branches` attribute only defines submodule `Module_X` as v1.1. Version C's `extends` attribute points to version B, and its `branches` attribute only defines submodule `Module_Z` as v1.0.

[0052] When the user command switches to version C, the system's computation path is as follows: First, the system identifies the inheritance chain C->B->A. Next, it processes the root node A, generating a basic configuration set: {Module_X:v1.0, Module_Y:v1.0}. Then, the configuration of node B is merged into the basic set. Since node B defines Module_X:v1.1, the system updates Module_X in the basic set to v1.1; Module_Y is not defined in node B, so it remains v1.0. At this point, the intermediate result is: {Module_X:v1.1, Module_Y:v1.0}. Finally, the configuration of node C is merged into the intermediate result. Node C defines a new module Module_Z:v1.0, which the system appends to the set. Node C does not mention Module_X and Module_Y, so they retain the state calculated by node B. Finally, the system outputs the final branch configuration set used for switching execution: {Module_X:v1.1, Module_Y:v1.0, Module_Z:v1.0}.

[0053] Through the aforementioned recursive merging mechanism, this invention can accurately reconstruct a complete system snapshot at any point in time without storing a full copy, ensuring the accuracy of version control and the efficiency of storage.

[0054] See attached document Figure 1 This embodiment elaborates on the specific execution mechanism of the execution control module when it renders the final branch configuration set generated by the calculation into a physical file state, focusing on the integrity verification, dynamic instruction adaptation and transactional rollback guarantee mechanism included therein.

[0055] In this embodiment, in order to ensure the atomicity and security of the version switching operation, the system does not directly perform batch operations on the sub-modules in the unified multi-module repository indiscriminately, but strictly follows the engineering processing flow of pre-verification, dynamic execution, and circuit breaking in case of anomalies.

[0056] First, the system performs an integrity check before switching. After the recursive merge calculation module generates the final branch configuration set, and before invoking any write operation instructions, the system performs a full traversal pre-check of this set. This check includes verification in two dimensions: Physical path existence verification: Based on the relative paths of submodules recorded in the final branch configuration set, the system calls the operating system's file system interface (such as fs.stat or test -d) to check whether the corresponding directory structure exists in the local working area of ​​the unified multi-module repository. If the physical path of a submodule is detected to be non-existent (for example, the module has been removed from the current code baseline or has not yet been pulled), the system will determine that the submodule is an invalid object.

[0057] Version identifier validity verification: The system extracts the version identifier of the target submodule corresponding to each submodule and executes a reference verification command (e.g., `git rev-parse --verify` or `git ls-remote`) on the Git repository context of that submodule. This step is used to confirm whether the branch name, tag name, or commit hash recorded in the configuration file actually exists in the current Git object repository. If the target identifier points to a non-existent commit hash or a misspelled branch name, the system will determine that the configuration item is invalid.

[0058] If an anomaly is detected in any of the above verification steps, the system will immediately terminate the current switchover process, without performing any substantive file changes, and record the specific error information (including the name of the faulty submodule and the invalid version identifier) ​​in the error log, thereby avoiding placing the workspace in an intermediate state.

[0059] Secondly, after passing the integrity verification, the system enters the dynamic command adaptation and execution phase. Because submodule version identifiers have diverse types, the system has built-in identifier type inference logic. Based on string characteristics, it categorizes the identifiers and constructs matching Git switching commands. If the identifier matches the SHA-1 characteristic (such as a 40-bit hexadecimal string), the system recognizes it as a commit hash and constructs commands such as git checkout [Hash] or git reset --hard [Hash] to ensure that the submodule accurately reverts to the commit snapshot. This is typically used for accurate builds in production environments.

[0060] If the identifier contains the `tags / ` prefix or conforms to the semantic versioning naming convention, the system recognizes it as a tag and constructs a command like `git checkout tags / [Tag]`, putting the submodule in a detached HEAD state and locking it to the release node.

[0061] If the identifier does not conform to the above characteristics, the system will identify it as a branch name by default and construct a command like gitcheckout [Branch] followed by git pull to ensure that the submodule is switched to the development branch and synchronized with the latest remote code. This is usually used in development or testing environments.

[0062] Finally, this embodiment introduces a transactional exception rollback mechanism to handle runtime errors during execution (such as network interruptions, file lock occupancy, etc.). The specific execution logic of this mechanism is as follows: State snapshot recording: Before executing the first switch command, the system first traverses all sub-modules, records their current HEAD pointer position (i.e., the version state before the switch), and generates an original state mapping table.

[0063] Real-time monitoring and circuit breaking: The system executes submodule switching in a serial or controlled parallel manner and captures the exit code of each Git command in real time. If any submodule switching command returns a non-zero exit code (indicating execution failure), the system will trigger the circuit breaking mechanism to immediately stop all subsequent unexecuted submodule switching tasks.

[0064] Reverse recovery: After the circuit breaker is triggered, the system reads the pre-generated original state mapping table, executes the switch command in reverse for all submodules that have been changed in this operation, forces them to be restored to the original HEAD pointer, and executes working directory cleanup commands (such as git clean) to remove any possible residual temporary files.

[0065] Through the above mechanism, this embodiment ensures that the version switching operation has the atomicity of a database transaction: either all sub-modules are successfully switched to the target state, or if an error is encountered, it is completely rolled back to the state before the operation, thereby eliminating the risk of multi-module version inconsistency (partial state) caused by partial switching failure and ensuring the absolute stability of the development and build environment.

[0066] See attached document Figure 1 This embodiment details how, after completing the multi-module version switch, the system solidifies the transient version state at runtime into persistently stored static metadata and injects it into the software build artifacts to achieve version traceability throughout the entire lifecycle.

[0067] In this embodiment, the version information persistence step is designed as the final step in the version switching process, typically triggered automatically immediately after the execution control module completes the Git switching operations for all submodules. The core purpose of this step is to address the technical challenge in the Monorepo architecture where build artifacts are often difficult to trace back to the specific version combinations of their internal submodules.

[0068] Specifically, the persistence process begins with runtime context collection. The system aggregates key metadata for the current operation cycle in memory, and the collected content includes, but is not limited to, the following four dimensions: Macro version anchor: This is the target global version identifier (e.g., CX2.0.4.0) upon which this operation is based. This is the top-level index for version tracing, used to quickly locate the release batch to which the build artifact belongs.

[0069] Environment context identifier: This is the environment identifier (e.g., prod or fat) in which this operation takes place. This identifier is used to distinguish whether the build artifact is intended for production environment deployment or test environment verification, preventing environment mixing.

[0070] Micro-level composition details: This refers to the final branch configuration set generated by the recursive merging algorithm. The system performs a complete dump of this set, recording the precise state (specific commit hash or tag name) of each submodule (e.g., packages / auth-service) at the time of build. This data constitutes the genetic map of the build artifacts, serving as the fundamental basis for subsequent bug localization and environmental consistency audits.

[0071] Construct timing information: that is, the current timestamp when the operation is completed and the host information that performed the operation.

[0072] Subsequently, the system performs structured encapsulation and serialization operations. The collected information is mapped into a standard structured data object (VersionManifestObject). To facilitate cross-platform reading and subsequent parsing by automated tools, the system typically serializes this object using JSON format. The generated serialized data content is shown in the following structure: { "meta":{ "global_version":"CX2.0.4.0", "environment":"prod", "build_time":"2025-11-23T10:00:00Z", "builder":"ci-runner-01" }, "modules":{ "packages / core":{ "path":"packages / core", "ref":"v2.0.4", "commit":"a1b2c3d4..." }, "services / api":{ "path":"services / api", "ref":"v1.5.0", "commit":"e5f6g7h8..." } } } Finally, the system performs a metadata injection and write operation. The system locates the output directory of the software build artifact (e.g., dist / build / or output) and creates a metadata file with a preset name (e.g., version.json or build-info.meta) in that directory. The system calls the file write interface to write the serialized JSON data to this file.

[0073] This persistence mechanism has significant technical value in practical engineering applications: Runtime self-check: When the application deployed on the server starts, it can read the version.json file and output the current global version and submodule hash in the X-Version field in the management backend or API response header, so that the operation and maintenance personnel can remotely verify the correctness of the deployed version without logging into the underlying server.

[0074] Fault reconstruction: When a fault occurs online, developers can download the version.json file corresponding to the faulty environment and, based on the list of modules recorded in it, restore the code combination that is completely consistent with the online version in their local development environment with one click, thereby eliminating the difficulty of reproduction caused by version inconsistency.

[0075] Deployment blocking verification: Before executing a release, the automated deployment pipeline (CDPipeline) parses the environment field in this file. If it detects that the field is "test" but the target deployment environment is "production", the pipeline will use this metadata to automatically block the release, preventing the test package from being mistakenly deployed to production at the physical level.

Claims

1. A multi-version control and management method based on monorepo, characterized in that, Includes the following steps: Step S1: Receive a version switching instruction, wherein the version switching instruction contains a target global version identifier and an environment identifier; Step S2: Based on the environment identifier, load the corresponding environment version configuration file from the preset storage path. The environment version configuration file predefines the correspondence between multiple global version identifiers and configuration nodes. The configuration node contains an inheritance attribute for pointing to the parent global version identifier and a branch attribute for recording changes in the sub-modules under the current configuration node. Step S3: Locate the target configuration node corresponding to the target global version identifier in the environment version configuration file; Step S4: Perform a recursive branch information merging operation on the target configuration node to generate the final branch configuration set. The recursive branch information merging operation specifically includes: Determine whether the target configuration node has the inherited attribute. If the inherited attribute exists, recursively obtain the configuration result of the parent configuration node based on the inherited attribute as the basic configuration set, and merge the sub-module branch information in the branch attribute of the target configuration node into the basic configuration set. The submodule branch information in the target configuration node is used to overwrite the submodule information with the same name in the basic configuration set; Step S5: Traverse the final branch configuration set and call the version control tool to switch each submodule in the multi-module unified repository to the target state corresponding to each submodule in the final branch configuration set.

2. The multi-version control and management method based on monorepo according to claim 1, characterized in that, Before the step of loading the corresponding environment version configuration file, the method further includes format verification of the target global version identifier to verify whether the target global version identifier conforms to the preset hierarchical definition format. The global version identifier follows a hierarchical definition format, which includes a major version number, a minor version number, a patch version number, and a hotfix version number arranged in sequence.

3. The multi-version control and management method based on monorepo according to claim 1, characterized in that, In step S2, loading the corresponding environment version configuration file from the preset storage path according to the environment identifier specifically includes: Pre-build physically isolated production environment version configuration files, test environment version configuration files, and development environment version configuration files, and independently maintain the inheritance relationship of their respective configuration nodes in the production environment version configuration files, test environment version configuration files, and development environment version configuration files; Parse the environment identifier in the version switching command; If the environment identifier indicates a production environment, then load the production environment version configuration file; If the environment identifier indicates a test environment, then load the test environment version configuration file; If the environment identifier indicates a development environment, then the development environment version configuration file is loaded.

4. The multi-version control and management method based on monorepo according to claim 1, characterized in that, Following the step of locating the target configuration node corresponding to the target global version identifier in the environment version configuration file, the method further includes: Parse the branch attributes of the target configuration node and extract all submodule names and submodule version identifiers contained in the branch attributes.

5. The multi-version control and management method based on monorepo according to claim 4, characterized in that, In step S4, the submodule branch information in the target configuration node is used to overwrite the submodule information with the same name in the basic configuration set, specifically including: Iterate through each submodule configuration item in the branch attributes of the target configuration node; Determine whether there exists a record in the basic configuration set that has the same name as the current submodule; If a record with the same name as the current submodule already exists in the basic configuration set, then the original submodule version identifier in the basic configuration set is replaced with the current submodule version identifier; If there is no record with the same name as the current submodule in the basic configuration set, then the current submodule name and the current submodule version identifier are added as a new record to the basic configuration set.

6. The multi-version control and management method based on monorepo according to claim 1, characterized in that, The recursive branch information merging operation also includes determining the recursion termination condition: During the recursive branch information merging operation, if the currently processed configuration node does not have the inherited attribute, or the content of the inherited attribute is empty, then the currently processed configuration node is determined to be the root configuration node. The submodule branch information in the branch attribute of the root configuration node is directly extracted and returned as the basic configuration set, without searching upwards to the parent configuration node.

7. The multi-version control and management method based on monorepo according to claim 4, characterized in that, Before invoking the version control tool to switch each submodule in the unified multi-module repository to the target state corresponding to each submodule in the final branch configuration set, the multi-version control and management method further includes an integrity verification step: Iterate through the final branch configuration set; For each submodule in the final branch configuration set, check if the physical path of the submodule exists in the file system, and check if the submodule version identifier corresponding to the submodule is valid in the repository record of the version control system. If the physical path is found to be missing or the submodule version identifier is found to be invalid, an exception log is recorded and the switching operation for the submodule is skipped.

8. The multi-version control and management method based on monorepo according to claim 4, characterized in that, The step of calling the version control tool to switch each submodule in the unified multi-module repository to the target state corresponding to each submodule in the final branch configuration set specifically includes: Parse the type of the submodule version identifier corresponding to each submodule in the final branch configuration set, and execute the Git switching command that matches the type of the submodule version identifier; The type of the submodule version identifier includes at least one of branch name, tag name, commit hash and custom branch name.

9. A multi-version control and management method based on monorepo according to claim 1, characterized in that, The multi-version control and management method also includes an exception rollback step: During the submodule switching process, the switching status of each submodule is monitored in real time. If any submodule switching failure is detected, the current switching process will be interrupted. Based on the original state record before generating the final branch configuration set, the version control tool is invoked to restore all changed submodules to the version state before the version switching command was executed.

10. A multi-version control and management method based on monorepo according to claim 1, characterized in that, The multi-version control and management method also includes a version information persistence step: After completing the switching operation of all sub-modules, obtain the current target global version identifier, the environment identifier, the current timestamp, and the final branch configuration set; The acquired information is encapsulated into structured data objects, and the structured data objects are written into a preset metadata file of the software build product.

Images