Implementation method of virtual environment based on different-stage operation of application program

Abstract

The invention discloses a virtual environment implementation method based on different-stage operation of an application program, which comprises the following steps of: creating a layered virtual environment through a physical directory isolation specification, defining three parent environments, namely a development environment, an early bird test environment and a formal release environment, and establishing a sub-environment capable of being reused across the parent environments; the operating environment is dynamically switched on the basis of global environment variables, and priority loading of the sub-environment dependency library is achieved by modifying the priority of a ROSEREPO path; in combination with cooperative control of a kernel space resource interface and a user space module, the security and flexibility problems of cross-environment resource access are solved. According to the method, through deep coupling of dynamic loading rules of the sub-environment and physical isolation of the parent environment, module migration barriers among development, testing and production environments are thoroughly eliminated, seamless connection of'one-time configuration and multi-environment operation 'is achieved, and the method is particularly suitable for scenes of frequent cross-version verification in agile development.

Description

Technical Field

[0001] The present invention relates to a method for realizing a virtual environment based on running an application program at different stages, and belongs to the technical field of virtualization environment and application program running management. Background Art

[0002] In software development, a virtual environment usually refers to installing and running software packages and dependent libraries in an independent, isolated environment to avoid dependency conflicts with other projects.

[0003] However, in multi-stage development scenarios, especially in agile development processes that require simultaneous maintenance of development, testing, and production environments, existing technologies have the following drawbacks:

[0004] 1. The conflict between environmental isolation and module reuse: While container technology can achieve environmental isolation, the same functional module requires repeated image building in different environments (development / test / production), leading to configuration redundancy and inefficient migration. For example, a module debugged in the development environment must be repackaged before deployment to the test environment, which is time-consuming and prone to human error.

[0005] 2. The imbalance between the flexibility and security of dynamic switching: When switching environments by modifying system path variables (such as PATH), dependency loading errors may occur due to incomplete path coverage. While solutions that rely on complete image reconstruction can avoid path conflicts, they consume a large amount of storage resources and cannot support parallel verification of multiple environments.

[0006] 3. Systemic risks of cross-environment resource management: Traditional virtualization technologies isolate resources through namespaces, but userspace modules can still directly access the underlying hardware, posing the risk of unauthorized access leading to system crashes. For example, an abnormal module in a test environment could compromise the data integrity of the production environment due to misoperation.

[0007] To alleviate these issues, the industry has attempted to adopt environment configuration templates (such as Ansible) or dependency version locking (such as Python pip freeze). However, templated configurations struggle to adapt to dynamic demand changes, and version locking exacerbates dependency conflicts when running multiple versions in parallel. Therefore, a lightweight virtualization management solution is needed that enables seamless migration across environments while ensuring system-level security. Summary of the Invention

[0008] The present invention provides a method for implementing a virtual environment based on the operation of different stages of an application program, the main purpose of which is to solve the problems of poor system stability and low operation and maintenance efficiency caused by path conflicts and inconsistent dependency versions when migrating modules across environments in existing virtualization technologies.

[0009] To achieve the above object, the present invention provides a method for implementing a virtual environment based on different stages of application operation, comprising the following steps:

[0010] Creating a hierarchical virtual environment, including a parent environment and at least one child environment, wherein the parent environment includes a development environment, an early bird test environment, and a formal release environment;

[0011] Dynamically switch the operating environment and implement environment switching by modifying global environment variables;

[0012] Perform cross-environment module reuse and load dependent libraries based on priority rules;

[0013] The creation of the hierarchical virtual environment includes: establishing a physical isolation directory of a parent environment and a child environment under a system root directory, wherein the parent environment directory is named including a system identifier and an environment type identifier, and the child environment directory is named including a child environment name;

[0014] The dynamic switching of the operating environment includes: modifying the global environment variable ROSE_REPO to point to the target sub-environment path, and synchronously updating the HOME variable to point to the target parent environment root directory, wherein the sub-environment's dependency library loading priority is higher than the parent environment;

