Version material management method and device for software privatization deployment
By introducing version material management methods into private software deployments, automating material archiving and intelligent material synthesis, the problem of material traceability is solved, deployment efficiency and the level of automation in operation and maintenance processes are improved, and material traceability and deployment reliability are ensured.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-19
- Publication Date
- 2026-04-07
AI Technical Summary
In private software deployment, existing technologies struggle to trace and reproduce the exact and complete set of materials that constitute a software version and their logical relationships, resulting in insufficient capabilities for accurate version auditing and rapid fault rollback in long-term operation and maintenance scenarios.
By responding to software version release events through the continuous delivery system, trigger signals are generated. The version material management engine obtains and packages materials into incremental packages, stores them in the material repository with identifiers, and merges them with the full material package of the previous version to generate the full package of the current version, thus achieving automated archiving and intelligent synthesis.
It enables complete archive management of version materials, improves deployment efficiency and automation of operation and maintenance processes, ensures material traceability and deployment reliability, and avoids the high error risk of manual material sorting.
Smart Images
Figure CN121807360A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of computer software technology, and in particular to a method and apparatus for version material management for proprietary software deployment. Background Technology
[0002] In current enterprise software practices, particularly in the private deployment of Software as a Service (SaaS), software releases and iterations have widely adopted a modern engineering system centered on CI / CD (Continuous Integration / Continuous Deployment) and guided by DevOps principles. These technologies have significantly improved the automation and agility from code submission to environment deployment. However, this advanced system primarily focuses on automating the "process" of building, testing, and deployment, generally neglecting the systematic management of the "deployment result"—that is, all the physical materials required to constitute a complete and working version. This results in the difficulty of tracing and reproducing the exact and complete set of materials and their logical relationships that constitute each historical version of the software, even though the deployment process is automated. This fundamentally weakens the ability to conduct accurate version audits, quickly roll back faults, and reproduce historical states in private environments and long-term operation and maintenance scenarios, becoming a prominent weakness in the full lifecycle management of enterprise software.
[0003] To address the aforementioned issues, existing technologies primarily employ the following solutions, but all have significant shortcomings. First, they rely on archiving plugins of general CI / CD tools or the general storage functions of artifact libraries. However, this does not resolve the logical dependencies and composition issues between materials. Second, they attempt to simulate material management by writing and maintaining complex custom operation and maintenance scripts that connect the APIs of different tools. This method is highly dependent on the skills of specific personnel, difficult to maintain and reuse, and the script logic itself can easily become a new source of errors. Third, they rely entirely on manual processes, with operation and maintenance personnel manually collecting and backing up materials after release. This approach is not only extremely inefficient but also completely fails to guarantee the mandatory and consistent archiving, making material loss or version history chaos a common occurrence.
[0004] Therefore, one or more methods are needed to solve the above problems.
[0005] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention
[0006] The purpose of this disclosure is to provide a method, apparatus, device, and medium for version material management in software privatization deployment, thereby overcoming, at least to some extent, one or more problems caused by limitations and defects in related technologies.
[0007] According to one aspect of this disclosure, a version material management method for software privatization deployment is provided, comprising: Once the target software version is released, the continuous delivery system responds to the release event of the target software version and generates a trigger signal. Based on the trigger signal, the version material management engine acquires and packages the online materials of the target software version into incremental material packages, and stores the incremental material packages in the material repository by associating them with the identifier of the target software version. The version material management engine retrieves the full material package of the previous version before the target version is released from the material repository, merges the full material package of the previous version with the incremental material package, generates the full material package of the current version, and stores the full material package of the current version in the material repository to complete the management of materials for the private deployment version of the software.
[0008] In one exemplary embodiment of this disclosure, responding to a release event of the target software version through a continuous delivery system includes: Respond to events that cause code to be merged into the release branch through a continuous delivery system; The continuous delivery system responds to events indicating the completion of the new application container image build. The continuous delivery system responds to commands manually triggered by operations and maintenance personnel through the management interface.
[0009] In one exemplary embodiment of this disclosure, the online material includes at least one of the following: Structured query language scripts used for database structure or data changes; The application's executable file or installation package; System or service configuration files; Command-line instructions used to update or configure middleware.
[0010] In one exemplary embodiment of this disclosure, the identifier includes a version number, a Git commit hash, a build pipeline ID, and a timestamp sequence.
[0011] In one exemplary embodiment of this disclosure, the type of the material storage warehouse includes: The material package is treated as a snapshot of a project version with a preset directory structure, and the project version snapshot is stored and managed by a Git repository. An object repository that stores and manages material packages as objects and identifies version information through the object's metadata; A professional artifacts library that utilizes binary file management and lifecycle management functions to store and manage material packages.
[0012] In one exemplary embodiment of this disclosure, merging the previous version full material package and the incremental material package includes: For the structured query language script, the structured query language scripts in the incremental material package are appended to the end of the sequence of structured query language scripts contained in the full material package of the previous version, in software version order. For the configuration file, a differential comparison and content fusion are performed between the configuration file in the previous version's full material package and the configuration file in the incremental material package.
[0013] In one exemplary embodiment of this disclosure, the merging process employs strategies including a content merging strategy, a reconstruction merging strategy, and a logical set strategy, wherein: The content merging strategy is to merge the incremental material package with the previous version's full material package to generate a physical current version's full material package. The refactoring strategy is based on the corresponding version status of the source code repository, and directly generates a complete material package containing all the contents up to the target software version as the full material package for the current version; The logical set strategy defines the current version full material package as a logical set, which consists of a baseline version material package and subsequent incremental material packages arranged in version order.
[0014] In one aspect of this disclosure, a version material management apparatus for proprietary software deployment is provided, comprising: The release response module is used to respond to the release event of the target software version through the continuous delivery system after the target software version is released online, and generate a trigger signal. The material package acquisition module is used to acquire and package the online materials of the target software version into incremental material packages according to the trigger signal, and store the incremental material packages in the material repository by associating them with the identifier of the target software version. The merge processing module is used to obtain the full material package of the previous version before the target version is released from the material repository using the version material management engine, merge the full material package of the previous version with the incremental material package to generate the full material package of the current version, and store the full material package of the current version in the material repository to complete the management of the materials of the software private deployment version.
[0015] In one aspect of this disclosure, an electronic device is provided, comprising: Processor; and A memory storing computer-readable instructions that, when executed by the processor, implement the method according to any one of the preceding claims.
[0016] In one aspect of this disclosure, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the method according to any one of the preceding claims.
[0017] Based on the embodiments of this disclosure, when a target software version is released online, the continuous delivery system responds to the release event of the target software version and generates a trigger signal. According to this signal, the version material management engine acquires and packages the release materials for the target software version into incremental material packages, and stores these incremental material packages in the material repository by associating them with the identifier of the target software version. Then, it acquires the full material package of the previous version before the target version's release, merges the two, generates the full material package of the current version, and stores the current version's full material package in the material repository, thus completing the management of version materials. Therefore, the embodiments of this disclosure provide a version material management solution for private software deployment, which can achieve automated archiving and intelligent synthesis of version materials, solving the core problems of discrete material management and difficult traceability in private deployment, and significantly improving deployment efficiency, system reliability, and the automation level of operation and maintenance processes.
[0018] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure.
[0019] The technical solutions of this disclosure will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description
[0020] The accompanying drawings, which form part of this specification, illustrate embodiments of this disclosure and, together with the description, serve to explain the principles of this disclosure.
[0021] This disclosure will become clearer with reference to the accompanying drawings and the following detailed description, wherein: Figure 1 A flowchart illustrating a version material management method for software privatization deployment, as an embodiment of the method disclosed herein; Figure 2 This is an overall architecture diagram of a version material management method for software privatization deployment, which is one embodiment of the method disclosed herein; Figure 3 This is a flowchart illustrating the decision logic of a version material management method for software privatization deployment, as an embodiment of the method disclosed herein. Figure 4This is a schematic diagram illustrating the operational mechanism of a version material management method for software privatization deployment, as an embodiment of the method disclosed herein. Figure 5 This is a structural block diagram of a version material management device for software privatization deployment, which is an embodiment of the method disclosed herein. Figure 6 This is a block diagram of an electronic device according to an embodiment of the method of this disclosure. Detailed Implementation
[0022] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the embodiments set forth herein; rather, they are provided so that this disclosure will be thorough and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted.
[0023] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this disclosure. However, those skilled in the art will recognize that the technical solutions of this disclosure can be practiced without one or more of the specific details described, or other methods, components, materials, apparatuses, steps, etc., can be employed. In other instances, well-known structures, methods, apparatuses, implementations, materials, or operations are not shown or described in detail to avoid obscuring various aspects of this disclosure.
[0024] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, or in one or more software-hardened modules, or in different network and / or processor devices and / or microcontroller devices.
[0025] In this disclosure, a version material management method for software privatization deployment is first provided; refer to Figure 1 As shown, this method for version material management for proprietary software deployment may include the following steps: Step S110: After the target software version is launched and released, the continuous delivery system responds to the release event of the target software version and generates a trigger signal. Step S120: According to the trigger signal, the version material management engine acquires and packages the online materials of the target software version into an incremental material package, and stores the incremental material package in the material repository by associating it with the identifier of the target software version. In step S130, the version material management engine obtains the full material package of the previous version before the target version is released from the material repository, merges the full material package of the previous version with the incremental material package to generate the full material package of the current version, and stores the full material package of the current version in the material repository to complete the management of the software private deployment version material. like Figure 3 As shown, this invention aims to solve the problems of scattered materials, difficulty in tracing, and low deployment efficiency in the version management of software private deployment. To this end, this invention provides a version material management method for software private deployment. This method integrates the automated archiving and intelligent synthesis of version materials into the software release process by constructing a mandatory management closed loop, thereby achieving complete archive management of version materials, significantly improving deployment efficiency, and end-to-end automation of the operation and maintenance process.
[0026] The implementation of the method relies on a collaborative system, such as Figure 2 As shown, it mainly includes the following core components: A self-developed DevOps platform (such as the Rock Platform or general DevOps tools): As a continuous delivery system, it is responsible for managing the entire software development lifecycle, providing governance from development and testing to the production environment, as well as software compilation and deployment capabilities. This platform integrates code quality and security vulnerability scanning during the compilation process. Furthermore, due to its self-developed nature, it can comprehensively control and provide structured, detailed deployment materials corresponding to each version release, laying a data foundation for subsequent material management.
[0027] Version Material Management Engine: As the core processing unit, it is responsible for responding to release events. After obtaining the release materials for the specified version from the self-developed DevOps platform, it performs operations such as packaging and associating identifiers, and executes key intelligent merging logic, such as combining incremental materials with historical full materials to form a new full package. This engine is responsible for saving all materials (including incremental and full packages) to the repository and providing full or incremental materials for the specified version to external users according to deployment requirements.
[0028] Material Repository: As a persistent storage layer, it is used to systematically store incremental and full material packages processed by the version material management engine, and to ensure the traceability and integrity of materials by leveraging its version control capabilities.
[0029] The specific steps of this version material management method for private software deployment are as follows: In step S110, as Figures 2 to 4As shown, once the target software version is successfully launched and released in the private environment, the self-developed DevOps platform will capture a series of events triggered by the successful launch and generate a trigger signal.
[0030] In some alternative embodiments of this example, the series of events refers to the release event of the target software version being successfully deployed in a private environment.
[0031] These can also be other release events, such as code merging events that pre-generate material packages when code is merged into a release branch; image build events triggered after a new application image is built in containerized deployments; and manually triggered events generated when operations personnel manually initiate a material backup process for a specific version through the management interface. All these triggered events, as long as their core purpose and effect is to drive the automated management of version materials, fall under the category of release events in this example.
[0032] In step S120, as Figures 2 to 4 As shown, in response to the trigger signal, the version material management engine starts working. This engine retrieves all available materials corresponding to the target software version (i.e., the new version planned for release) from the continuous delivery system. It then packages these available materials into an incremental material package (i.e., containing only the set of materials that have changed or been added in the current version compared to the previous version).
[0033] The "online materials" refer to the collection of entity files necessary to constitute a runnable software version, which includes at least one of the following types: structured query language scripts (i.e., SQL scripts) for database structure or data changes; executable files or installation packages for applications; configuration files for systems or services; and command-line instructions for updating or configuring middleware (such as Nginx, Redis, etc.).
[0034] Subsequently, the material management engine strongly associates this incremental material package with a unique identifier (such as semantic version number v2.1.0, Git commit hash, build pipeline ID, or sequential timestamp) and stores it in a material repository used to persistently store all versions of materials.
[0035] In a specific example, the specific implementation type of the material repository is interchangeable, primarily employing Git repositories, object repositories, and professional artifact repositories, wherein: Git repositories are repositories implemented using the Git distributed version control system. In this scenario, each package (whether incremental or full) is treated as a snapshot of a "project" version with a predefined directory structure. By performing Git commit operations, the entire package directory structure is stored in the repository, and Git's tagging feature is used to associate it with identifiers, thereby obtaining complete version history, change tracking, and branch management capabilities.
[0036] Object repository: For example, using object storage services such as Amazon S3 or MinIO. In this implementation, the material package is uploaded and stored as a whole "object," and its corresponding version information is recorded and identified through metadata set for that object.
[0037] Specialized artifact repositories: such as Nexus Repository or JFrog Artifactory. These systems are designed specifically for binary artifact management, with built-in powerful binary file management functions (such as storage, retrieval, and distribution) and lifecycle management functions (such as version policies and cleanup rules), enabling professional and standardized storage management of materials such as application packages.
[0038] In step S130, as Figures 2 to 4 As shown, the version material management engine further retrieves the full material package (i.e., a complete set containing all materials required for software operation up to the previous version) from the material repository, representing the previous version that was successfully released before the target software version. Subsequently, the version material management engine merges the newly generated incremental material package with the previous version's full material package to generate the current version's full material package representing the latest state. This package is also stored back in the material repository, thus completing the archiving management of all materials for a software version.
[0039] In a specific example, the merging process employs a differentiated strategy for different types of materials. For Structured Query Language (SQL) scripts, a sequential append strategy is used. Specifically, the SQL scripts in the current incremental material package are appended to the end of the SQL script sequence contained in the previous version's full material package, in version order. This ensures that database changes are executed in the correct historical order during deployment. For configuration files, an intelligent fusion strategy is used. That is, the configuration files in the two versions are compared differentially to identify newly added, modified, or deleted configuration items. Then, according to predefined rules (such as key-value pair overwriting, list merging, etc.), the changes are merged into the new configuration file to generate a configuration suitable for the current version.
[0040] In a specific example, the overall strategy employed in the merging process can also be diverse, with commonly used strategies including: Content merging strategy: Merge the incremental material package with the previous version's full material package in terms of physical content to generate a new, independent physical full material package file.
[0041] Refactoring and merging strategy: Instead of relying on historical full packages, the instruction build system directly compiles and packages from scratch based on the code state corresponding to the target software version in the source code repository, directly generating a brand new complete material package containing all content up to that version.
[0042] Logical Set Strategy: The full material package is not a single physically merged file, but is defined as a logical set. This logical set specifies a baseline version material package (usually the full package of a historical stable version) and all incremental material packages arranged sequentially from that baseline version to the current version. During deployment, the system achieves a "full" deployment effect by first deploying the baseline package and then automatically applying all incremental packages in sequence.
[0043] And other more complex strategies, such as three-party merging strategies and annotation-driven merging strategies.
[0044] The version material management solution provided in this disclosure establishes a complete and traceable version material archive by building material management into an indispensable automated closed loop in the version release process, providing a solid data foundation for version auditing and state reproduction. On this basis, the automatically synthesized latest full material package simplifies the deployment of a new environment into a "one-click" operation, revolutionarily improving deployment efficiency and reliability, and completely avoiding the high error risk of manually compiling incremental materials. At the same time, through deep integration with the self-developed operation and maintenance system, this method achieves end-to-end automation from deployment to archiving, forming a mandatory material backup mechanism, and significantly enhancing the overall control and internal control level of the operation and maintenance process.
[0045] It should be noted that although the steps of the method in this disclosure are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps.
[0046] Furthermore, in this example embodiment, a version material management device for software privatization deployment is also provided. (Refer to...) Figure 5 As shown, the version material management device 300 for software privatization deployment may include: a release response module 310, a material package acquisition module 320, and a merge processing module 330. Wherein: The release response module 310 is used to respond to the release event of the target software version through the continuous delivery system after the target software version is released online, and generate a trigger signal. The material package acquisition module 320 is used to acquire and package the online materials of the target software version into incremental material packages according to the trigger signal, and store the incremental material packages in the material storage repository by associating them with the identifier of the target software version. The merging processing module 330 is used to obtain the full material package of the previous version before the target version is released from the material repository using the version material management engine, merge the full material package of the previous version with the incremental material package to generate the full material package of the current version, and store the full material package of the current version in the material repository to complete the management of the materials of the software private deployment version.
[0047] The version material management device for software privatization deployment described in this disclosure corresponds to the version material management method for software privatization deployment described above, and the relevant content can be referred to each other, which will not be repeated here. The beneficial technical effects of the version material management device for software privatization deployment described in this disclosure can be found in the corresponding beneficial technical effects of the exemplary method section described above, which will not be repeated here.
[0048] It should be noted that although several modules or units of the version material management device 300 for software privatization deployment have been mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.
[0049] Below, for reference Figure 6 This describes an electronic device according to embodiments of the present disclosure. The electronic device may be either or both of a first device and a second device, or a standalone device independent of them, which may communicate with the first device and the second device to receive acquired input signals from them.
[0050] Figure 6 A block diagram of an electronic device according to an embodiment of the present disclosure is shown.
[0051] like Figure 6 As shown, the electronic device includes one or more processors and memory.
[0052] A processor can be a central processing unit (CPU) or other form of processing unit with data processing and / or instruction execution capabilities, and can control other components in an electronic device to perform desired functions.
[0053] The memory can store one or more computer program products, and the memory can include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, random access memory (RAM) and / or cache memory. The non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program products can be stored on the computer-readable storage medium, and the processor can run the computer program products to implement the methods of the various embodiments of this disclosure described above and / or other desired functions.
[0054] In one example, the electronic device may also include input devices and output devices, which are interconnected via a bus system and / or other forms of connection mechanism (not shown).
[0055] In addition, the input device may also include, for example, a keyboard, a mouse, etc.
[0056] This output device can output various information to the outside, including determined distance information, direction information, etc. The output device may include, for example, a display, a speaker, a printer, and a communication network and its connected remote output devices, etc.
[0057] Of course, for the sake of simplicity, Figure 6 Only some of the components of the electronic device relevant to this disclosure are shown, omitting components such as buses, input / output interfaces, etc. In addition, the electronic device may include any other suitable components depending on the specific application.
[0058] In addition to the methods and apparatus described above, embodiments of this disclosure may also be computer program products comprising computer program instructions that, when executed by a processor, cause the processor to perform the steps in the methods of various embodiments of this disclosure described in the foregoing portion of this specification.
[0059] The computer program product can be written in any combination of one or more programming languages to perform the operations of the embodiments of this disclosure. The programming languages include object-oriented programming languages such as Java and C++, as well as conventional procedural programming languages such as C or similar languages. The program code can be executed entirely on a user's computing device, partially on a user's computing device, as a standalone software package, partially on a user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.
[0060] Furthermore, embodiments of this disclosure may also be computer-readable storage media storing computer program instructions that, when executed by a processor, cause the processor to perform the steps in the methods of various embodiments of this disclosure described in the foregoing portion of this specification.
[0061] The computer-readable storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof.
[0062] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.
[0063] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For system embodiments, since they largely correspond to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.
[0064] The block diagrams of devices, apparatuses, devices, and systems disclosed herein are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as “comprising,” “including,” “having,” etc., are open-ended terms meaning “including but not limited to,” and are used interchangeably with them. The terms “or” and “and” as used herein refer to the terms “and / or,” and are used interchangeably with them unless the context clearly indicates otherwise. The term “such as” as used herein refers to the phrase “such as but not limited to,” and is used interchangeably with it.
[0065] The methods and apparatus of this disclosure may be implemented in many ways. For example, they may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order of steps for the methods is for illustrative purposes only, and the steps of the methods of this disclosure are not limited to the order specifically described above unless otherwise specifically stated. Furthermore, in some embodiments, this disclosure may also be implemented as a program recorded on a recording medium, the program including machine-readable instructions for implementing the methods according to this disclosure. Thus, this disclosure also covers recording media storing programs for performing the methods according to this disclosure.
[0066] It should also be noted that in the apparatus, devices, and methods of this disclosure, the components or steps can be disassembled and / or recombined. These disassemblies and / or recombinations should be considered as equivalent solutions to this disclosure.
[0067] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features disclosed herein.
[0068] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this disclosure to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations therein.
Claims
1. A method for version material management for proprietary software deployment, characterized in that, include: Once the target software version is released, the continuous delivery system responds to the release event of the target software version and generates a trigger signal. Based on the trigger signal, the version material management engine acquires and packages the online materials of the target software version into incremental material packages, and stores the incremental material packages in the material repository by associating them with the identifier of the target software version. The version material management engine retrieves the full material package of the previous version before the target version is released from the material repository, merges the full material package of the previous version with the incremental material package, generates the full material package of the current version, and stores the full material package of the current version in the material repository to complete the management of materials for the private deployment version of the software.
2. The method according to claim 1, characterized in that, Responding to the release event of the target software version through a continuous delivery system includes: Respond to events that cause code to be merged into the release branch through a continuous delivery system; The continuous delivery system responds to events indicating the completion of the new application container image build. The continuous delivery system responds to commands manually triggered by operations and maintenance personnel through the management interface.
3. The method according to claim 1, characterized in that, The materials uploaded include at least one of the following: Structured query language scripts used for database structure or data changes; The application's executable file or installation package; System or service configuration files; Command-line instructions used to update or configure middleware.
4. The method according to claim 1, characterized in that, The identifiers include version number, Git commit hash, build pipeline ID, and timestamp sequence.
5. The method according to claim 1, characterized in that, The types of material storage repositories include: The material package is treated as a snapshot of a project version with a preset directory structure, and the project version snapshot is stored and managed by a Git repository. An object repository that stores and manages material packages as objects and identifies version information through the object's metadata; A professional artifacts library that utilizes binary file management and lifecycle management functions to store and manage material packages.
6. The method according to claim 3, characterized in that, The process of merging the previous version's full material package with the incremental material package includes: For the structured query language script, the structured query language scripts in the incremental material package are appended to the end of the sequence of structured query language scripts contained in the full material package of the previous version, in software version order. For the configuration file, a differential comparison and content fusion are performed between the configuration file in the previous version's full material package and the configuration file in the incremental material package.
7. The method according to claim 1, characterized in that, The merging process employs strategies including content merging, restructuring merging, and logical set strategies, wherein: The content merging strategy is to merge the incremental material package with the previous version's full material package to generate a physical current version's full material package. The refactoring strategy is based on the corresponding version status of the source code repository, and directly generates a complete material package containing all the contents up to the target software version as the full material package for the current version; The logical set strategy defines the current version full material package as a logical set, which consists of a baseline version material package and subsequent incremental material packages arranged in version order.
8. A version material management device for proprietary software deployment, characterized in that, include: The release response module is used to respond to the release event of the target software version through the continuous delivery system after the target software version is released online, and generate a trigger signal. The material package acquisition module is used to acquire and package the online materials of the target software version into incremental material packages according to the trigger signal, and store the incremental material packages in the material repository by associating them with the identifier of the target software version. The merge processing module is used to obtain the full material package of the previous version before the target version is released from the material repository using the version material management engine, merge the full material package of the previous version with the incremental material package to generate the full material package of the current version, and store the full material package of the current version in the material repository to complete the management of the materials of the software private deployment version.
9. An electronic device, characterized in that, include: Memory, used to store computer program products; A processor for executing a computer program product stored in the memory, wherein when the computer program product is executed, it implements the method described in any one of claims 1-7.
10. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the method described in any one of claims 1-7.