A monorepo-based multi-version control and management method

Abstract

The application relates to the technical field of software configuration management, and discloses a multi-version control and management method based on a monorepo, which comprises the following steps: receiving a version switching instruction containing a target global version identifier and an environment identifier; loading an environment version configuration file physically isolated from a preset path according to the environment identifier; locating a target configuration node corresponding to the target global version identifier in the configuration file, and performing a recursive branch information merging operation based on inheritance attributes and branch attributes in the node to generate a final branch configuration set containing target states of all submodules; and traversing the final branch configuration set to call a version control tool to switch the workspace states of the submodules to corresponding target submodule version identifiers. Through the environment isolation and incremental inheritance model, the application solves the problems of version definition redundancy and environment confusion in a multi-module warehouse, and realizes accurate backtracking and atomic switching of submodule states.

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 reading and writing 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. This dirty state is not only difficult to repair manually, but also causes the local development environment or the 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:

[0008] 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 parsing 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, a 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.

[0009] 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 a 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, a 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.

[0010] 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.

[0011] 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.

[0012] 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.

[0013] 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, thus ending the upward search process and preventing infinite loops.

[0014] 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.

[0015] 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.

[0016] 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.

[0017] 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 final branch configuration set in effect, 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.

[0018] The application provides a monorepo-based multi-version control and management method. The method has the following beneficial effects:

[0019] 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, and the application builds 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 too many submodule combinations under the monorepo architecture.

[0020] 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, blocks the risk of unstable configuration misrelease from the test or development environment to the production environment from the physical storage level, and effectively improves the safety and standardization of the software release process.

[0021] 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 a transaction operation with atomicity, prevents the inconsistency problem of the code repository state caused by partial submodule switching failure, and ensures the stability of the development environment. BRIEF DESCRIPTION OF DRAWINGS

[0022] Figure 1 The method flowchart of the application. DETAILED DESCRIPTION

[0023] 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.

[0024] 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.

[0025] 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.

[0026] First, the instruction receiving module executes the step of receiving a version switching instruction. The user inputs the 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 includes a target global version identifier (i.e., a 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].

[0027] 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.

[0028] 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.

[0029] 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.

[0030] 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.

[0031] 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.

[0032] 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.

[0033] 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.

[0034] 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.

[0035] 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.

[0036] The extends attribute is used to build the inheritance link between versions. The value of this attribute is a string, which points to another existing CX version number (i.e., the parent version). Through this pointing relationship, the current version node implicitly inherits all the submodule states defined in the parent version. This chain structure allows the system to build a version inheritance tree, where the node without the extends attribute or with an empty extends attribute is defined as the root node (Root Version). The system can trace the extends attribute to backtrack from any child node to the root node, thus obtaining the complete configuration context.

[0037] The branches attribute is used to define the incremental changes of the current version relative to the parent version. The value of this attribute is a nested dictionary object, whose key is the relative path of the submodule in the Monorepo repository (e.g., packages / components or services / jssdk), and the value is the specific version identifier that the submodule should be in under this CX version. This design allows the configuration node to only record the submodules that have changed, and the submodules not listed in branches will automatically follow the configuration in the parent version, thus achieving the de-redundant storage of configuration information.

[0038] Specifically, the data structure in the environment version configuration file is as shown in the following example:

[0039] {

[0040] "CX1.18.3.4":{

[0041] "branches":{

[0042] "packages / components":"v1.0.0_base",

[0043] "services / jssdk":"v3.0.0_base"

[0044] }

[0045] },

[0046] "CX2.0.0.0":{

[0047] "extends":"CX1.18.3.4",

[0048] "branches":{

[0049] "packages / components":"v2.0.0_feature_A",

[0050] "services / jssdk":"v3.1.0_fix_B"

[0051] }

[0052] },

[0053] "CX2.0.0.1":{

[0054] "extends":"CX2.0.0.0",

[0055] "branches":{

[0056] "services / jssdk":"v3.1.1_hotfix"

[0057] }

[0058] }

[0059] }

[0060] In the above data structure, version CX1.18.3.4 does not define the extends property, so as the root node of the inheritance tree, its branches property defines the base state of all sub-modules. 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 sub-modules 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 is updated to v3.1.1_hotfix, while packages / components maintains the v2.0.0_feature_A state defined in CX2.0.0.0.

[0061] In addition, the sub-module version identifiers recorded in the branches property support multiple Git reference types to adapt to different development scenarios. Specifically, they include:

[0062] Tag: used to point to stable release states, such as v2.0.0_release;

[0063] Branch: used to point to ongoing development lines, such as feature / login_module;

[0064] Commit Hash: used to point to the snapshot of the changed code commit, such as a1b2c3d;

[0065] Custom branch name: an identifier for temporary or special use, such as v3.1.1_zz.

[0066] When the system parses, the above identifier is passed as a parameter to the Git command, so as to accurately control the checkout state of the submodule. Through the flexible support of the identifier, the application can simultaneously compatible with the release management of stable version and the dynamic debugging of development version.