[0015] The cross-environment module reuse includes: the child environment accesses the underlying resources of the parent environment through the public interface provided by the kernel space, the public interface includes the file system API and the network communication API, and the resolution of resource conflicts between child environments is based on a preset priority order.

[0016] In a preferred embodiment, the priority order is determined as follows: when there are dependent libraries with the same name in multiple sub-environments, the dependent library with the most recently modified timestamp is loaded first; if the priorities are the same, the order is determined based on the parent environment type, and the order is that the development environment takes precedence over the early bird test environment, and the early bird test environment takes precedence over the official release environment.

[0017] In a preferred embodiment, the establishment of the physical isolation directory includes: the parent environment directory is named .env / parent followed by a system identifier and an environment type identifier separated by a hyphen; the child environment directory is named .env / child followed by a child environment name separated by a hyphen.

[0018] In a preferred embodiment, the public interfaces provided by the kernel space include: a resource access control interface that restricts user space modules from directly operating hardware resources; and a dynamic resource allocation interface that allocates CPU and memory resources according to sub-environment priorities.

[0019] In a preferred embodiment, the modification of the global environment variables is achieved by injecting instructions into the application startup script, and the instruction format is set as ROSE_REPO=target sub-environment path.

[0020] In a preferred embodiment, the conditions for cross-environment module reuse include: the compatibility of the dependent library version of the child environment with the public interface of the parent environment passes the version number verification; and the resource occupancy rate of the parent environment is lower than a preset threshold.

[0021] In a preferred embodiment, an environment status monitoring step is also included: real-time collection of resource usage data of the parent environment and child environment; when the resource usage exceeds a threshold, the operation of the low-priority child environment is suspended and an alarm is triggered.

[0022] In a preferred embodiment, the resource usage threshold is set as follows: the CPU usage threshold for the development environment is 90%, for the early bird test environment is 80%, and for the official release environment is 70%.

[0023] In a preferred embodiment, the optimization of the dependent library loading includes: performing a hash check on the dependent library file, and directly loading it if the hash value is consistent with the pre-stored value of the parent environment, otherwise it is synchronously updated from the parent environment.

[0024] In a preferred embodiment, an environment rollback mechanism is also included: when a child environment fails to run, it automatically switches to the backup configuration of the parent environment that was most recently successfully run. The backup configuration includes a snapshot of environment variables and dependent library version information.

[0025] Compared with the problems described in the background technology, the beneficial effects of the present invention are:

[0026] 1. Through the coordinated mechanism of dynamic loading rules for sub-environment dependency libraries and physical directory isolation in the parent environment, the same module can run directly in development, early bird testing, and official release environments without manual adaptation. This solves the configuration duplication and path conflicts caused by environment fragmentation in traditional virtualization technology. It is particularly suitable for the frequent cross-environment verification needs in agile development scenarios.

[0027] 2. Based on the priority override mechanism of the global variable (ROSE_REPO / HOME), combined with the kernel space's API-level resource access authorization for user space modules, it not only supports developers to switch operating environments within seconds, but also completely blocks the pollution of underlying resources caused by unauthorized module operations, providing a lightweight virtualization solution for high-security scenarios such as finance and healthcare.

[0028] 3. Through the physical directory naming rules of the parent environment and child environment (such as .env / parent-{system}-{env_type}) and the topological sorting logic when loading the dependent library, the dependency versions of different environments are isolated at the file storage level, while automatically avoiding startup failures caused by circular dependencies, significantly improving the reliability of multi-version parallel verification in enterprise-level applications.

