Multi-environment publishing control method, electronic device, and storage medium

Abstract

This application provides a multi-environment release control method, electronic device, and storage medium, applicable to the field of software release control technology. The method includes: capturing snapshots of each managed object in the production environment to obtain source production snapshots and a list of source production snapshots; reconstructing the test environment based on the source production snapshots, and archiving and packaging each managed object in the test environment to generate candidate release versions and a candidate release list; performing difference analysis on the source production snapshot list, the candidate release list, and the current production snapshot list to determine the production promotion access control result; determining the target release version based on the production promotion access control result and the candidate release versions; and releasing the target release version in the target environment. This application establishes the association between the source production snapshot list, the candidate release list, and the current production snapshot list, and performs three-way verification on the managed objects, which can accurately identify the source of production drift and improve the accuracy of promotion judgment.

Description

Technical Field

[0001] This application relates to the field of software release control technology, and in particular to a multi-environment release control method, electronic device and storage medium. Background Technology

[0002] With the widespread adoption of agent platforms, plug-in runtime platforms, and dynamic runtime systems, the objects of software deployment are no longer limited to source code or container images, but have gradually expanded to a set of managed objects that continuously evolve during runtime. These managed objects typically include the runtime core directory, configuration files, skills, extensions, agent instances, and multiple workspace directories. Compared to traditional applications that are deployed solely through code build artifacts, the runtime state of such systems is more dynamic and environment-dependent, leading to more complex technical challenges in multi-environment deployment control.

[0003] Existing multi-environment deployment schemes typically use a code repository, artifact repository, or container image as the sole deployment source, with the default test environment, pre-release environment, and / or production environment all originating from the same static build result. In such schemes, environmental differences are usually treated as anomalies or configuration deviations, rather than as part of the deployment chain. However, in the agent runtime environment, skills, extensions, agent catalogs, or runtime configurations in the production environment may continue to change after the candidate release version is generated, or even directly create new objects in the production environment. If the traditional one-way deployment method is still used, it is easy to accidentally delete newly added objects in the production environment or incorrectly overwrite critical objects that have already been modified in the production environment during subsequent deployments.

[0004] Furthermore, existing technologies mostly employ a two-way comparison approach to assess release discrepancies, comparing only the differences between the candidate release version and the current production environment. While this approach can identify discrepancies, it cannot accurately pinpoint the source of production drift and is insufficient to support refined production deployment decisions. Summary of the Invention

[0005] In view of this, embodiments of this application provide a multi-environment release control method, electronic device, and storage medium to solve the problem in the prior art that the source of production drift cannot be accurately identified.

[0006] The first aspect of this application provides a multi-environment release control method, including: Snapshots are collected from each managed object in the production environment to obtain the source production snapshots and a list of source production snapshots; Based on the source production snapshot, the test environment is rebuilt, and each managed object in the test environment is archived and packaged to generate candidate release versions and a candidate release list. A difference analysis is performed on the source production snapshot list, candidate release list, and current production snapshot list to determine the production promotion access control results. The current production snapshot list is obtained by taking snapshots of each managed object in the current production environment. The production promotion access control results are used to indicate the production drift situation of each managed object. Based on the production and promotion results of the access control system and the candidate release versions, the target release version is determined; Publish the target release in the target environment; the target environment includes the pre-release environment and / or the production environment.

[0007] A second aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method of the first aspect.

[0008] A third aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the method of the first aspect.

[0009] Compared with the prior art, the embodiments of this application have at least the following technical effects: The multi-environment release control method of the first aspect of this application can collect snapshots of each managed object in the production environment to obtain source production snapshots and a list of source production snapshots. Then, based on the source production snapshots, the test environment is reconstructed, and each managed object in the test environment is archived and packaged to generate candidate release versions and a candidate release list. This allows the latest production snapshots to be referenced in the test environment reconstruction and candidate release version generation process, thereby establishing a release spectrum starting from the actual production running state. Furthermore, this application embodiment performs difference analysis on the source production snapshot list, the candidate release list, and the current production snapshot list to determine the production promotion access control result. Since the current production snapshot list is obtained by collecting snapshots of each managed object in the current production environment, and the production promotion access control result is used to indicate the production drift situation of each managed object, this application embodiment can establish the association relationship between the source production snapshot list, the candidate release list, and the current production snapshot list, and perform three-way verification on the managed objects to accurately identify the source of production drift and improve the accuracy of promotion judgment. Then, based on the production promotion access control results and candidate release versions, this application embodiment determines the target release version to manage production drift, and then releases the target release version in the target environment, which includes the pre-release environment and / or production environment, thereby realizing multi-environment security release control for dynamically running managed objects.

[0010] It is understood that the beneficial effects of the second and third aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

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

[0012] Figure 1 This is a flowchart of a multi-environment release control method provided in an embodiment of this application; Figure 2 This application provides a flowchart for performing difference analysis on a source production snapshot list, a candidate release list, and a current production snapshot list to generate a target release version; Figure 3 This is a flowchart illustrating how a target release version is published in a target environment, as provided in an embodiment of this application. Figure 4 This is a flowchart of a pre-deployment capacity detection, remote backup, application deployment, health check, and automatic failure recovery provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a multi-environment release control device provided in an embodiment of this application; Figure 6 This is a schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0013] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0014] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0015] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0016] In the description of this application, unless otherwise stated, the " / " used in this specification and appended claims indicates that the related objects are in an "or" relationship. For example, A / B can mean A or B. The "and / or" in this application merely describes the relationship between the related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. Furthermore, in the description of this application, unless otherwise stated, "multiple" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, a and b, a and c, b and c, or a, b, and c. Here, a, b, and c can be single or multiple.