[0067] With reference to the accompanying drawings Figure 1 The embodiment details 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.

[0068] In the embodiment, the recursive branch information merging operation is a dynamic triggering calculation process at runtime, rather than a static reading process. When the system locates the target configuration node corresponding to the target global version identifier, the algorithm logic is activated. The algorithm adopts a depth-first strategy to handle the inheritance relationship between configuration nodes. Specifically, the algorithm first reads the extends attribute of the current processing configuration node, and judges whether the attribute exists and has a non-empty value.

[0069] If it is detected that the current configuration node contains a valid extends attribute, the system pushes the current node into the logical call stack, extracts the parent global version identifier pointed by the extends attribute, and then shifts the execution focus to the parent configuration node corresponding to the parent identifier, and repeats the above checking process.

[0070] Preferably, in order to prevent the version inheritance relationship from appearing a dead loop due to configuration errors, the recursive branch information merging operation also contains a circular dependency detection mechanism.

[0071] Specifically, in the process of executing recursive lookup, the system maintains a visited node set (Visited Set) in memory. Whenever the system reads a new global version identifier and prepares to load the configuration node corresponding to it, it first checks whether the global version identifier already exists in the visited node set.

[0072] If not, the global version identifier is added to the visited node set, and the lookup and loading of the parent node are continued.

[0073] If it exists, it is determined that the current inheritance chain has a circular dependency (Circular Dependency), and the system immediately terminates the recursive process, throws a configuration exception error, and outputs the specific circular path information, so as to avoid the program from falling into an infinite loop and protect the stability of system resources.

[0074] This backtracking process will continue until a configuration node is located that either does not contain an extends attribute or whose extends attribute is empty. This node is determined by the system to be the root node of the version inheritance tree, and the contents of its branches attribute form the initial base configuration set for this inheritance link.

[0075] After determining the root node, the system enters the regression merge phase, in which the branch information is merged in order along the path from the root node to the target child node (i.e., in the out-of-stack order of the logical call stack). For each child node along the path, the system performs a dictionary merge of the submodule branch information defined in its branches attribute with the intermediate configuration set calculated in the previous step.

[0076] The dictionary merge follows a child-first override strategy, which includes the following three processing logics:

[0077] Update override: Traverse each submodule configuration item in the branches attribute of the current child node. If the name of this submodule already exists in the intermediate configuration set, it is determined that a configuration change has occurred. The system uses the submodule version identifier recorded in the current child node to forcibly replace the original version identifier of the submodule with the same name in the intermediate configuration set. This logic ensures that the modification of the child version to the parent version takes effect.

[0078] New addition: If the name of a submodule included in the branches attribute of the current child node does not exist in the intermediate configuration set, it is determined that this is a new module. The system adds the name and version identifier of this submodule as a new key-value pair to the intermediate configuration set. This logic supports the scenario of dynamically introducing new functional modules during iteration.

[0079] 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 keeps their original version identifiers unchanged and directly preserves them in the next round of calculation. This logic realizes the automatic inheritance of unchanged modules and is the key to reducing configuration redundancy.

[0080] To more intuitively illustrate the above logic, a specific three-level inheritance structure is used as an example: Suppose there is a root node version A, an intermediate node version B, and a target node version C. Version A is the root node, and its branches attribute defines submodule Module_X as v1.0 and submodule Module_Y as v1.0. The extends attribute of version B points to version A, and its branches attribute only defines submodule Module_X as v1.1. The extends attribute of version C points to version B, and its branches attribute only defines submodule Module_Z as v1.0.

[0081] When the user instructs to switch to version C, the system computes as follows: first, the system identifies the inheritance chain C -> B -> A. Next, the root node A is processed, generating the base configuration set: {Module_X:v1.0, Module_Y:v1.0}. Then, the configuration of node B is merged into the base set. Since node B defines Module_X:v1.1, the system updates Module_X in the base 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 is appended to the set. Node C does not mention Module_X and Module_Y, so they remain in the state after node B computation. Finally, the system outputs the final branch configuration set for switching execution: {Module_X:v1.1, Module_Y:v1.0, Module_Z:v1.0}.

[0082] Through the above recursive merging mechanism, the present application can accurately reconstruct the complete system snapshot at any time point without storing full copies, ensuring the accuracy of version control and the efficiency of storage.

[0083] Referring to the accompanying Figure 1 , this embodiment details the specific execution mechanism of the execution control module in landing the final branch configuration set generated by the calculation into a physical file state, focusing on the integrity verification, dynamic instruction adaptation, and transaction rollback guarantee mechanisms it contains.

[0084] In this embodiment, in order to ensure the atomicity and safety of version switching operations, the system does not directly perform indiscriminate batch operations on the sub-modules in the multi-module unified repository, but strictly follows the engineering processing flow of pre-verification, dynamic execution, and exception fusing.

[0085] First, the system performs the integrity verification step before switching. After the recursive merging calculation module generates the final branch configuration set, and before any write operation instruction is called, the system will perform a full traversal pre-check on the set. This check contains two dimensions of verification:

[0086] Physical path existence check: The system calls the file system interface (such as fs.stat or test-d) of the operating system according to the relative path of the submodule recorded in the final branch configuration set, detects whether the corresponding directory structure exists in the local workspace of the multi-module unified repository. If it is detected that the physical path of a certain submodule does not exist (for example, the module has been removed or has not been pulled in the current code baseline), the system will determine that the submodule is an invalid object.

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

[0088] Once an exception is found in any of the above verification steps, the system will immediately terminate the current switching process, not perform any substantive file changes, and record the specific error information (including the submodule name and invalid version identification) to the exception log, thereby avoiding placing the workspace in an intermediate state.

[0089] Secondly, after passing the integrity check, the system enters the dynamic instruction adaptation and execution phase. Since the types of submodule version identifications are diverse, the system has built-in identification type inference logic, which classifies the identification according to string characteristics and constructs a matching Git switching command:

[0090] If the identification conforms to the SHA-1 feature (such as a 40-bit hexadecimal string), the system identifies it as a commit hash (Commit Hash), and constructs a command such as git checkout [Hash] or git reset --hard [Hash] to ensure that the submodule accurately backtracks to the commit snapshot, which is usually used for precise construction in production environments.

[0091] If the identification contains the tags / prefix or conforms to the semantic version naming specification, the system identifies it as a tag (Tag), and constructs a command such as git checkout tags / [Tag] to make the submodule in a detached head (Detached HEAD) state, locked at the release node.

[0092] If the identifier does not meet the above characteristics, the system will identify it as a branch name (Branch) by default, and construct a command such as git checkout [Branch] and subsequent git pull commands to ensure that the submodule switches to the development branch and synchronizes the latest remote code, which is usually used for development or testing environments.

[0093] Finally, this embodiment introduces a transactional exception rollback mechanism to deal with runtime errors (such as network interruption, file lock occupation, etc.) during execution. The specific execution logic of this mechanism is as follows:

[0094] State snapshot record: Before executing the first switching command, the system first traverses all submodules, records their current HEAD pointer positions (i.e. the version state before switching), and generates an original state mapping table.

[0095] Real-time monitoring and fusing: 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 it detects that any submodule switching command returns a non-zero exit code (indicating execution failure), the system will trigger the fuse mechanism to immediately stop the switching tasks of all unexecuted submodules.

[0096] Reverse recovery: After triggering the fuse, the system reads the pre-generated original state mapping table and executes the switching command in reverse for all submodules that have been changed in this operation, forcing them to return to the original HEAD pointing and executing the workspace cleaning command (such as git clean) to remove possible temporary files.

[0097] Through the above mechanism, this embodiment ensures that the version switching operation has the atomicity of a database transaction: either all submodules successfully switch to the target state, or completely roll back to the state before the operation when an error is encountered, thereby eliminating the risk of partial state inconsistency caused by partial switching failure, and ensuring the absolute stability of the development and build environment.

[0098] Referring to the accompanying Figure 1 , this embodiment describes in detail how the system solidifies the transient version state at runtime into persistent static metadata and injects it into the software build product after completing the multi-module version switching, to achieve version tracing throughout the life cycle.

[0099] 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.

[0100] 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:

[0101] 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.

[0102] 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.

[0103] 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.

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

[0105] 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:

[0106] {

[0107] "meta":{

[0108] "global_version":"CX2.0.4.0",

[0109] "environment":"prod",

[0110] "build_time":"2025-11-23T10:00:00Z",

[0111] "builder":"ci-runner-01"

[0112] },

[0113] "modules":{

[0114] "packages / core":{

[0115] "path":"packages / core",

[0116] "ref":"v2.0.4",

[0117] "commit":"a1b2c3d4..."

[0118] },

[0119] "services / api":{

[0120] "path":"services / api",

[0121] "ref":"v1.5.0",

[0122] "commit":"e5f6g7h8..."

[0123] }

[0124] }

[0125] }

[0126] Finally, the system performs the metadata injection write operation. The system locates the output directory of the software build product (e.g., dist / build / or output) and creates a metadata file (e.g., version.json or build-info.meta) with a preset name under this directory. The system calls the file write interface to write the above-mentioned serialized JSON data into this file.

[0127] This persistence mechanism has significant technical value in practical engineering applications:

[0128] Runtime self-check: The application deployed on the server can read this version.json file when it starts and output the current global version and submodule hash in the X-Version field in the management background or API response header, so that the operation and maintenance personnel can remotely verify the correctness of the deployment version without logging into the server bottom layer.

[0129] Fault site restoration: When a fault occurs online, developers can download the version.json corresponding to the fault environment, according to the modules list recorded therein, to restore the code combination consistent with the online environment in the local development environment, so as to exclude the difficulty of reproduction caused by inconsistent versions.

[0130] Deployment blocking verification: Before executing the release, the automatic deployment pipeline (CDPipeline) parses the environment field in the file. If it is detected that the field is test but the target deployment environment is production, the pipeline will automatically block using this metadata to prevent the test package from being mistakenly released online from the physical layer.

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