[0029] 4. Through the dynamic resource allocation strategy of the child environment priority rule (timestamp + parent environment type), combined with real-time resource monitoring and automatic rollback functions, it ensures that high-priority tasks quickly obtain execution rights while the key data of low-priority tasks is not lost. It is particularly suitable for the flexible scheduling needs of sudden tasks in cloud computing scenarios. In addition, through the symbolic link decoupling design of the parent environment workspace directory and the child environment sense directory, developers can simultaneously maintain experimental versions of multiple child environments under the same parent environment, and the dependency configuration of each version is managed independently, solving the problem of production environment pollution caused by misoperation in traditional development processes. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Figure 1 This is the Release Chinese application data loading path decision flow chart of the present invention.

[0031] The purpose, features and advantages of the present invention will be further described with reference to the accompanying drawings and in conjunction with the embodiments. DETAILED DESCRIPTION

[0032] It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0033] The present invention provides a method for implementing a virtual environment based on different stages of application execution, including the following steps:

[0034] Creating a hierarchical virtual environment, including a parent environment and at least one child environment, wherein the parent environment includes a development environment, an early bird test environment, and a formal release environment;

[0035] Dynamically switch the operating environment and implement environment switching by modifying global environment variables;

[0036] Perform cross-environment module reuse and load dependent libraries based on priority rules;

[0037] The creation of the hierarchical virtual environment includes: establishing a physical isolation directory of a parent environment and a child environment under a system root directory, wherein the parent environment directory is named including a system identifier and an environment type identifier, and the child environment directory is named including a child environment name;

[0038] The dynamic switching of the operating environment includes: modifying the global environment variable ROSE_REPO to point to the target sub-environment path, and synchronously updating the HOME variable to point to the target parent environment root directory, wherein the sub-environment's dependency library loading priority is higher than the parent environment;

[0039] The cross-environment module reuse includes: the child environment accesses the underlying resources of the parent environment through the public interface provided by the kernel space, the public interface includes the file system API and the network communication API, and the resolution of resource conflicts between child environments is based on a preset priority order.

[0040] In a preferred embodiment, the priority order is determined as follows: when there are dependent libraries with the same name in multiple sub-environments, the dependent library with the most recently modified timestamp is loaded first; if the priorities are the same, the order is determined based on the parent environment type, and the order is that the development environment takes precedence over the early bird test environment, and the early bird test environment takes precedence over the official release environment.

[0041] In a preferred embodiment, the establishment of the physical isolation directory includes: the parent environment directory is named .env / parent followed by a system identifier and an environment type identifier separated by a hyphen; the child environment directory is named .env / child followed by a child environment name separated by a hyphen.

[0042] In a preferred embodiment, the public interfaces provided by the kernel space include: a resource access control interface that restricts user space modules from directly operating hardware resources; and a dynamic resource allocation interface that allocates CPU and memory resources according to sub-environment priorities.

[0043] In a preferred embodiment, the modification of the global environment variables is achieved by injecting instructions into the application startup script, and the instruction format is set as ROSE_REPO=target sub-environment path.

[0044] In a preferred embodiment, the conditions for cross-environment module reuse include: the compatibility of the dependent library version of the child environment with the public interface of the parent environment passes the version number verification; and the resource occupancy rate of the parent environment is lower than a preset threshold.

[0045] In a preferred embodiment, an environment status monitoring step is also included: real-time collection of resource usage data of the parent environment and child environment; when the resource usage exceeds a threshold, the operation of the low-priority child environment is suspended and an alarm is triggered.

[0046] In a preferred embodiment, the resource usage threshold is set as follows: the CPU usage threshold for the development environment is 90%, for the early bird test environment is 80%, and for the official release environment is 70%.

[0047] In a preferred embodiment, the optimization of the dependent library loading includes: performing a hash check on the dependent library file, and directly loading it if the hash value is consistent with the pre-stored value of the parent environment, otherwise it is synchronously updated from the parent environment.

[0048] In a preferred embodiment, an environment rollback mechanism is also included: when a child environment fails to run, it automatically switches to the backup configuration of the parent environment that was most recently successfully run. The backup configuration includes a snapshot of environment variables and dependent library version information.