[0017] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0018] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0019] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0020] Research has revealed that existing technologies for assessing release differences mostly employ a two-way comparison approach, comparing only the candidate release version with the current production environment. While this method can identify "differences," it cannot accurately pinpoint their source or determine whether a particular difference was actively introduced by the candidate release version, added to the production environment after the candidate release version was generated, or whether the production and testing environments underwent different modifications relative to a common baseline. Therefore, traditional two-way comparisons are insufficient for nuanced production deployment decisions, easily leading to the unintended blocking of changes that should be approved, or the incorrect implementation of changes that should be blocked.

[0021] Furthermore, in existing technologies, workspace objects are typically treated as ordinary directories and copied or overwritten entirely. Workspaces often contain both configuration and runtime data. Configuration data is generally suitable for rollout with each release, while runtime data often carries the real-time status, cache, memory, or context information of the production environment. If a complete replacement is used to directly roll out workspaces from the test environment or candidate release to the production environment, it easily overwrites the continuously accumulating data in the production environment. Conversely, if workspaces are completely prohibited from participating in releases for fear of data overwrite, workspace configurations cannot be properly validated and rolled out. Therefore, existing technologies lack an effective mechanism that can simultaneously address the needs of workspace configuration rollout and the data protection requirements of production workspaces.

[0022] When production environments have drifted, existing technologies typically offer only two solutions: simple blocking or manual catalog synchronization. On the one hand, while simple blocking can prevent erroneous deployments, it fails to provide operations personnel with a structured follow-up processing path. On the other hand, manual catalog synchronization heavily relies on human experience, lacks a unified mechanism for object location, difference selection, and result write-back, resulting in low processing efficiency and a high risk of introducing new errors. Especially in scenarios involving multiple skills, extensions, agents, and workspace objects, relying solely on manual comparison and manual overwriting is insufficient to meet the accuracy, traceability, and recoverability requirements of real-world production systems.

[0023] Meanwhile, existing multi-environment deployment processes often lack a complete deployment protection mechanism. For example, failure to perform capacity pre-checks on local temporary storage space and remote target machine space before formal deployment may lead to interruption during the release process due to insufficient disk space; failure to perform remote backups of the target environment before performing destructive replacements may result in unrecoverable failures; and the lack of a state recovery mechanism based on logs, metadata, and summary files after deployment failure or abnormal interruption of the release control process makes it impossible for operations and maintenance personnel to accurately determine whether the target environment has partially taken effect, whether manual rollback is required, and which versions are still within the rollback window.

[0024] Therefore, existing technologies have at least the following shortcomings: First, they lack a release hierarchy representation method oriented towards the actual production runtime state, and cannot incorporate the snapshot state, candidate release version state, and current production state in the production environment into a unified relationship chain; Second, they lack a three-way difference verification mechanism for managed runtime objects, and cannot accurately identify production additions, production blocking changes, and bilateral fork changes; Third, they lack a promotion mechanism for layered processing of the workspace configuration layer and data layer; Fourth, they lack a mechanism for back-up or three-way merging processing for production drift; Fifth, they lack an integrated multi-environment release control scheme that includes coverage capacity pre-check, remote backup, deployment failure recovery, state reclamation, and rollback window maintenance.

[0025] In view of this, this application proposes a new multi-environment release control method, which uses production snapshots as the baseline of the release spectrum. By establishing the association between the baseline production snapshot, candidate release versions and the current production snapshot, three-way verification is performed on the managed objects. Combined with work area layered retention, production drift back absorption or merging, pre-deployment protection and post-deployment state recovery, secure release control for dynamic runtime objects is achieved.

[0026] The technical solution of this application and how it solves the above-mentioned technical problems are described in detail below with specific embodiments. It should be noted that the following embodiments can be referenced, borrowed, or combined with each other, and the same terms, similar features, and similar implementation steps in different embodiments will not be described again.

[0027] See Figure 1 As shown, this application provides a flowchart of a multi-environment release control method. Figure 1 As shown, the multi-environment release control method of this application embodiment includes steps S101 to S105.

[0028] S101. Perform snapshot collection on each managed object in the production environment to obtain the source production snapshot and the source production snapshot list.

[0029] Optionally, the source production snapshot is used as the baseline production snapshot, and the source production snapshot is set with a source production snapshot identifier, which serves as the baseline snapshot identifier.

[0030] Optionally, the managed objects include at least one of the following: runtime core directory, runtime configuration, skill objects, extended objects, company-level skill objects, agent objects, and workspace objects; wherein, the workspace object includes a main workspace and multiple independent workspaces divided by agent.

[0031] The source production snapshot list not only records path information, but also object category, existence status, file size, directory statistics, and fingerprint information calculated based on content or structure. It also establishes a genealogical association between the latest production snapshot and subsequent candidate release versions through the source production snapshot identifier.

[0032] The multi-environment release control platform corresponding to the multi-environment release control method in this application embodiment is deployed on the host of the test environment and connected to the pre-release environment and production environment via the network. The platform internally maintains a production snapshot directory, candidate release versions, deployment record directory, job status directory, and third-party merged session directory. The platform determines the range of managed paths in the production environment based on a preset set of managed paths and a dynamically discovered set of workspace paths. Subsequently, the platform can also synchronize the directory tree and configuration files corresponding to the managed path range to the local snapshot directory via remote transmission, and form a new production snapshot named according to the timestamp. The platform further generates a production snapshot list for this production snapshot. The object categories in the production snapshot list include at least skills, extensions, company skills, agents, workspaces, and runtime core objects. For each managed object, the platform records its path, existence status, number of bytes, and fingerprint information calculated based on content or directory structure. The platform also sets the latest production snapshot as the current production snapshot identifier for unified reference in subsequent processes.

[0033] S102. Based on the source production snapshot, rebuild the test environment and archive and package each managed object in the test environment to generate candidate release versions and candidate release lists.

[0034] Optionally, rebuilding the test environment can record the source production snapshot identifier corresponding to this test rebuild. When generating a release version package (candidate release version), the version package checksum, managed path list, and runtime list can be generated simultaneously.

