Automatic code release method and device supporting different operating systems, computer device and program product
By integrating and automating the process of deployment tools, code distribution packages adapted to different operating systems are built and deployed, solving the inefficiency problem of traditional manual reliance and achieving efficient and automated code deployment.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- KINGDEE SOFTWARE(CHINA) CO LTD
- Filing Date
- 2026-02-09
- Publication Date
- 2026-06-12
AI Technical Summary
Traditional software release processes rely on manual operations, resulting in low development efficiency and difficulty in adapting to heterogeneous environments with different operating systems.
By acquiring compilation scripts for multiple runtime environments through target integration tools, building matching deployment packages, and automatically deploying them based on hardware architecture information using target deployment tools, the code release is fully automated.
It achieves high efficiency and consistency in code deployment, solves the adaptation problem of heterogeneous environments, and improves development efficiency and the degree of automation in the deployment process.
Smart Images
Figure CN122195437A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and in particular to an automatic code distribution method, apparatus, computer equipment, computer-readable storage medium, and computer program product that supports different operating systems. Background Technology
[0002] With the development of computer technology, software updates and iterations are becoming increasingly frequent. After developers upload the update code for the software, they need to release and launch the update code to realize the software application update.
[0003] In traditional technologies, software release is primarily handled as follows: developers manually compile the code, create patch packages, and then deploy the patches sequentially to the development, testing, UAT, and production environments. This process involves repetitive manual operations and heavily relies on human experience, resulting in low development efficiency. Summary of the Invention
[0004] Therefore, it is necessary to provide a method, apparatus, computer equipment, computer-readable storage medium, and computer program product that can improve development efficiency, automate code deployment, and support different operating systems to address the above-mentioned technical problems.
[0005] Firstly, this application provides a method for automatic code deployment supporting different operating systems, including:
[0006] In response to the upload event of the target code, the system obtains target compilation scripts corresponding to multiple runtime environments through the target integration tool; compiles the target code into target bytecode files; runs each target compilation script to obtain matching target resource files; constructs target deployment packages matching each runtime environment based on the target bytecode files and each target resource file; and stores each target deployment package in the artifact image library.
[0007] The target hardware architecture information of the target runtime environment is obtained through the target deployment tool, and the corresponding target deployment package is obtained from the artifact image library based on the target hardware architecture information; the configuration information of the target runtime environment is read, and the target deployment package is deployed to the target runtime environment according to the configuration information.
[0008] Secondly, this application also provides an automatic code deployment device that supports different operating systems, including:
[0009] An integration module is used to respond to an upload event of target code, obtain target compilation scripts corresponding to multiple runtime environments; compile the target code into target bytecode files; run each target compilation script to obtain matching target resource files; construct target deployment packages matching each runtime environment based on the target bytecode files and each target resource file; and store each target deployment package in an artifact image library.
[0010] The deployment module is used to obtain the target hardware architecture information of the target operating environment, obtain the corresponding target deployment package from the artifact image library based on the target hardware architecture information, read the configuration information of the target operating environment, and deploy the target deployment package to the target operating environment according to the configuration information.
[0011] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps described in the methods above.
[0012] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps described in the methods above.
[0013] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps described in the methods above.
[0014] The aforementioned automatic code deployment method, apparatus, computer equipment, computer-readable storage medium, and computer program product supporting different operating systems, respond to target code upload events by obtaining target compilation scripts corresponding to multiple operating environments through a target integration tool, and running each target compilation script to obtain target resource files corresponding to different operating environments. Then, based on the target bytecode files and corresponding target resource files, target deployment packages matching different operating environments are constructed. This enables unified code submission and parallel construction across multiple architectures, effectively solving the adaptation problem of heterogeneous environments such as domestic IT innovation. Subsequently, the target deployment tool obtains the target hardware architecture information of the target operating environment, and based on the target hardware architecture information, retrieves the target deployment package corresponding to the target operating environment from the artifact image library. Thus, the entire code deployment process is fully automated, improving the efficiency and consistency of code deployment. Attached Figure Description
[0015] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0016] Figure 1 This is a flowchart illustrating an automatic code deployment method supporting different operating systems in one embodiment;
[0017] Figure 2 This is a schematic diagram of the architecture of an automated code deployment system in one embodiment;
[0018] Figure 3 This is a flowchart illustrating an automatic code deployment method supporting different operating systems in another embodiment;
[0019] Figure 4 This is a structural block diagram of an automatic code deployment device that supports different operating systems in one embodiment.
[0020] Figure 5 This is an internal structural diagram of a computer device in one embodiment;
[0021] Figure 6 This is a diagram of the internal structure of a computer device in another embodiment. Detailed Implementation
[0022] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.
[0023] In one exemplary embodiment, such as Figure 1 As shown, an automatic code deployment method supporting different operating systems is provided. This embodiment illustrates the method's application to a terminal, but it is understood that the method can also be applied to a server, and to a system including both a terminal and a server, and implemented through interaction between the terminal and the server. In this embodiment, the method includes the following steps:
[0024] S102, in response to the target code upload event, obtain the target compilation scripts corresponding to multiple runtime environments through the target integration tool; compile the target code into target bytecode files; run each target compilation script to obtain matching target resource files; build target deployment packages matching each runtime environment based on the target bytecode files and each target resource file; and store each target deployment package in the artifact image library.
[0025] In this context, "target code" refers to the source code (such as Java, Python, Go source code, etc.) written and uploaded by the developer. In this embodiment, the target code can be uploaded to a code repository. In addition to the target code, the corresponding metadata, database scripts, and static resources are also uploaded to the code repository, facilitating the subsequent target integration tool to retrieve a series of files related to the target code from the code repository to build the target deployment package.
[0026] Upload events refer to action signals that trigger the code release process, such as when a developer submits code via the Git Push command.
[0027] Target integration tools refer to tools used to automatically build, compile, and package target code submitted by developers. In this embodiment, it is a continuous integration pipeline. Target integration tools can be triggered by code changes in the code repository and automatically perform a series of operations to achieve code integration, including code merging, static analysis, code scanning (such as security scanning and quality checks), cross-architecture compilation (adapting to different hardware architectures x86 / ARM), creating deployment packages (such as JAR packages, static resource files, data model files, description files, etc.), and pushing qualified deployment packages to the artifact image repository.
[0028] The runtime environment refers to the operating system or platform environment in which the target code ultimately runs, such as Linux x86_64, Linux ARM64, Windows environment, Android environment, and domestic IT innovation environment.
[0029] The target compilation script refers to the build instruction file written for the hardware architecture corresponding to a specific runtime environment. For example, the target compilation script for the x86 architecture is compile_x86.sh, and the target compilation script for the ARM architecture is compile_arm.sh.
[0030] Target bytecode files refer to intermediate code generated after the target code has been processed by the compiler, which lies between the source code and the machine code. Examples include Java's .class files and Python's .pyc files.
[0031] Target resource files refer to dependency libraries or files that are required for bytecode execution and are compiled for a specific environment. Examples include architecture-specific parameters and native libraries corresponding to domestic IT innovation environments.
[0032] A target deployment package refers to a data package containing all the contents (bytecode, libraries, startup scripts, etc.) required to run the target code, which can be a JAR package, Docker image, compressed package, etc.
[0033] An artifact repository is a system used to store and version-manage build artifacts (e.g., JAR packages, Docker / OCI images, compressed files, etc.). It is a key component linking target integration tools and target deployment tools, used to store, manage, and distribute standardized build artifacts output by the target integration tools. In this embodiment, the artifact repository supports version management, artifact traceability, and cross-environment access.
[0034] For example, a developer submits target code to a code repository. The target integration tool is triggered upon detecting the target code upload event. First, the target integration tool compiles the target code into target bytecode files. Next, the tool reads target compilation scripts corresponding to different runtime environments from the code repository. Each target compilation script is run to obtain matching target resource files. These target resource files can be base images corresponding to different runtime environments. For example, for an AMD64 environment, `Dockerfile.amd64` is run to pull a base image based on `linux / amd64`. This base image contains C libraries and system instruction sets adapted for x86 CPUs. Similarly, for an ARM64 environment, `Dockerfile.arm64` is run to pull a base image based on `linux / arm64`, obtaining system libraries and instruction sets adapted for ARM chips. Then, the target bytecode files are copied into the base image to obtain the target image, i.e., the target deployment package. Finally, each target deployment package is pushed to the artifact image repository. It is understandable that when pushing target deployment packages corresponding to different operating environments to the artifact image repository, a unique identifier is built for these target deployment packages so that subsequent target deployment tools can pull the corresponding target deployment packages based on the identifier.
[0035] In some embodiments, the target deployment package is a patch package that fixes a specific issue. A developer submits target code to fix a bug. The target integration tool obtains this target code and compiles it into target bytecode files. Then, it obtains target compilation scripts corresponding to different runtime environments, runs each script, and collects corresponding environment-specific auxiliary files, i.e., target resource files, based on the different runtime environments. Finally, the target deployment tool packages and compresses the target bytecode files and target resource files to obtain the target deployment package.
[0036] S104: Obtain the target hardware architecture information of the target runtime environment through the target deployment tool, and obtain the corresponding target deployment package from the artifact image library based on the target hardware architecture information; read the configuration information of the target runtime environment, and deploy the target deployment package to the target runtime environment according to the configuration information.
[0037] The target deployment tool is used to automatically pull built artifacts from the artifact image repository and deploy them to the target runtime environment. Specifically, the target deployment tool pulls qualified build artifacts from the artifact image repository and automatically performs environment preparation, automated deployment, automated acceptance testing, release confirmation, full deployment, and post-release monitoring, thereby achieving end-to-end delivery of build artifacts to the target runtime environment (development runtime environment / test runtime environment / user acceptance test runtime environment / production runtime environment).
[0038] The target hardware architecture information refers to the CPU architecture type of the target server.
[0039] Configuration information refers to the parameters required to run the target code in the target runtime environment, such as database connection address, port number, environment variables, etc.
[0040] For example, in response to an update event in the artifact image repository or a deployment operation targeting a deployment package, the target deployment tool can first check the CPU instruction set architecture of the current server to identify the hardware chip architecture type corresponding to the current environment. Then, based on the identified architecture information, it initiates a pull request to the artifact image repository. For example, it pulls a target deployment package (such as a target image) that matches the target hardware architecture information from the artifact image repository. Next, the target deployment tool reads configuration files that match the target runtime environment. These configurations contain sensitive or environment-differentiated information such as database connection strings, port numbers, and keys. The read configuration information is injected into the target image as "environment variables" or "mount files," and then the target image is started. In this way, the application corresponding to the target code can run successfully on the target hardware architecture using the correct configuration.
[0041] In some embodiments, if the target deployment package is a patch package, after pulling the matching patch package from the artifact image library based on the target hardware architecture information, the target deployment package is decompressed according to the preset decompression rules and the decompressed files are copied to the corresponding location in the system files corresponding to the target runtime environment to complete the deployment.
[0042] The aforementioned automated code deployment method supporting different operating systems involves responding to target code upload events by using a target integration tool to obtain target compilation scripts corresponding to multiple operating environments. Each target compilation script is then run to obtain target resource files corresponding to different operating environments. Based on the target bytecode files and their corresponding resource files, target deployment packages matching different operating environments are constructed. This enables unified code submission and parallel construction across multiple architectures, effectively solving the adaptation problem for heterogeneous environments such as domestic IT innovation. Subsequently, the target deployment tool obtains the target hardware architecture information of the target operating environment. Based on this information, the target deployment package corresponding to the target operating environment is retrieved from the artifact image repository. This achieves full automation of the code deployment process, improving the efficiency and consistency of code deployment.
[0043] In some embodiments, the following steps may be performed: in response to the upload event of the target code, obtain the hardware architecture corresponding to each runtime environment, and obtain the corresponding target compilation script based on the hardware architecture; compile the target code into target bytecode files; obtain the source code of the native library that matches the runtime environment; run the target compilation script to compile the source code of the native library to obtain the corresponding target resource files; build a target image that matches the runtime environment; and package the corresponding target bytecode files and target resource files into the image to obtain the corresponding target deployment package.
[0044] Specifically, in response to the upload event of the target code, the hardware architecture corresponding to each runtime environment is obtained. This obtained hardware architecture can be the hardware architecture of the environment to which the code will be deployed, for example, by identifying the hardware architecture identifier of the target runtime environment (e.g., development, testing, UAT, or production environment) using a runtime environment detection script. The corresponding build configuration file is automatically matched based on the hardware architecture identifier. The target code is then compiled into target bytecode files. Subsequently, the crucial native compilation stage begins, where the native library source code corresponding to each runtime environment (e.g., C language source code for image processing or encryption) is obtained. The target compilation script corresponding to each runtime environment is run, compiling the obtained native library source code into binary dependency libraries (i.e., target resource files) adapted to different hardware architectures. Finally, these binary dependency libraries and business bytecode are assembled into the corresponding operating system image, creating container image packages for different runtime environments. This allows the same business logic to seamlessly adapt to multiple underlying hardware without manual intervention.
[0045] In this embodiment, by first obtaining the hardware architecture and matching the compilation script accordingly, accurate compilation for different CPU instruction sets is achieved. By packaging the bytecode and native resource files into an image of a specific architecture, the generated deployment package has good isolation and consistency, which can ensure that the application runs correctly and efficiently in heterogeneous distributed environments (such as hybrid cloud and edge computing nodes), thereby solving the problem of the complexity and error-proneness of manually adapting to multiple architecture environments.
[0046] In some embodiments, if a patch package is pulled from the artifact image library, the configuration information of the target runtime environment is read, and the target deployment package is deployed to the target runtime environment according to the configuration information, including: reading environment requirement information from the target deployment package; if the server information of the target runtime environment meets the environment requirement information, the general configuration information in the target deployment package is replaced with the configuration information of the target runtime environment, and each file in the target deployment package is deployed to the corresponding file location in the system directory of the target runtime environment.
[0047] The configuration information includes operating system parameters and database connection information. Operating system parameters refer to settings that affect operating system behavior or application resource limits. Database connection information refers to the credentials and network address required for the application to connect to the background database, which may include the JDBC URL, username, password, and driver class name.
[0048] Among them, the environmental requirements information refers to the list of hardware and software conditions that the software must meet to run, which may include operating system version, CPU architecture, minimum memory requirements, and versions of dependent underlying components.
[0049] Server information refers to the actual attribute data of the target operating environment, such as the current operating system kernel version and the actual physical memory size.
[0050] General configuration information refers to the default configurations or placeholders pre-configured in the target deployment package during the packaging stage, such as using DATABASEADRESS instead of the actual database address. These configurations may differ in different environments. During deployment, the configuration information of the target runtime environment is read and replaced with this general configuration information.
[0051] The system directory refers to the standard path in the operating system used to store specific types of files.
[0052] Specifically, the process begins by uncompressing the target deployment package, such as a patch package, and reading its metadata files to obtain environment requirement information. Next, the server information of the target runtime environment is checked (e.g., corresponding to a domestic IT innovation environment). If it is found to be inconsistent (e.g., the environment requirement information corresponds to x86, while the current target runtime environment corresponds to a domestic IT innovation environment), the installation is terminated to prevent system crashes. If the check passes, the actual database connection information of the current environment is read from the configuration library corresponding to the target runtime environment, and this information is used to replace the placeholders in the general configuration file in the corresponding directory of the patch package. Finally, an uncompressed and overwrite operation is performed, precisely copying the compiled files and modified configuration files from the patch package to the corresponding system directories, overwriting the old files, thus completing the repair.
[0053] In this embodiment, by verifying the "server information" and "environmental requirements information" before deployment, a compatibility defense can be effectively built to prevent the risk of system paralysis caused by "broken patches" due to version incompatibility or hardware incompatibility. Simultaneously, by replacing the general configuration in the patch package with the specific configuration of the current environment, not only can the patch content be seamlessly integrated with the runtime environment, but the loss of personalized configurations due to patch overwriting is also avoided. This ensures that the application gains new functionality after the update while maintaining its original business connections and operating parameters without interruption.
[0054] In some embodiments, a target deployment package matching each runtime environment is constructed based on the target bytecode file and each target resource file, including: obtaining a packaging tool and obtaining a pre-configured structure template through the packaging tool; determining a first directory, a second directory, and a third directory from the structure template; creating a new folder and creating a first directory, a second directory, and a third directory under the folder; storing the target bytecode file and the target resource file in the first directory, storing the front-end static resource file in the second directory, and storing the data model file in the third directory; and compressing the first directory, the second directory, and the third directory using a compression tool to obtain the target deployment package.
[0055] Specifically, the patch package packaging tool is launched, such as a custom packaging plugin based on Gradle / Maven. It reads a pre-configured patch package structure template and determines the first directory (e.g., jar / ), second directory (e.g., resource / ), third directory (e.g., dm / ), and fourth directory (e.g., kdpkgs.xml) from this template. Then, the compiled JAR package (including target bytecode files and target resource files) is automatically copied to the jar / directory, the front-end static resources (e.g., CSS / JS / HTML) compressed package is decompressed to the second directory, and the data model SQL file is copied to the third directory.
[0056] In addition, to enable subsequent deployment tools to quickly understand the contents of the target deployment package, a description file matching the target deployment package can be generated based on relevant information from the target bytecode file and target resource file. For example, a patch package description file kdpkgs.xml can be automatically generated, containing build identifiers, patch version, a list of included files, and dependency requirements. Then, a ZIP compression tool is used to package the above directory and the description file into a standardized patch package, and the build identifier is written into the patch package's metadata file to complete version marking.
[0057] In this embodiment, by creating a standardized directory structure based on a structural template, separating the front-end, back-end, data, and metadata, the consistency of the internal organization of the deployment package can be ensured. This allows the deployment script or decompression program to accurately locate different types of files in the correct positions within the system, avoiding deployment errors caused by disorganized files. Furthermore, by generating a description file, self-descriptive capabilities (such as version verification and dependency declarations) are added to the deployment package, enabling operations and maintenance personnel to quickly verify the integrity and compatibility of the package before decompression or system deployment, greatly improving the reliability of software delivery and the convenience of subsequent maintenance.
[0058] In some embodiments, after deploying the target deployment package to the target runtime environment according to the configuration information, automated testing is also required to ensure that the deployment effect meets expectations. For example, the following steps can be performed: obtain the identifier of the target deployment package; obtain the test script corresponding to the identifier from the code repository; start the target runtime environment, execute the test script, obtain functional test data, and obtain the interface response data corresponding to the target business interface; determine the test results based on the interface response data and the functional test data.
[0059] The target deployment package identifier is used to uniquely distinguish different versions or build artifacts, such as the corresponding project name, hardware architecture, and trigger event for the upload event. In addition to storing the target code, the code repository can also store the test scripts corresponding to the target code.
[0060] Test scripts refer to automated test program code used to simulate user operations or send requests to verify software functionality.
[0061] Functional test data refers to the verification results of interface interaction and business process logic collected by executing test scripts, such as status information like "login button clicked successfully", "page redirection was correct", and "form submission passed".
[0062] The target business interface refers to the API endpoint provided by the application, such as / api / user / login, which is used to handle specific business logic requests.
[0063] Interface response data refers to the raw data returned by the business interface after receiving the request, including the HTTP status code, response body, and response time.
[0064] Test results refer to the final conclusions after comprehensive evaluation, which usually include "pass / fail" status, test coverage, a list of discovered bugs (vulnerabilities), and performance metric reports.
[0065] Specifically, the process begins by obtaining the unique version number (identifier) of the newly built target deployment package and using this number to pull the corresponding test case code from the code repository, ensuring that the test version matches the code version. Subsequently, the target integration tool gains access to the development environment. The test script drives the corresponding browser to simulate real user operations, generating functional test data (such as screenshots of page elements and click feedback). Simultaneously, the test script can directly send HTTP requests to the backend to obtain JSON response data from the underlying business interfaces. Finally, the expected UI performance (i.e., user interface performance) is compared with the actual interface response to determine whether the front-end display and backend logic meet expectations, thereby generating a detailed test report. If the test report for the development environment is satisfactory, access to the UAT environment (i.e., the user acceptance test runtime environment) can be maintained, the target deployment package can be deployed to the UAT environment, and the corresponding tests can be automatically started. If the test results for the UAT environment are also satisfactory, the target deployment package can be deployed to other runtime environments until it is released online (i.e., deployed to the production environment). If the test results show problems, i.e., the test fails, a rollback operation is automatically initiated, restoring the runtime environment to its state before the target code was deployed (e.g., database information).
[0066] In this embodiment, by obtaining an identifier and the corresponding test script, the version consistency between the test code and the code under test is ensured. Simultaneously, by performing automated testing on the system after deploying the target code, the quality and stability of the deployment package before its release can be guaranteed.
[0067] In some embodiments, after determining the test result based on interface response data and functional test data, the process includes: if the test result corresponds to a test failure, obtaining the reversal log of the metadata storage, restoring the database to the pre-deployment state based on the reversal log, wherein the reversal log includes the original attributes and data values of the data tables in the database; stopping the running process of the current application deployed in the target runtime environment, unloading the target deployment package, and deploying the historical deployment package corresponding to the pre-deployment state to the target runtime environment; obtaining the historical resource information corresponding to the historical deployment package, and replacing the static resources and middleware configurations in the target runtime environment with the historical resource information.
[0068] For example, when the automated test report shows a failure, a rollback script is invoked to immediately trigger the rollback logic. Running the rollback script first pulls the backup file of the previous version from the backup server. Next, a database recovery command is executed, forcibly overwriting the database data and structure back to the state before the test (e.g., a database snapshot). Simultaneously, modified static files are deleted, and the old version of static resource files from the backup are copied to the corresponding file locations in the current system directory. Finally, the problematic application is uninstalled, a stable deployment package (e.g., an older version of the JAR file) is reinstalled, and the service is restarted, ensuring the test environment is quickly restored to a usable baseline state, facilitating developer intervention and troubleshooting.
[0069] Optionally, if deployment is performed via an image, the currently deployed image version will be rolled back to the image corresponding to the stable deployment package.
[0070] In this embodiment, by immediately obtaining the stable system data of the previous version and performing a restore operation after a test failure, it is possible to effectively eliminate dirty data and configuration pollution caused by new version code or failed database migration scripts, and avoid the accumulation of error states.
[0071] In some embodiments, before storing each target deployment package to the artifact image repository, the method further includes: obtaining the name of the target runtime environment corresponding to the target deployment package, obtaining the submission time of the corresponding target code, obtaining the project identifier corresponding to the target code; randomly generating a target random number of a target length; and concatenating the name, submission time, project identifier, and target random number to obtain the identifier corresponding to the target deployment package.
[0072] The name of the target operating environment can be the name of the corresponding hardware architecture.
[0073] Project identifiers are unique codes used to distinguish different software projects, such as the project name (e.g., payment-service) or the project ID, which are used to identify which business system the deployment package belongs to.
[0074] Specifically, a unique identifier is generated using the project identifier, a timestamp accurate to the minute, and 6 random characters (such as CMSK-202509050810-8F3D7A). This identifier forms a unique mapping with the code commit hash, patch package file name, image tag, deployment log, and test report.
[0075] In this embodiment, by combining the project name, the corresponding hardware architecture identifier, the submission time, and a randomly generated random number, the generated identifier is not only unique but also interpretable, facilitating subsequent troubleshooting.
[0076] In one exemplary embodiment, reference is made to Figure 2 and Figure 3This embodiment uses an integrated architecture of "code repository + CI pipeline (i.e., the target integration tool mentioned above) + artifact / image repository (i.e., the artifact image library mentioned above) + CD pipeline (i.e., the target deployment tool mentioned above)" to connect the entire process of code development, building, verification and deployment.
[0077] First, the developer submits the code (including Java code, metadata, and database scripts) to the code repository, specifies the target branch, and triggers the CI pipeline execution.
[0078] Next, the CI pipeline executes an automated build process: First, code merging is performed to resolve branch conflicts. Based on the code repository's branch management rules (such as GitLab's Merge Request mechanism), the CI pipeline automatically identifies the target branch (the branch identifier specified by the developer during commit, such as release-v1.0), pulls the code differences between the target branch and the current development branch (corresponding to the target code), and automatically merges the code using preset conflict resolution strategies (such as "based on the target branch code" or "preserving newly added code from the development branch"). If a conflict that cannot be automatically resolved is identified during the merge process (e.g., a conflict over modifying the same line of code in the same file), a conflict alert is triggered, and the pipeline is paused until the developer manually intervenes to resolve the conflict before re-triggering the merge. Next, the target code is checked for syntax errors, and its compliance with preset coding standards is verified. If the target code has no syntax errors and complies with coding standards, the next step can proceed. Finally, a security vulnerability scan and performance risk detection are performed on the current development branch to improve its security. Since the target runtime environment may correspond to different hardware architectures, the compilation script of the adaptation layer (i.e., the target compilation script mentioned above) can be called according to the target environment architecture (Intel x86 chip / China's domestically developed Kunpeng ARM chip) to generate a JAR package compatible with the corresponding architecture (i.e., the target bytecode file and target resource file mentioned above). Then, the JAR package, static resources, data model (SQL file), and patch description file are integrated to generate a standardized patch package (i.e., the target deployment package mentioned above). An ID tag version is then created, and these files are assigned this identifier to facilitate subsequent deployment. Finally, the qualified patch package is pushed to the artifact repository (i.e., a part of the artifact image repository mentioned above). In the case of containerized deployment, an image adapted to the domestically developed environment is simultaneously generated and pushed to the image repository (i.e., a part of the artifact image repository mentioned above).
[0079] Next, the target deployment package is deployed to the target runtime environment. First, based on the build identifier, the corresponding version of the patch package / image is pulled from the artifact repository / image repository. The configuration information of the target runtime environment (test / UAT / production), such as parameters of the domestic operating system (Kylin OS), database (DM) connection information, etc., is read, and environment initialization is automatically completed. Then, JAR packages and static resources are deployed, database scripts are executed, metadata is imported, and the application service is restarted. Afterwards, interface testing and functional verification testing are performed to ensure that the deployment effect meets expectations. For example, interface testing covers core business interfaces (such as user login and data query), requiring an interface response time ≤1000ms under the domestic IT innovation environment. Functional testing verifies core functions such as page rendering and data interaction, and compatibility with the domestic 360 browser domestic IT innovation version. Finally, the deployment is performed. Optionally, manual review and confirmation are supported before deployment to the online runtime environment; after approval, a full deployment is executed.
[0080] To ensure the security of the target code, the runtime status and resource usage of the released application can be monitored after deployment, triggering alerts when anomalies are detected. If acceptance testing fails, post-deployment monitoring metrics exceed limits, or a manual rollback request is initiated, the rollback process is automatically initiated. First, based on the reversal log stored in metadata, the database is restored to its pre-deployment state (recording the original attributes and data values of the data tables). Next, the current application process is stopped, the JAR package adapted to the current architecture is uninstalled, and the application is switched to the stable version of the JAR package before deployment and restarted. Finally, static resources and middleware configurations are synchronously rolled back, restoring the application to its historical stable state. After the rollback is complete, basic functional tests are re-executed to ensure application and data consistency, and a rollback report is generated.
[0081] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.
[0082] Based on the same inventive concept, this application also provides an automatic code deployment apparatus for supporting different operating systems, used to implement the above-described automatic code deployment method for supporting different operating systems. The solution provided by this apparatus is similar to the implementation described in the above-described method. Therefore, the specific limitations in one or more embodiments of the automatic code deployment apparatus supporting different operating systems provided below can be found in the limitations of the automatic code deployment method for supporting different operating systems described above, and will not be repeated here.
[0083] In one exemplary embodiment, such as Figure 4 As shown, an automatic code deployment device 400 supporting different operating systems is provided, including: an integration module 401 and a deployment module 402, wherein:
[0084] The integration module 401 is used to respond to the upload event of the target code, obtain the target compilation scripts corresponding to multiple runtime environments; compile the target code into target bytecode files; run each target compilation script to obtain the matching target resource files; build the target deployment package matching each runtime environment based on the target bytecode files and each target resource file; and store each target deployment package to the artifact image library.
[0085] The deployment module 402 is used to obtain the target hardware architecture information of the target runtime environment, obtain the corresponding target deployment package from the artifact image library based on the target hardware architecture information, read the configuration information of the target runtime environment, and deploy the target deployment package to the target runtime environment according to the configuration information.
[0086] In some embodiments, the integration module 401 is specifically used to: obtain the hardware architecture corresponding to each runtime environment, obtain the corresponding target compilation script based on the hardware architecture; obtain the native library source code that matches the runtime environment; run the target compilation script to compile the native library source code to obtain the corresponding target resource file; build the target image that matches the runtime environment; and package the corresponding target bytecode file and target resource file into the image to obtain the corresponding target deployment package.
[0087] In some embodiments, in reading the configuration information of the target runtime environment and deploying the target deployment package to the target runtime environment according to the configuration information, the deployment module 402 is specifically used to: read environment requirement information from the target deployment package; if the server information of the target runtime environment meets the environment requirement information, then replace the general configuration information in the target deployment package with the configuration information of the target runtime environment, and deploy each file in the target deployment package to the corresponding file location in the system directory of the target runtime environment. The configuration information includes operating system parameters and database connection information.
[0088] In some embodiments, after deploying the target deployment package to the target runtime environment according to the configuration information, the deployment module 402 is further configured to: obtain the identifier of the target deployment package; obtain the test script corresponding to the identifier from the code repository; start the target runtime environment in the target browser, execute the test script, obtain functional test data, and obtain the interface response data corresponding to the target business interface; and determine the test result based on the interface response data and the functional test data.
[0089] In some embodiments, after determining the test result based on interface response data and functional test data, the deployment module 402 is specifically configured to: if the test result corresponds to a test failure, obtain the reversal log of the metadata storage, restore the database to the pre-deployment state based on the reversal log, wherein the reversal log includes the original attributes and data values of the data tables in the database; stop the running process of the current application deployed in the target runtime environment, unload the target deployment package, and deploy the historical deployment package corresponding to the pre-deployment state to the target runtime environment; obtain the historical resource information corresponding to the historical deployment package, and replace the static resources and middleware configuration in the target runtime environment with the historical resource information.
[0090] In some embodiments, before storing each target deployment package to the artifact image library, the integration module 401 is specifically used to: obtain the name of the target runtime environment corresponding to the target deployment package, obtain the submission time of the corresponding target code, and obtain the project identifier corresponding to the target code; randomly generate a target random number of the target length; and concatenate the name, submission time, project identifier, and target random number to obtain the identifier corresponding to the target deployment package.
[0091] The modules in the aforementioned automatic code publishing device supporting different operating systems can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.
[0092] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 5As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores native libraries and other data corresponding to various operating environments. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements an automatic code deployment method that supports different operating systems.
[0093] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 6 As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements an automatic code deployment method that supports different operating systems. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.
[0094] Those skilled in the art will understand that Figure 5 or Figure 6The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.
[0095] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.
[0096] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in the above method embodiments.
[0097] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.
[0098] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.
[0099] Those skilled in the art will understand that 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 non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.
[0100] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.
[0101] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.
Claims
1. A method for automatically deploying code to different operating systems, characterized in that, The method includes: In response to the upload event of the target code, the system obtains target compilation scripts corresponding to multiple runtime environments through the target integration tool; compiles the target code into target bytecode files; runs each target compilation script to obtain matching target resource files; constructs target deployment packages matching each runtime environment based on the target bytecode files and each target resource file; and stores each target deployment package in the artifact image library. The target hardware architecture information of the target runtime environment is obtained through the target deployment tool, and the corresponding target deployment package is obtained from the artifact image library based on the target hardware architecture information; the configuration information of the target runtime environment is read, and the target deployment package is deployed to the target runtime environment according to the configuration information.
2. The method according to claim 1, characterized in that, The step of obtaining the target compilation scripts corresponding to multiple runtime environments includes: Obtain the hardware architecture corresponding to each of the aforementioned operating environments, and obtain the corresponding target compilation script based on the hardware architecture; The step of running each of the target compilation scripts to obtain the matching target resource files includes: Obtain the source code of the native library that matches the runtime environment; The target compilation script is run to compile the original library source code to obtain the corresponding target resource file; The step of constructing a target deployment package matching each runtime environment based on the target bytecode file and each target resource file includes: Construct a target image that matches the runtime environment; The corresponding target bytecode file and target resource file are packaged into the image to obtain the corresponding target deployment package.
3. The method according to claim 1, characterized in that, The step of reading the configuration information of the target runtime environment and deploying the target deployment package to the target runtime environment according to the configuration information includes: Read the environment requirement information from the target deployment package; If the server information of the target operating environment meets the environment requirements, the general configuration information in the target deployment package is replaced with the configuration information of the target operating environment, and each file in the target deployment package is deployed to the corresponding file location in the system directory of the target operating environment. The configuration information includes operating system parameters and database connection information.
4. The method according to claim 1, characterized in that, After deploying the target deployment package to the target runtime environment according to the configuration information, the process includes: Obtain the identifier of the target deployment package; Retrieve the test script corresponding to the identifier from the code repository; Start the target runtime environment in the target browser, execute the test script, obtain functional test data, and obtain the interface response data corresponding to the target business interface; The test results are determined based on the interface response data and functional test data.
5. The method according to claim 4, characterized in that, After determining the test results based on the interface response data and functional test data, the process includes: If the test result corresponds to a test failure, then a rollback process is executed; The rollback process includes: Obtain the reversal log of the metadata storage, and restore the database to the state before deployment based on the reversal log, wherein the reversal log includes the original attributes and data values of the data tables in the database; Stop the running process of the current application deployed in the target runtime environment, unload the target deployment package, and deploy the historical deployment package corresponding to the pre-deployment state to the target runtime environment; Obtain the historical resource information corresponding to the historical deployment package, and replace the static resources and middleware configurations in the target runtime environment with the historical resource information.
6. The method according to any one of claims 1-5, characterized in that, Before storing each of the target deployment packages to the artifact image repository, the method further includes: Obtain the name of the target runtime environment corresponding to the target deployment package, obtain the submission time of the corresponding target code, and obtain the project identifier corresponding to the target code; Generate a target random number of a specified number of bits. The identifier corresponding to the target deployment package is obtained by concatenating the name, the submission time, the project identifier, and the target random number.
7. An automatic code deployment device supporting different operating systems, characterized in that, The device includes: An integration module is used to respond to an upload event of target code, obtain target compilation scripts corresponding to multiple runtime environments; compile the target code into target bytecode files; run each target compilation script to obtain matching target resource files; construct target deployment packages matching each runtime environment based on the target bytecode files and each target resource file; and store each target deployment package in an artifact image library. The deployment module is used to obtain the target hardware architecture information of the target operating environment, obtain the corresponding target deployment package from the artifact image library based on the target hardware architecture information, read the configuration information of the target operating environment, and deploy the target deployment package to the target operating environment according to the configuration information.
8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.
9. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.