[0049] See also Figure 1 , Figure 1The invented Release Chinese application data loading path decision flowchart shows the path decision process when the Release Chinese App loads data: when starting data loading, first determine whether there is a childenv; if there is no childenv, set CDS_HOME to SCDS_OUT / user / userName, and load the data of SCDS_ROOT / sense and SCDS_HOME / sense; if there is a childenv, also set CDS_HOME to SCDS_OUT / user / userName, but additionally load the data under the SCDS_HOME / .ENV.child-env-name / sense path, and finally complete the loading process.

[0050] Example 1: In the agile development scenario of a large internet company, the Release Chinese App needs to support data loading for development, test, and production environments simultaneously. Traditional solutions, due to insufficient environmental isolation, cannot directly migrate development phase configurations to the test environment. Manual image reconstruction is required, which is inefficient and prone to path conflicts. This example optimizes data loading by following these steps:

[0051] Step 1: Environment initialization and path determination. After the system starts the Release Chinese app, it enters the data loading phase. First, it determines whether a Children node (i.e., child environment configuration) currently exists. If no Children node exists (e.g., when deploying a production environment for the first time), the environment variable CDS_HOME is set to SCDS_ROOT / user / userName, and data is loaded from SCDS_ROOT / sense (system global configuration) and CDS_HOME / sense (user personalized configuration).

[0052] Step 2: Dynamically load the child environment. If a Children node exists (for example, if the test environment needs to reuse the development configuration), the system also sets CDS_HOME = SCDS_ROOT / user / userName, but additionally loads the child-environment-specific configuration under the CDS_HOME / .ENV / child-env-name / sense path. For example, the configuration file for the test child environment child-env-name = test_v2 is stored independently and physically isolated from the development environment child-dev_v1 to prevent version overlap.

[0053] Step 3: Priority drives data merging. During loading, the child environment configuration file (child-env-name / sense) takes precedence over the user configuration file (CDS_HOME / sense), which in turn takes precedence over the global configuration file (SCDS_ROOT / sense). When files with the same name conflict, the system automatically overwrites them based on priority. For example, database connection parameters specific to the test environment replace the global defaults, ensuring that module behavior meets the requirements of the current environment.

[0054] Step 4: Kernel space resource authorization. The child environment accesses the parent environment's resources through the kernel space's file system API. For example, when the test environment needs to read the production environment's benchmark dataset, the kernel interface verifies permissions and dynamically authorizes it, prohibiting unauthorized writes and preventing test data from contaminating the production database.

[0055] Example 2: This example demonstrates a module developer creating a project named "data-processor" in the Codigger system. When the user executes the command "cds env use parent-codigger-development" to switch to the development environment, the system automatically updates the HOME environment variable to point to the development environment's workspace directory. When the project is opened in the VSCode extension, the IDE automatically recognizes the current environment configuration and generates a green-bordered environment icon in the debug panel.

[0056] When developers write module code, they reference the core library using the `import {core-utils} from '@codigger / core'` statement. Based on the ROSE_REPO path setting for the development environment, the system prioritizes searching for local debug versions in the $HOME / workspace / modules directory over stable versions in the release environment. When developers trigger the live preview feature, the system builds a separate ChildEnv sandbox in memory and automatically mounts the `test-config.yaml` file in the project directory as the environment configuration.

[0057] When submitting to continuous integration, the build system dynamically creates an earlybird environment container by parsing the child-env-meta.json file in the .env directory. This container inherits the Python 3.9 runtime from the development environment but forces the loading of official dependency versions specified in prod-dependencies.txt. During integration testing, the logging system automatically adds the "Env:earlybird" prefix, and path mappings in error stack traces are converted to absolute paths on the host machine based on the CDS_HOST_HOME variable.

[0058] Once a module passes quality control, the release process automatically executes the cds env merge command to deeply merge the child-env-data-processor configuration with the global settings of the release environment. When users install the module through the App Store, the system creates a separate ChildEnv instance marked with a blue icon. Its sense directory contains both the developer's pre-set config template and the user-defined override.json file.