[0035] The release package includes not only archived payloads for environment deployment, but also checksum files, a managed path list, a runtime manifest, version descriptions, source production snapshot identifiers, and a copy of the source production snapshot list. The runtime manifest records the quantity, byte count, and fingerprint information of each type of managed object to support subsequent difference analysis, capacity estimation, and rollback window determination. This makes the candidate release version not just a static archive, but a structured version entity that can be used for lineage verification and production deployment decisions.

[0036] Furthermore, the platform in this embodiment archives managed objects in the test environment, generates payload archive files, and further calculates the corresponding checksum files. The platform also generates a managed path list and a runtime list. The runtime list records at least the number of skills, extensions, company skills, agents, and workspaces, and can further record byte statistics and fingerprint statistics for each type of object. In this embodiment, the platform uniformly writes the version identifier, creation time, source production snapshot identifier, version description, payload information, managed path list, runtime list, and a copy of the source production snapshot list into the version list, thereby forming a structured release version package.

[0037] This application first collects data from managed objects in the production environment, generating timestamped source production snapshots, and further generates a source production snapshot list. The source production snapshot list describes the structured state of the collected managed objects, including at least object category, path, existence status, byte count, and fingerprint information. By setting source production snapshot identifiers, the latest production snapshot can be referenced in subsequent test environment reconstruction and candidate release version generation processes, thereby establishing a release lineage starting from the actual production running state.

[0038] Optionally, embodiments of this application may take snapshots of each managed object in the production environment at predetermined intervals or as needed, and take the current production snapshot corresponding to the current production environment.

[0039] In some embodiments, the test environment is rebuilt based on the source production snapshot, including: Use the current test environment as the initial test environment, stop the user gateway service in the initial test environment, and clean up the existing managed objects in the initial test environment; Based on the source production snapshot, the managed objects in the initial test environment are restored to obtain the intermediate test environment; The intermediate test environment is overlaid with the preset test environment overlay configuration to obtain the test environment.

[0040] This application embodiment reconstructs the test environment based on the source production snapshot. By restoring managed objects and overlaying test environment coverage configurations, the test environment inherits the managed object baseline of the production environment while possessing independent test access points and runtime parameters. After the test environment reconstruction is completed, the corresponding source production snapshot identifier is recorded so that candidate release versions generated from this test environment can be clearly associated with their source production snapshot.

[0041] Furthermore, in this embodiment, the platform first stops the user gateway service in the test environment and cleans up the existing managed objects in the test environment. Then, the platform restores the managed objects in the test environment based on the source production snapshot, ensuring consistency between the test environment and the source production snapshot. After restoration, the platform writes an overlay configuration to the test environment, including a test environment-specific binding address, access address, control path, authentication parameters, and proxy configuration, enabling the test environment to inherit the production baseline while having an independent entry point. Afterward, the platform performs a health check on the test environment. When it detects that the basic service, gateway service, and access link have all reached a preset state, it writes the source production snapshot into the test environment reconstruction state.

[0042] S103. Perform a difference analysis on the source production snapshot list, candidate release list, and current production snapshot list to determine the production promotion access control results. The current production snapshot list is obtained by taking snapshots of each managed object in the current production environment. The production promotion access control results are used to indicate the production drift situation of each managed object.

[0043] Before production rollout, this application's embodiments read the source production snapshot list corresponding to the source production snapshot identifier, the version list corresponding to the release version package, and the current production snapshot list to establish a phylogenetic relationship between the baseline production snapshot, candidate release versions, and the current production snapshot, and perform a three-way difference analysis accordingly. Through this three-way difference analysis, it is possible to distinguish between candidate-side changes, production-side additions, production-side blocking changes, bilateral fork changes, workspace configuration drift, and workspace data drift, thereby outputting the production rollout readiness level, conflicting workbench items, and recommended actions. Compared to the traditional method of only comparing candidate release versions and the current production status bidirectionally, this technical solution can clearly identify the source of differences and improve the accuracy of rollout judgment.

[0044] S104. Based on the production and promotion of access control results and candidate release versions, determine the target release version.

[0045] This application embodiment can update the candidate release version through three-dimensional difference analysis to obtain a new candidate release version as the target release version.

[0046] S105. Publish the target release version in the target environment; the target environment includes the pre-release environment and / or the production environment.

[0047] This application embodiment can be used for a multi-environment release system consisting of a test environment, a pre-release environment, and a production environment. The production environment is the actual running state as the baseline source, the test environment is the candidate release version generation environment, the pre-release environment is the complete verification environment, and the production environment is the controlled promotion target environment.

[0048] Based on the above steps S101 to S105, the multi-environment release control method of this application embodiment can collect snapshots of each managed object in the production environment to obtain source production snapshots and a list of source production snapshots; then, based on the source production snapshots, the test environment is rebuilt, and each managed object in the test environment is archived and packaged to generate candidate release versions and a list of candidate releases. This allows the latest production snapshots to be referenced in the test environment reconstruction and candidate release version generation process, thereby establishing a release spectrum starting from the actual production running state.

[0049] Furthermore, this embodiment of the application performs a difference analysis on the source production snapshot list, the candidate release list, and the current production snapshot list to determine the production promotion access control result. Since the current production snapshot list is obtained by capturing snapshots of each managed object in the current production environment, and the production promotion access control result is used to indicate the production drift situation of each managed object, this embodiment of the application can establish the association between the source production snapshot list, the candidate release list, and the current production snapshot list, and perform three-way verification on the managed objects. This can accurately identify the source of production drift and improve the accuracy of promotion judgment.

[0050] Then, based on the production promotion access control results and candidate release versions, this application embodiment determines the target release version to manage production drift, and then releases the target release version in the target environment, which includes the pre-release environment and / or production environment, thereby realizing multi-environment security release control for dynamically running managed objects.

[0051] This application relates to the fields of software release control, runtime object governance, and multi-environment continuous delivery technology. It is applicable to managed runtime environments that include runtime core directories, runtime configurations, skill objects, extended objects, company skill objects, agent objects, and workspace objects. It is a technical solution that achieves secure release control through production snapshot collection, version lineage establishment, three-way difference verification, workspace layered promotion, conflict back-up or merging, deployment protection, and state recycling.

[0052] In some embodiments, a difference analysis is performed on the source production snapshot list, the candidate release list, and the current production snapshot list to determine the production promotion access control results, including: Based on the changes in each managed object in the source production snapshot list, candidate release list, and current production snapshot list, determine the difference classification result for each managed object; Based on the results of each differential classification, the results of the production and promotion access control system are determined.

[0053] Optionally, the production and promotion of access control results may include multiple access control levels.

[0054] The embodiments of this application can perform three-way genealogy verification based on the source production snapshot list, the candidate release list, and the current production snapshot list to identify production-side additions, production-side blocking changes, bilateral fork changes, and work area differences.

[0055] In some embodiments, the difference classification result for each managed object is determined based on the change relationships between managed objects in the source production snapshot list, the candidate release list, and the current production snapshot list, including at least one of the following: If any managed object does not exist in the source production snapshot list, exists in the current production snapshot list, and does not exist in the candidate release list, then the difference classification result of the managed object is determined as a newly added object on the production side; If any managed object exists in the source production snapshot list, is modified or deleted in the current production snapshot list, and is consistent with the candidate release list and the source production snapshot list, then the difference classification result of the managed object is determined as a production-side blocked change object. If any managed object exists in the source production snapshot list and has different modifications in the current production snapshot list and the candidate release list, then the difference classification result of the managed object is determined as a two-sided fork change object.

[0056] Optionally, the three-way genealogy check will classify the differences into at least the following types: security additions or modifications to the candidate release version itself, new objects in the production environment relative to the baseline, blocking changes in the production environment relative to the baseline, forking changes in the production and test environments relative to the baseline, workspace configuration drift, and workspace data drift; and output three access control levels: clean (corresponding to candidate-side changes), merge_back_required (absorb or merge), or blocked (blocked) based on the difference classification results.

[0057] In some embodiments, the target release version is determined based on the production deployment access control results and candidate release versions, including: Based on the production promotion access control results, determine the production drift handling methods for each managed object that has experienced production drift; the production drift handling methods include back-suction handling and merging handling; If the production drift handling method for the managed object is the back-up processing, then for the managed object, the current production snapshot corresponding to the current production snapshot list is used to back-up update the candidate release version and generate the target release version. If the production drift handling method for the managed object is merge processing, then for the managed object, a three-way merge is performed based on the source production snapshot, the candidate release version, and the current production snapshot corresponding to the current production snapshot list to determine the conflict handling result, and the conflict handling result is written back to the test environment to generate the target release version.

[0058] In this application embodiment, for runtime objects that are newly added only in the production environment, the system defaults to outputting a backflow result and only allows destructive advancement when explicitly permitted; for cases where the baseline object has been modified or deleted in the production environment and the candidate release version does not carry the modification, the system outputs a blocking result, prohibiting direct promotion to the production environment.

[0059] In some embodiments, a three-way merging is performed based on the source production snapshot, the candidate release version, and the current production snapshot corresponding to the current production snapshot list to determine the conflict resolution result, including: Based on the source production snapshot, candidate release versions, and the current production snapshot corresponding to the current production snapshot list, construct the source production snapshot variant tree, the candidate release variant tree, and the current production snapshot variant tree; The source production snapshot variant tree, candidate release variant tree, and current production snapshot variant tree are used to initialize the three-party merged repository, generating the base variant tree, our variant tree, and the other party's variant tree; Merge the base variant tree, our variant tree, and the opponent's variant tree to generate a merge working branch; Based on the merged work branches, determine the conflict resolution outcome.

[0060] This application embodiment can construct a Git-style merge session for file-level resolution when mergeable conflicts are identified, and generate a resolved release (i.e., the target release version) after the conflict is resolved.

[0061] Furthermore, a Git-style merge session includes: constructing a base variant tree (i.e., the basic variant tree), ours variant tree (i.e., our variant tree), and theirs variant tree (i.e., the counterpart variant tree) based on the source production snapshot, the release package, and the current production snapshot, respectively; initializing three lineage branches of the Git repository with the three variant trees; performing an automatic merge to form a resolved working branch (i.e., the merge working branch); outputting the resolution status of files in the resolved branch, such as unresolved, retaining the release package, reverting to the baseline, automatic merge, or manual editing; and allowing the resolved working branch to be written back to the test environment and generating the target release version after all conflicting files have been resolved.

[0062] See Figure 2 As shown, this application embodiment provides a flowchart for performing difference analysis on the source production snapshot list, candidate release list, and current production snapshot list to generate a target release version. Figure 2 As shown, this application embodiment performs a three-way difference analysis on the source production snapshot list, the candidate release list, and the current production snapshot list. When the three-way difference analysis detects production drift, it generates the corresponding production promotion access control result.

[0063] Furthermore, for skills, extensions, company skills, agents, and runtime configuration objects, if an object does not exist in the source production snapshot list, exists in the current production snapshot list, but does not exist in the candidate release version, the platform identifies it as a newly added object on the production side; if an object exists in the source production snapshot list, has been modified or deleted in the current production snapshot, and the candidate release version still maintains the baseline state, the platform identifies it as a production-side blocked change object; if an object exists in the source production snapshot list, and the current production snapshot list and the candidate release version have made different modifications to it, the platform identifies it as a two-sided fork change object. Based on the differential classification results of all managed objects, the platform outputs one of the following production rollout readiness levels: clean, merge_back_required, or blocked, and writes managed objects that require further processing into conflict workbench items.