[0059] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention.

[0060] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not limiting. Although the present invention has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical solutions of the present invention may be modified or replaced by equivalents without departing from the spirit and scope of the technical solutions of the present invention.

Claims

1. A method for implementing a virtual environment based on different stages of application operation, characterized in that: The following steps are involved: Creating a hierarchical virtual environment, including a parent environment and at least one child environment, wherein the parent environment includes a development environment, an early bird test environment, and a formal release environment; Dynamically switch the operating environment and implement environment switching by modifying global environment variables; Perform cross-environment module reuse and load dependent libraries based on priority rules; The creation of the hierarchical virtual environment includes: establishing a physical isolation directory of a parent environment and a child environment under a system root directory, wherein the parent environment directory is named including a system identifier and an environment type identifier, and the child environment directory is named including a child environment name; The dynamic switching of the operating environment includes: modifying the global environment variable ROSE_REPO to point to the target sub-environment path, and synchronously updating the HOME variable to point to the target parent environment root directory, wherein the sub-environment's dependency library loading priority is higher than the parent environment; The cross-environment module reuse includes: the child environment accesses the underlying resources of the parent environment through the public interface provided by the kernel space, the public interface includes the file system API and the network communication API, and the resolution of resource conflicts between child environments is based on a preset priority order.

2. A method for implementing a virtual environment based on different stages of application operation according to claim 1, characterized in that: The priority order is determined as follows: when multiple sub-environments have dependent libraries with the same name, the dependent library with the most recently modified timestamp is loaded first; if the priorities are the same, the order is determined based on the parent environment type, with the development environment taking precedence over the early bird test environment, and the early bird test environment taking precedence over the official release environment.

3. The method for implementing a virtual environment based on different stages of application operation according to claim 1, characterized in that: The establishment of the physical isolation directory includes: the parent environment directory is named .env / parent followed by a system identifier and an environment type identifier separated by a hyphen; the child environment directory is named .env / child followed by a child environment name separated by a hyphen.

4. The method for implementing a virtual environment based on different stages of application operation according to claim 1, characterized in that: The public interfaces provided by the kernel space include: a resource access control interface that restricts modules in the user space from directly operating hardware resources; and a dynamic resource allocation interface that allocates CPU and memory resources according to sub-environment priorities.

5. The method for implementing a virtual environment based on different stages of application operation according to claim 1, characterized in that: The modification of the global environment variables is achieved by injecting instructions into the application startup script, and the instruction format sets ROSE_REPO=target sub-environment path.

6. The method for implementing a virtual environment based on different stages of application program operation according to claim 1, characterized in that: The conditions for cross-environment module reuse include: the compatibility of the dependent library version of the child environment with the public interface of the parent environment passes the version number verification; the resource occupancy rate of the parent environment is lower than the preset threshold.

7. The method for implementing a virtual environment based on different stages of application operation according to claim 1, characterized in that: It also includes an environment status monitoring step: real-time collection of resource usage data for the parent environment and child environment; when resource usage exceeds the threshold, the operation of the low-priority child environment is suspended and an alarm is triggered.

8. The method for implementing a virtual environment based on different stages of application operation according to claim 1, characterized in that: The resource usage threshold is set as follows: the CPU usage threshold for the development environment is 90%, for the early bird test environment is 80%, and for the official release environment is 70%.

9. The method for implementing a virtual environment based on different stages of application program operation according to claim 1, characterized in that: The optimization of the dependent library loading includes: performing hash verification on the dependent library file, and directly loading if the hash value is consistent with the pre-stored value of the parent environment, otherwise synchronously updating from the parent environment.

10. The method for implementing a virtual environment based on different stages of application program operation according to claim 1, characterized in that: It also includes an environment rollback mechanism: when a child environment fails to run, it automatically switches to the backup configuration of the parent environment that last successfully ran. The backup configuration includes a snapshot of environment variables and dependent library version information.

Images