[0064] Then, for managed objects that have experienced production drift, a backflow process based on the current production snapshot can be performed, or a three-way merge session can be created.

[0065] In this embodiment, when the platform executes the backtracking process, it determines the category, object identifier, and corresponding production snapshot path of the object to be backtracked based on the conflicting workbench item. For workspace objects, only the workspace configuration layer content is synchronized; for non-workspace objects, the corresponding object in the current production snapshot overwrites the corresponding object in the test environment. After the backtracking is completed, the platform prompts for the regeneration of the release version package, thereby enabling the new candidate release version to continue into the subsequent release chain based on the corrected test environment.

[0066] In this embodiment, the three-party merge session constructs three variant trees (base, ours, and theirs) and a resolved working branch to provide conflict objects with file-level difference location, status identification, manual editing, and write-back application capabilities, thereby elevating production drift governance from simple blocking to structured processing. The platform constructs a baseline version variant tree, a release version variant tree, and a production version variant tree for each conflict object to initialize the three-party merge repository and form three lineage references: base, ours, and theirs. Then, the platform executes the three-party merge to generate a resolved working branch (i.e., the merge working branch) and outputs resolution statuses for files in the resolved working branch, including unresolved, retained release, retained production, reverted to baseline, automatic merge, and manual editing. After all conflict files are resolved, the platform writes back the conflict resolution results corresponding to the resolved working branch to the test environment and generates a new candidate release version, allowing the conflict resolution results to re-enter the standard release process.

[0067] In some embodiments, before publishing the target release in the target environment, the method further includes: Workspace objects are hierarchically identified to determine the workspace configuration layer and the workspace data layer; managed objects include workspace objects. Deploying the target release in the target environment includes: If the target environment is a pre-release environment, the workspace configuration layer and workspace data layer in the target release version will be used for release; If the target environment is a production environment, the release will be performed using the workspace configuration layer in the target release version and the workspace data layer in the current production snapshot corresponding to the current production snapshot list.

[0068] Specifically, when the target to be promoted includes workspace objects, the workspace is split into a configuration layer and a data layer. The full release version package is applied in the pre-release environment, while only the workspace configuration layer is applied in the production environment, and the current production environment's workspace data layer is retained.

[0069] In this embodiment, the workspace files are classified and fingerprinted using a preset set of workspace control files, a set of configuration prefixes, and a set of data prefixes to obtain the workspace configuration layer fingerprint and the workspace data layer fingerprint. The pre-release environment performs full verification of the workspace configuration layer and data layer. When the production environment applies the release version package, it only overwrites the configuration layer files and retains the data layer files in the current production environment.

[0070] See Figure 3 As shown, this application embodiment provides a flowchart for publishing a target release version in a target environment. For example... Figure 3 As shown, layered identification processing of configuration and data layers is performed on workspace objects. Specifically, control files, configuration directories, and skill directories within the workspace object are categorized into the configuration layer, while runtime cache, memory data, lock files, status files, and related runtime data directories are categorized into the data layer.

[0071] For pre-release environments, a complete candidate release version verification method is adopted, ensuring that both the workspace configuration layer and the workspace data layer are verified. For production environments, a method of promoting the workspace configuration layer while retaining the current production data layer is used, thereby ensuring that the configuration is deployable while preventing production runtime data from being overwritten. This technical solution solves the problem of balancing verification and protection for workspace objects.

[0072] Specifically, embodiments of this application can predefine a set of workspace control files, a set of configuration prefixes, and a set of data prefixes. Control files, configuration directories, and skill directories in the workspace are identified as configuration layer content; memory directories, runtime state directories, cache directories, lock files, and runtime-related data files in the workspace are identified as data layer content. Then, embodiments of this application calculate independent fingerprints for the configuration layer content and the data layer content respectively, thereby enabling separate determination of workspace configuration changes and workspace data changes.

[0073] In this embodiment, when the target environment is a pre-release environment, the platform fully applies the workspace configuration layer and workspace data layer during deployment to ensure that the candidate release version is verified in its complete state. When the target environment is a production environment, after unpacking the candidate release version, the platform extracts the workspace data layer from the current production snapshot and backfills it into the production environment staging tree. This ensures that the staging tree ultimately used for production environment deployment only carries the workspace configuration layer from the candidate release version, while retaining the current production workspace data layer. Therefore, the workspace configuration can be rolled out with each version, and the runtime data in the production environment will not be overwritten by the deployment of the candidate release version.

[0074] In some embodiments, prior to publishing the target release in the target environment, at least one of the following is also included: Perform local and remote capacity pre-checks on the target release version; Perform remote backup of the target release version; And / or, after the target release is published in the target environment, it also includes: Perform a health check on the target release version; If the health check fails, retrieve the backup target release version from the remote repository and perform a health check on the backup target release version.

[0075] The embodiments of this application can perform capacity pre-checks and remote backups before deployment in the target environment, perform health checks after deployment, automatically recover in case of deployment failure, and accumulate deployment logs, deployment metadata, and deployment summaries.

[0076] Specifically, the pre-deployment capacity check includes at least local temporary storage space estimation and remote target machine space estimation. The remote target machine space estimation takes into account the release version package archive size, managed object unpacking size, remote backup size, and preset safety buffer, thereby preventing release operations with insufficient disk space before performing destructive replacement.

[0077] See Figure 4As shown, this application embodiment provides a flowchart of pre-deployment capacity detection, remote backup, application deployment, health check, and automatic recovery from failure. Before deploying the release version package to a pre-release or production environment, this application embodiment performs local capacity pre-detection, remote capacity pre-detection, remote backup, and staging tree preparation, and performs a health check after deployment. When deployment fails, automatic recovery is performed based on the remote backup created before deployment, and the health check is re-executed, thereby improving the security and recoverability of the multi-environment release control process.

[0078] Furthermore, the platform first performs a capacity pre-check before deployment. Based on the payload size in bytes, the unpacked size in bytes, and a preset security buffer value, the platform calculates the required local temporary storage space to determine if the local temporary directory meets the deployment preparation requirements. Simultaneously, based on the payload size in bytes, the estimated remote backup size in bytes, and the preset security buffer value, the platform calculates the required space on the remote target machine to determine if the target environment has sufficient temporary and backup space. Once the capacity pre-check passes, the platform creates a remote temporary storage directory and a remote backup directory in the target environment, and transfers the temporary storage tree to the remote temporary storage directory. Then, before performing a destructive replacement, a remote backup is performed on the currently managed objects in the target environment.

[0079] In this embodiment, a remote temporary storage directory and a remote backup directory can be created before deployment in the remote target environment. Then, the user gateway service, web service and cache service are stopped, the existing managed state is cleaned up and the temporary storage tree is applied. If any step in the deployment process fails, automatic recovery is performed using the pre-deployment backup. After recovery is completed, a health check is performed again.

[0080] In this embodiment, job logs, deployment logs, deployment metadata, deployment summaries, and rollback retention states are written to the state storage. When the release control platform process is interrupted or restarted, state reclamation or deployment summary reconstruction is performed based on the logs and metadata already written to disk, thereby maintaining the integrity of audit evidence for the release process.

[0081] Furthermore, when the target environment is a pre-release environment, the platform directly applies the complete staging tree corresponding to the release version package and performs a health check after deployment to verify the complete running status of the candidate release version. When the target environment is a production environment, the platform first verifies whether there is a successful pre-release record for the release to be deployed that is completely consistent with its version identifier; only after the verification passes will the platform stop the basic services and user services in the target environment, clean up existing managed objects, apply the staging tree, and restore directory permissions. The platform then restarts the basic services and user services and performs a post-deployment health check. If the deployment fails and a remote backup has been created, the platform automatically restores the original state of the target environment from the remote backup and performs a health check again to confirm the recovery result.

[0082] In this embodiment, the platform generates corresponding job metadata and process logs for each production snapshot, test environment reconstruction, candidate version generation, rollback, merging, and deployment action; it generates deployment metadata, deployment logs, and deployment summaries for each deployment; and it maintains a rollbackable release set and a remote backup set according to preset retention window rules. After a process interruption or restart, the platform can recover the job status, restore the deployment results, or rebuild the deployment summary based on the job logs, deployment logs, and deployment metadata already written to disk, thereby ensuring that status information and audit information in the release control chain are not lost due to process anomalies.

[0083] Furthermore, in one embodiment, the platform only identifies a candidate release as a rollback target if it simultaneously meets the following conditions: a successful deployment record exists, the payload archive file is still retained, and the candidate release is within the window of the most recently pre-defined number of successfully deployed versions. This mechanism avoids performing erroneous rollbacks on outdated or incomplete versions, improving the reliability of rollback operations.

[0084] The embodiments of this application may also include job persistence and evidence recovery steps: in the event of a restart or interruption of the release console process, the job status is automatically inferred based on the job logs, deployment logs and metadata that have been written to disk, successful results are recovered or conservative failure results are generated, and the deployment summary is rebuilt as needed to maintain the continuity of the audit evidence chain.

[0085] The purpose of this application is to address the problems in existing technologies, such as multi-environment release control mainly relying on code repositories or artifact repositories, inability to accurately identify the source of drift during production environment runtime, difficulty in protecting workspace runtime data, lack of structured conflict handling mechanisms, and insufficient recovery and state reclamation capabilities after deployment failure. This application proposes a multi-environment release control method based on production snapshot genealogy verification and workspace layered retention, so as to achieve secure promotion, traceable governance, and recoverable control for managed runtime objects.

[0086] Compared with the prior art, the embodiments of this application have at least the following beneficial effects: Firstly, by establishing a genealogical relationship between baseline production snapshots, candidate releases, and the current production snapshot, this application achieves traceable release control over the actual running state of the production environment, avoiding the problem of relying solely on source code or build artifacts while ignoring the actual runtime state.

[0087] Secondly, the embodiments of this application can clearly distinguish between candidate-side changes, production-side additions, production-side blocking changes, and bilateral forking changes through three-way difference analysis, thereby improving the accuracy of production promotion access control judgment and reducing false releases and false blockings.

[0088] Third, the embodiments of this application perform configuration layer and data layer processing on the workspace object, so that the pre-release environment can be fully verified, and the production environment can promote only the configuration layer and retain the data layer, thereby taking into account both the workspace configuration promotion needs and the production workspace data protection needs.

[0089] Fourth, the embodiments of this application provide two types of structured processing methods: production drift reabsorption and three-party merging sessions, so that production drift is no longer limited to just blocking, thus improving the operability and recoverability of conflict governance.

[0090] Fifth, the embodiments of this application incorporate capacity pre-inspection, remote backup, automatic recovery from deployment failure, rollback window maintenance, and state recovery after process interruption into a unified release control link, which significantly improves the stability, reliability, and audit traceability of the multi-environment release control process.

[0091] In summary, this application's embodiments construct a complete multi-environment release control chain for managed runtime objects through production snapshot acquisition, test environment reconstruction, candidate release version generation, lineage verification, workspace layering, drift absorbing or third-party merging, deployment protection, failure recovery, and state persistence and recycling. Compared to traditional release methods centered solely on code or artifacts, this application's embodiments can more accurately express the relationship between the actual production runtime state and candidate release versions, handle workspace data more securely, manage production drift more efficiently, and more reliably support fault recovery and audit tracing during multi-environment releases. Moreover, this application's embodiments can incorporate runtime-generated agents, skills, extensions, workspace configurations, and workspace data into the controlled release chain, effectively avoiding problems such as accidental deletion of newly added production objects, complete overwriting of workspace data, lack of evidence after release failures, and untraceable multi-environment states.

[0092] See Figure 5 As shown in the diagram, this application provides a schematic diagram of the structure of a multi-environment release control device 50. Figure 5 As shown, the multi-environment release control device 50 includes: a production snapshot module 501, a version generation module 502, a difference analysis module 503, a conflict handling module 504, and a release control module 505.

[0093] The production snapshot module 501 is used to collect snapshots of each managed object in the production environment and obtain the source production snapshot and the source production snapshot list.

[0094] Version generation module 502 is used to rebuild the test environment based on the source production snapshot, and archive and package each managed object in the test environment to generate candidate release versions and candidate release lists.

[0095] The difference analysis module 503 is used to perform difference analysis on the source production snapshot list, candidate release list and current production snapshot list to determine the production promotion access control results; the current production snapshot list is obtained by taking snapshots of each managed object in the current production environment, and the production promotion access control results are used to indicate the production drift of each managed object.

[0096] The conflict resolution module 504 is used to determine the target release version based on the production promotion access control results and candidate release versions.

[0097] The release control module 505 is used to release the target release version in the target environment; the target environment includes a pre-release environment and / or a production environment.

[0098] Optionally, the difference analysis module 503 is used to determine the difference classification result of each managed object based on the change relationship of each managed object in the source production snapshot list, the candidate release list and the current production snapshot list; and to determine the production promotion access control result based on each difference classification result.

[0099] Optionally, the difference analysis module 503 is used to achieve at least one of the following: if any managed object does not exist in the source production snapshot list, exists in the current production snapshot list, and does not exist in the candidate release list, then the difference classification result of the managed object is determined to be a newly added object on the production side; If any managed object exists in the source production snapshot list, is modified or deleted in the current production snapshot list, and is consistent with the candidate release list and the source production snapshot list, then the difference classification result of the managed object is determined as a production-side blocked change object. If any managed object exists in the source production snapshot list and has different modifications in the current production snapshot list and the candidate release list, then the difference classification result of the managed object is determined as a two-sided fork change object.

[0100] Optionally, the conflict resolution module 504 is used to determine the production drift handling method for each managed object that has experienced production drift based on the production promotion access control results. The production drift handling method includes pullback processing and merging processing. If the production drift handling method for the managed object is pullback processing, then for the managed object, the candidate release version is updated by pullback using the current production snapshot corresponding to the current production snapshot list to generate the target release version. If the production drift handling method for the managed object is merging processing, then for the managed object, a three-way merging is performed based on the source production snapshot, the candidate release version, and the current production snapshot corresponding to the current production snapshot list to determine the conflict resolution result. The conflict resolution result is then written back to the test environment to generate the target release version.

[0101] Optionally, the conflict resolution module 504 is used to construct a source production snapshot variant tree, a candidate release variant tree, and a current production snapshot variant tree based on the source production snapshot, the candidate release version, and the current production snapshot corresponding to the current production snapshot list; initialize the three-party merge repository using the source production snapshot variant tree, the candidate release variant tree, and the current production snapshot variant tree to generate a base variant tree, our variant tree, and the other party's variant tree; merge the base variant tree, our variant tree, and the other party's variant tree to generate a merge working branch; and determine the conflict resolution result based on the merge working branch.

[0102] Optionally, the multi-environment publishing control device 50 includes a work area layering module, which is used to perform layered identification of work area objects and determine the work area configuration layer and the work area data layer.

[0103] Correspondingly, the release control module 505 is used to release the target environment using the workspace configuration layer and workspace data layer in the target release version if the target environment is a pre-release environment; and to release the target environment using the workspace configuration layer in the target release version and the workspace data layer in the current production snapshot corresponding to the current production snapshot list if the target environment is a production environment.

[0104] Optionally, the version generation module 502 is used to take the current test environment as the initial test environment, stop the user gateway service in the initial test environment, clean up the existing managed objects in the initial test environment; restore the managed objects in the initial test environment based on the source production snapshot to obtain the intermediate test environment; and overlay the intermediate test environment with the preset test environment coverage configuration to obtain the test environment.

[0105] Optionally, the release control module 505 is also configured to perform at least one of the following: perform local and remote capacity pre-checks on the target release version; perform remote backups of the target release version; Optionally, the release control module 505 performs a health check on the target release version; if the health check fails, it retrieves a backup of the target release version from the remote end and performs a health check on the backup target release version.

[0106] In applications, the modules in the multi-environment release control device 50 can be software program modules, or they can be implemented through different logic circuits integrated in the processor, or they can be implemented through multiple distributed processors.

[0107] The multi-environment publishing control device 50 of this application embodiment can execute the method provided in the embodiment of this application. The implementation principle is similar. The actions performed by each module in the multi-environment publishing control device 50 of each embodiment of this application correspond to the steps in the method of each embodiment of this application. For detailed functional descriptions of each module of the multi-environment publishing control device 50, please refer to the descriptions in the corresponding methods shown above, which will not be repeated here.

[0108] See Figure 6 As shown, this application provides a schematic diagram of the structure of an electronic device 60. Figure 6 As shown, the electronic device 60 of this application embodiment includes: a memory 62, a processor 61, and a computer program 63 stored in the memory 62 and executable on the processor 61. When the processor 61 executes the computer program, it implements the steps of the methods of the various embodiments of this application.

[0109] Electronic device 60 can be a computing device such as a desktop computer, laptop, handheld computer, or cloud server. Electronic device 60 may include, but is not limited to, a processor 61 and a memory 62. Those skilled in the art will understand that electronic device 60 may also include more or fewer components, or combinations of certain components, or different components, such as input / output devices, network access devices, etc.

[0110] Processor 61 can be a Central Processing Unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0111] In some embodiments, memory 62 may be an internal storage unit, such as a hard disk or RAM. Memory 62 may be a removable / non-removable, volatile / non-volatile computer system storage medium; for example, memory 62 may be a non-volatile memory used for reading and writing non-volatile magnetic media. In other embodiments, memory 62 may be an external storage device, such as a plug-in hard disk, smart media card (SMC), secure digital card (SD) card, flash card, etc., provided on electronic device 60. Memory 62 is used to store operating systems, applications, bootloaders, data, and other programs, such as program code for computer programs. Memory 62 may also be used to temporarily store data that has been output or will be output.

[0112] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0113] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0114] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in the above-described method embodiments.

[0115] If the integrated units described above are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a device / terminal equipment, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks.

[0116] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk drive (HDD), or solid-state drive (SSD), etc. The storage medium can also include combinations of the above types of memory.

[0117] This application provides a computer program product that, when run on a processor, enables the processor to execute the steps described in the various method embodiments above.

[0118] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0119] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0120] In the embodiments provided in this application, it should be understood that the disclosed apparatus / network devices and methods can be implemented in other ways. For example, the apparatus / network device embodiments described above are merely illustrative. For instance, the division of modules or units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0121] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0122] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A multi-environment release control method, characterized in that, include: Snapshots are collected from each managed object in the production environment to obtain the source production snapshots and a list of source production snapshots; Based on the source production snapshot, the test environment is rebuilt, and each managed object in the test environment is archived and packaged to generate candidate release versions and a candidate release list. A difference analysis is performed on the source production snapshot list, the candidate release list, and the current production snapshot list to determine the production promotion access control result; the current production snapshot list is obtained by taking snapshots of each managed object in the current production environment, and the production promotion access control result is used to indicate the production drift situation of each of the managed objects; Based on the production and promotion access control results and the candidate release versions, the target release version is determined; The target release version is released in the target environment, which includes a pre-release environment and / or a production environment.

2. The multi-environment release control method according to claim 1, characterized in that, The step of performing a difference analysis on the source production snapshot list, the candidate release list, and the current production snapshot list to determine the production promotion access control results includes: Based on the changes in each managed object in the source production snapshot list, the candidate release list, and the current production snapshot list, determine the difference classification result for each managed object; Based on the differences in the classification results, the production and promotion access control results are determined.

3. The multi-environment release control method according to claim 2, characterized in that, The step of determining the difference classification result for each managed object based on the change relationships of managed objects in the source production snapshot list, the candidate release list, and the current production snapshot list includes at least one of the following: If any of the managed objects does not exist in the source production snapshot list, exists in the current production snapshot list, and does not exist in the candidate release list, then the difference classification result of the managed object is determined to be a newly added object on the production side; If any of the managed objects exists in the source production snapshot list, is modified or deleted in the current production snapshot list, and is consistent with the candidate release list and the source production snapshot list, then the difference classification result of the managed object is determined as a production-side blocked change object; If any of the managed objects exists in the source production snapshot list and has different modifications in the current production snapshot list and the candidate release list, then the difference classification result of the managed object is determined as a bilateral fork change object.

4. The multi-environment release control method according to claim 1, characterized in that, The process of determining the target release version based on the production and promotion access control results and the candidate release versions includes: Based on the production promotion access control results, the production drift handling method for each managed object that has experienced production drift is determined; the production drift handling method includes back-suction handling and merging handling; If the production drift handling method of the managed object is the back-up processing, then for the managed object, the candidate release version is updated by back-up using the current production snapshot corresponding to the current production snapshot list to generate the target release version; If the production drift handling method of the managed object is merge processing, then for the managed object, a three-way merge is performed based on the source production snapshot, the candidate release version, and the current production snapshot corresponding to the current production snapshot list to determine the conflict handling result, and the conflict handling result is written back to the test environment to generate the target release version.

5. The multi-environment release control method according to claim 4, characterized in that, The process of merging the source production snapshot, the candidate release version, and the current production snapshot corresponding to the current production snapshot list to determine the conflict resolution result includes: Based on the source production snapshot, the candidate release version, and the current production snapshot corresponding to the current production snapshot list, construct the source production snapshot variant tree, the candidate release variant tree, and the current production snapshot variant tree; The source production snapshot variant tree, the candidate release variant tree, and the current production snapshot variant tree are used to initialize the three-party merged repository, generating a base variant tree, our variant tree, and the other party's variant tree; The base variant tree, our variant tree, and the opponent's variant tree are merged to generate a merge working branch; Based on the merged working branches, the conflict resolution result is determined.

6. The multi-environment release control method according to any one of claims 1-5, characterized in that, Before publishing the target release version in the target environment, the method further includes: Workspace objects are hierarchically identified to determine the workspace configuration layer and the workspace data layer; the managed objects include the workspace objects. The step of publishing the target release version in the target environment includes: If the target environment is a pre-release environment, then the workspace configuration layer and workspace data layer in the target release version are used for release; If the target environment is a production environment, then the release is performed using the workspace configuration layer in the target release version and the workspace data layer in the current production snapshot corresponding to the current production snapshot list.

7. The multi-environment release control method according to any one of claims 1-5, characterized in that, The process of rebuilding the test environment based on the source production snapshot includes: Use the current test environment as the initial test environment, stop the user gateway service in the initial test environment, and clean up the existing managed objects in the initial test environment; Based on the source production snapshot, the managed objects in the initial test environment are restored to obtain the intermediate test environment; The intermediate test environment is overlaid with a preset test environment overlay configuration to obtain the test environment.

8. The multi-environment release control method according to any one of claims 1-5, characterized in that, Before releasing the target release version in the target environment, the method further includes at least one of the following: Perform local and remote capacity pre-checks on the target release version; Perform a remote backup of the target release version; And / or, after publishing the target release version in the target environment, the method further includes: Perform a health check on the target release version; If the health check fails, retrieve the backup target release version from the remote repository and perform a health check on the backup target release version.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 8.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 8.

Images