Incremental upgrade package construction method and device, electronic equipment and storage medium

Abstract

The invention discloses a construction method and device of an incremental upgrade patch, electronic equipment and a storage medium, and relates to the technical field of computers, a file list and a change type are extracted from a code submission record, difference comparison is performed on files of an original version and a target version based on the information to generate code difference data, and the code difference data are sent to a server; therefore, the problem that the upgrade package contains a large number of redundant codes or key change contents are omitted and the upgrade accuracy and reliability are affected due to the fact that only a file name or a directory structure is used as a change judgment basis in an existing incremental upgrade method can be solved; the technical effects of improving the accuracy and reliability of incremental upgrading and reducing upgrading package redundancy are achieved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to methods, apparatus, electronic devices, and storage media for constructing incremental upgrade packages. Background Technology

[0002] In the field of software development and maintenance, version control and incremental upgrade technologies are core means to ensure the continuous iteration and stable operation of systems, and are widely used in scenarios such as cloud computing platforms, enterprise applications, mobile applications and open source collaborative projects.

[0003] Currently, incremental upgrade methods directly use filenames or directory structures as the basis for determining changes. When the granularity of the upgrade is small, it can lead to the upgrade package containing a large amount of redundant code or missing key changes, affecting the accuracy and reliability of the upgrade. Summary of the Invention

[0004] This application provides a method, apparatus, electronic device, and storage medium for constructing incremental upgrade packages, in order to at least solve the problem in related technologies where upgrade packages contain a large amount of redundant code or omit key changes, affecting the accuracy and reliability of the upgrade.

[0005] This application provides a method for constructing incremental upgrade packages, including:

[0006] Get code commit history;

[0007] Extract the file list and change types from the code commit history;

[0008] Based on the file list and its change types, the files in the original version and the target version are compared to generate code difference data.

[0009] Based on the code difference data, construct an incremental upgrade package.

[0010] Optionally, obtaining code commit records also includes:

[0011] The system receives the current version of the application system as input parameters through a preset script, and calls the version control system interface to obtain the tag number and commit identifier corresponding to that version.

[0012] Based on the tag number and the submission identifier, all submission records following the tag number are filtered out to obtain the code submission record.

[0013] Optionally, extracting the file list and change type from the code commit record further includes:

[0014] The file change type in each commit record of the code commit history is analyzed; wherein the file change type includes addition, modification, and deletion.

[0015] Based on a pre-defined mapping table, each file is associated with a corresponding service.

[0016] Optionally, the step of comparing the files in the original version and the target version based on the file list and their change types to generate code difference data further includes:

[0017] Based on the file list and its change types, the files in the original version and the target version are compared line by line to generate the content before modification, the content after modification, and the line number information of the difference lines;

[0018] The difference lines are stored in a structured manner according to the file dimension to obtain the code difference data.

[0019] Optionally, the method further includes:

[0020] The completed incremental upgrade package is digitally signed, and the validity of the digital signature is verified before deployment;

[0021] In response to the invalid digital signature, the deployment of the incremental upgrade package is rejected, and an exception log is logged and a rollback mechanism is triggered.

[0022] Optionally, the code commit history includes:

[0023] Add the complete content of a new file, modify the differences between files, and delete file identifiers.

[0024] Optionally, the method further includes:

[0025] The incremental upgrade package is tested using a preset number of test environments, and the results are used to determine whether the incremental upgrade package meets the upgrade requirements.

[0026] This application also provides an apparatus for building incremental upgrade packages, including:

[0027] The retrieval unit is used to retrieve code commit records;

[0028] The extraction unit is used to extract a list of files and change types from the code commit record;

[0029] The comparison unit is used to perform difference comparison on the files in the original version and the target version based on the file list and its change type, and generate code difference data;

[0030] A building unit is used to build an incremental upgrade package based on the code difference data.

[0031] Optionally, the acquisition unit is further configured to:

[0032] The system receives the current version of the application system as input parameters through a preset script, and calls the version control system interface to obtain the tag number and commit identifier corresponding to that version.

[0033] Based on the tag number and the submission identifier, all submission records following the tag number are filtered out to obtain the code submission record.

[0034] Optionally, the extraction unit is further configured to:

[0035] The file change type in each commit record of the code commit history is analyzed; wherein the file change type includes addition, modification, and deletion.

[0036] Based on a pre-defined mapping table, each file is associated with a corresponding service.

[0037] Optionally, the comparison unit is further configured to:

[0038] Based on the file list and its change types, the files in the original version and the target version are compared line by line to generate the content before modification, the content after modification, and the line number information of the difference lines;

[0039] The difference lines are stored in a structured manner according to the file dimension to obtain the code difference data.

[0040] Optionally, the device further includes:

[0041] A signature unit is used to digitally sign the completed incremental upgrade package and verify the validity of the digital signature before deployment.

[0042] The verification unit is used to refuse to deploy the incremental upgrade package in response to the invalid digital signature, and to record the exception log and trigger the rollback mechanism.

[0043] Optionally, the code commit history includes:

[0044] Add the complete content of a new file, modify the differences between files, and delete file identifiers.

[0045] Optionally, the device further includes:

[0046] The testing unit is used to test the incremental upgrade package based on a preset number of test environments, and determine whether the incremental upgrade package meets the upgrade requirements based on the test results.

[0047] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of constructing any of the above-described incremental upgrade packages when executing the computer program.

[0048] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described incremental upgrade package construction methods.

[0049] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of constructing any of the above-described incremental upgrade packages.

[0050] This application utilizes a method that extracts a file list and change types from code commit records. Based on this information, it compares the files in the original version with those in the target version to generate code difference data. Then, it constructs an incremental upgrade package based on this data. This method can more accurately capture code changes. Therefore, it can solve the problem in existing incremental upgrade methods where upgrade packages contain a large amount of redundant code or omit key changes because only filenames or directory structures are used as the basis for change judgment. This affects the accuracy and reliability of the upgrade, achieving the technical effect of improving the accuracy and reliability of incremental upgrades and reducing upgrade package redundancy. Attached Figure Description

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

[0052] Figure 1 This is a flowchart illustrating a method for constructing an incremental upgrade package according to an embodiment of the present disclosure.

[0053] Figure 2 This is a schematic diagram illustrating an incremental upgrade package creation process provided in an embodiment of this application;

[0054] Figure 3 A schematic diagram of a construction apparatus for an incremental upgrade package provided in an embodiment of this disclosure;

[0055] Figure 4 A schematic diagram of a construction apparatus for another incremental upgrade package provided in an embodiment of this disclosure. Detailed Implementation

[0056] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0057] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0058] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0059] The specific application environment architecture or specific hardware architecture on which the incremental upgrade package construction method depends is described here.

[0060] The embodiments of this application provide a method for constructing an incremental upgrade package. The method is described in detail below in conjunction with the execution flow of the incremental upgrade package construction method. Figure 1 This is a flowchart illustrating a method for constructing an incremental upgrade package provided in an embodiment of this disclosure.

[0061] like Figure 1 As shown, the method includes the following steps:

[0062] Step 101: Obtain code commit history;

[0063] In some embodiments, the version identifier of the software system is obtained by calling the interface or command-line tool provided by the version control system. The version identifier is typically a tag or commit identifier in Git, where a tag marks a release version, and a commit identifier uniquely identifies a specific code commit. In some implementations, the system may support user input of a version number or tag name as a parameter, which is automatically parsed and mapped to the corresponding commit identifier by a Python script.

[0064] Furthermore, the system uses commands to extract all commit records between the starting and target commit identifiers. These commit records include: commit identifier, commit timestamp, author information, commit comments, a list of changed files, and their change types.

[0065] The identifiers for the starting and target versions must conform to the format specifications of tags or commit identifiers in the version control system. The scope of commit record extraction is usually based on the linear history of commit identifiers, supporting cross-branch merge commit processing to ensure the integrity and continuity of change records.

[0066] Step 102: Extract the file list and change type from the code commit record;

[0067] In some embodiments, Git commands are invoked to retrieve all commit records within a specified version range, and the commit identifier for each commit is extracted. Subsequently, a list of files involved in that commit and their change types (add, modify, delete) are obtained. By parsing this information, the system can construct a structured change file table, containing fields such as file path, change type, commit time, and committer.

[0068] To achieve service-level upgrade control, the system also needs to establish a "file-service" mapping relationship. This mapping can be implemented through a predefined configuration file (such as YAML or JSON format), where each file path corresponds to its respective service module (such as service_name). In the automation script, Python's os.path module can be used for path matching, combined with regular expressions or prefix matching strategies, to bind the changed files to the services.

[0069] In some embodiments, key parameters include: version identifier (tag or commit identifier), file change status, file path, service name, etc.

[0070] Through automated parsing and mapping mechanisms, a precise correlation between code changes and service impacts is achieved, providing a data foundation for the construction and deployment of subsequent incremental upgrade packages. Compared to traditional manual comparison methods, this approach significantly improves processing efficiency and accuracy, reduces the risk of system instability due to misoperation, and is a core supporting technology for achieving an efficient, secure, and controllable software upgrade process.

[0071] Step 103: Based on the file list and its change types, perform a difference comparison on the files in the original version and the target version to generate code difference data;

[0072] In some embodiments, a list of file changes between the starting version and the target version is obtained through a version control system interface, including three types: additions, modifications, and deletions. For each changed file, the system will detect its complete code content in both the starting version and the target version, compare the file content of the two versions line by line, identify the specific insertion, deletion, and replacement operations, and record its line number, context information, and changed content in the file.

[0073] In some embodiments, the system can configure the number of context rows for difference comparison to enhance the readability and traceability of the difference data. Furthermore, to improve comparison efficiency, a caching mechanism can be used to store compared file versions, avoiding repeated fetching and calculation.

[0074] In some embodiments, the comparison results will be structured into a JSON or XML data structure, including metadata such as filename, change type, change line number, change content, commit time, and committer, to facilitate the generation of subsequent upgrade package build and deployment scripts. This structured data is not only used for building incremental packages, but also serves as the basis for version rollback, audit trails, and automated testing.

[0075] By performing precise line-by-line difference analysis, we ensure that the incremental upgrade package contains only the actual changed code content, significantly reducing the upgrade package size and improving transmission efficiency. At the same time, the output of structured data provides a standardized interface for subsequent automated deployment and version control, enhancing the maintainability and scalability of the system.

[0076] Step 104: Construct an incremental upgrade package based on the code difference data.

[0077] In some implementations, automated tools (such as Python scripts) are used to process commit records extracted from version control systems (such as Git), identify newly added, modified, and deleted files, and generate corresponding upgrade content based on their change types.

[0078] For newly added files, the system will fully read their contents in the target version and package them into the upgrade package according to the original file path structure, ensuring path consistency during deployment. For modified files, the system uses the Diff tool to compare the code differences between the starting version and the target version line by line, extracting only the modified lines and recording their line numbers in the file to support precise overwriting. Deleted files are marked by adding identifiers to the upgrade package to avoid accidental deletion during deployment.

[0079] Furthermore, the upgrade script will dynamically generate corresponding restart commands based on the service module to which the file belongs.

[0080] It enables the minimal construction of incremental upgrade packages and supports service-level hot updates, effectively solving the problems of resource waste and human error caused by traditional full upgrades, and improving the deployment efficiency and operation and maintenance automation level of software systems.

[0081] In some embodiments, obtaining code commit records further includes:

[0082] The system receives the current version of the application system as input parameters through a preset script, and calls the version control system interface to obtain the tag number and commit identifier corresponding to that version.

[0083] In some implementations, the current version number is received via command-line arguments or a configuration file and used as a query condition for the version control system. Python scripts typically use the gitpython library or call the Git command-line interface to interact with the Git repository and obtain version-related metadata.

[0084] By querying the tag object corresponding to a specified version number, the script obtains the commit identifier that the tag points to. For example, if the current version is v1.2.0, the script will execute the command `git rev-list -n 1v1.2.0` to obtain the commit hash value of the latest commit record for that version. Furthermore, the script can call the `git show` or `git log` commands to extract detailed information about the commit, including commit time, author, commit message, etc., to assist in subsequent version comparison and change analysis.

[0085] At the parameter level, version numbers typically follow semantic versioning specifications, with the format major version-minor version-revision number, such as 1.2.3. A one-to-one correspondence must be maintained between tags and commit identifiers to ensure the uniqueness and traceability of version identifiers. Furthermore, the script must support parameters such as multi-repository configuration, branch switching, and remote repository pulls to adapt to the needs of different development environments.

[0086] This provides precise version anchors for building subsequent incremental upgrade packages, ensuring that only changes after the target version are extracted, thereby significantly improving the efficiency and accuracy of upgrade package building and laying the foundation for efficient and secure software upgrades.

[0087] Based on the tag number and the submission identifier, all submission records following the tag number are filtered out to obtain the code submission record.

[0088] The commit history analysis based on the version control system aims to accurately identify all code change records since a certain version tag, providing an accurate data foundation for subsequent difference comparison and upgrade package generation.

[0089] In some implementations, automated commit filtering is achieved by calling the Git command-line interface or the Git Python library. The specific workflow is as follows: First, based on the version number entered by the user (e.g., v1.2.0), the Git command `git tag -l` is used to retrieve all version tags, and `git rev-list v1.2.0` is used to retrieve the commit ID corresponding to that version tag (e.g., abc1234). Then, `git log abc1234..HEAD --pretty=format:%H` is called to retrieve a list of commit IDs for all commit records from that commit ID to the current HEAD pointer. Further, `git show` is used to...<commit_id> Alternatively, use the `git diff-tree` command to extract file change information involved in each commit, including the paths of newly added, modified, or deleted files and the types of changes.

[0090] By employing a precise commit record filtering mechanism, we ensure that the incremental upgrade package only contains the code that has actually changed in the target version, avoiding the problems of redundant file inclusion or omission caused by manual judgment or logical errors in traditional methods. Furthermore, this step provides a structured and ordered commit dataset for subsequent difference comparison and packaging operations, forming the core foundation for an efficient, accurate, and traceable incremental upgrade process.

[0091] In some embodiments, extracting the file list and change type from the code commit record further includes:

[0092] The file change type in each commit record of the code commit history is analyzed; wherein the file change type includes addition, modification, and deletion.

[0093] In some implementations, all commit records within a specified version range are retrieved. Each commit record contains metadata such as commit ID, commit timestamp, committer information, commit comments, and a list of changed files. The file change type is inferred from the Git commit diff information, specifically including three types: A (Add), M (Modify), and D (Delete). These types are usually obtained using Git's `git diff-tree` or `git log --diff-filter=AMD` commands.

[0094] Furthermore, the system parses the full path of each file, including its relative path in the repository, and binds it to the change type to form a structured change log table.

[0095] In a Git environment, iterate through all commits from the base version tag to the target version commit ID, and extract the file change information involved in each commit.

[0096] Based on a pre-defined mapping table, each file is associated with a corresponding service.

[0097] In some implementations, the construction of the file-service mapping table relies on static code analysis tools or configuration file parsing modules. Static code analysis traverses the source code directory structure, identifies the classes, interfaces, methods defined in the files and their calling relationships, and extracts the mapping relationship between files and services by combining service registration information. Configuration file parsing, on the other hand, reads the service definition files, extracts metadata such as service names, component paths, and dependencies, and establishes the correspondence between files and services.

[0098] Furthermore, this mapping table is typically stored in key-value pairs, where the key is the file path (e.g., / src / main / java / com / example / service / UserService.java) and the value is the corresponding service name (e.g., UserService) or service group (e.g., auth-service). When building an incremental upgrade package, the system will quickly locate the affected services based on the list of changed files using the mapping table, thus only restarting the affected services in the deployment script and avoiding unnecessary restarts of unrelated services.

[0099] This invention achieves a precise correlation between code changes and service impacts, providing data support for the automated deployment of subsequent incremental upgrade packages and minimizing service restarts. This effectively reduces system downtime and improves operational efficiency, and is one of the core innovations of this invention in the automated and intelligent software upgrade process.

[0100] In some embodiments, the step of comparing the files in the original version and the target version based on the file list and their change types to generate code difference data further includes:

[0101] Based on the file list and its change types, the files in the original version and the target version are compared line by line to generate the content before modification, the content after modification, and the line number information of the difference lines;

[0102] The version control system retrieves the complete code content of each file in the starting and target versions. Specifically, Git commands can be invoked to obtain source code snapshots of the corresponding files in the starting and target versions, respectively. Then, the standard Diff tool is used to compare the file content of the two versions line by line. The Diff tool, based on the longest common subsequence algorithm, identifies newly added, modified, and deleted lines of code and outputs the differences.

[0103] Optionally, during the comparison process, the system can set comparison granularity parameters. For example, context=3 means retaining 3 lines of context before and after the lines of difference, which facilitates subsequent location and understanding of the change logic. In addition, comparison strategies that ignore whitespace characters, comment lines, or encoding format differences can be configured to improve the accuracy and practicality of the comparison.

[0104] Furthermore, the comparison results will be parsed and stored in a structured format, including the original line number of the differing lines, the content before modification, the content after modification, and the change type. This information will serve as the basis for file changes in the incremental upgrade package, ensuring that only necessary code changes are transmitted, thereby significantly reducing the size of the upgrade package and transmission overhead.

[0105] This invention achieves precise capture of code changes, providing a reliable data foundation for subsequent incremental packaging and deployment, and effectively improves the controllability and stability of the upgrade process. It is a key technical aspect of achieving efficient and secure software upgrades in this invention.

[0106] The difference lines are stored in a structured manner according to the file dimension to obtain the code difference data.

[0107] Each line of change information obtained during the code difference comparison phase is categorized and processed, including added lines, modified lines, and deleted lines. Each type of changed line must record its line number in the file, its content before / after the change, the change type identifier (e.g., "A" for added, "M" for modified, and "D" for deleted), and the corresponding commit record (commit identifier). Subsequently, the system categorizes these changed line information according to file paths, ensuring that the difference data for each file is stored independently, forming a structured difference data file. This file can be organized using standard formats such as JSON, YAML, or XML for easy parsing and processing by subsequent tools.

[0108] At the parameter level, the generation of difference data files must adhere to certain encoding standards and storage specifications. For example, file paths should use absolute paths or relative paths to the project root directory to ensure compatibility across different deployment environments; change lines should retain complete syntax and comment information to avoid upgrade failures due to content truncation; the encoding format for difference data files is recommended to be UTF-8, which supports a wide range of character sets and offers strong compatibility. Furthermore, the storage structure of difference data files can adopt a tree-like directory structure, consistent with the original project file structure, facilitating the construction and deployment of subsequent incremental upgrade packages.

[0109] At the application level, this step is widely applicable to software development projects based on version control systems such as Git, especially in continuous integration / continuous delivery processes, for automating the building of incremental upgrade packages. For example, in cloud-native applications and microservice architecture systems, after each version iteration, the system can automatically extract the difference lines and generate a structured difference file, allowing deployment tools to update only the changed parts during upgrades, thereby significantly reducing the size of the upgrade package and deployment time.

[0110] By storing differential rows in a structured format, the accuracy and efficiency of incremental upgrade package construction are improved, and the traceability and verifiability of the upgrade process are enhanced. In subsequent upgrade package construction phases, the system can accurately extract changed content based on this structured data, avoiding the packaging of redundant files, thereby optimizing resources and improving deployment efficiency. Furthermore, the structured differential data can also be used for advanced functions such as version rollback and change auditing, further enhancing the system's operational capabilities and security.

[0111] In some embodiments, the method further includes:

[0112] The completed incremental upgrade package is digitally signed, and the validity of the digital signature is verified before deployment;

[0113] In some embodiments, digital signatures typically employ asymmetric encryption algorithms, such as RSA or ECDSA (Elliptic Curve Digital Signature Algorithm). The signing process includes the following steps: First, a hash algorithm (such as SHA-256) is used to calculate the digest of the binary content of the upgrade package, generating a fixed-length hash value; then, the hash value is encrypted using a private key to generate a digital signature; finally, the signature result is packaged together with the upgrade package to form an upgrade package file containing the signature information. During the deployment phase, the system reads the signature information, decrypts the signature using the corresponding public key, and compares it with the hash value of the current upgrade package. If they match, the signature is valid; otherwise, it is determined to be an illegal or tampered upgrade package, and the system will refuse deployment.

[0114] The signature algorithm can be either RSA-2048 or ECDSA-256 to meet the requirements of different security levels. The signature verification process needs to be implemented in the deployment script, typically with a timeout mechanism (e.g., verification within 3 seconds) and support for multi-certificate chain verification to adapt to multi-level permission management in enterprise deployments.

[0115] By introducing a digital signature mechanism, unauthorized modification of upgrade packages during transmission or storage is effectively prevented, enhancing the credibility and security of the software upgrade process. Simultaneously, combined with access control policies, access control for upgrade operations can be implemented, ensuring that only authorized users or systems can execute the deployment, thus constructing a complete security loop for software upgrades.

[0116] In response to the invalid digital signature, the deployment of the incremental upgrade package is rejected, and an exception log is logged and a rollback mechanism is triggered.

[0117] The signature verification process employs asymmetric encryption algorithms (such as RSA or ECDSA). During the upgrade package construction phase, a trusted signing key digitally signs the upgrade package's metadata (such as version number, file hash value, change description, etc.), and the signature value, along with the public key, is embedded in the deployment script or configuration file. Upon receiving the upgrade package, the deployment system first extracts the signature information and verifies the signature using the pre-set public key. If verification fails (e.g., signature mismatch, invalid key, or unsupported signature algorithm), the system determines that the upgrade package's source is untrusted or its content has been tampered with, and will reject the deployment operation.

[0118] Furthermore, the system will record signature verification failures to the system log file via the logging module. Log content includes, but is not limited to: signature verification time, reason for failure, upgrade package version number, scope of submissions, and a list of involved files. The log format can conform to the ISO 8601 time standard and be stored in JSON or XML structure for easy auditing and troubleshooting.

[0119] Optionally, when signature verification fails, the system will automatically trigger a preset rollback mechanism. The rollback mechanism can be based on the version control system's tag information or snapshot mechanism to restore the system to the most recently successfully deployed version. The rollback operation can be implemented by a rollback function in the deployment script, supporting multi-level version rollback, and updating the system status flag after the rollback is complete to ensure system consistency.

[0120] In some embodiments, the code commit history includes:

[0121] Add the complete content of a new file, modify the differences between files, and delete file identifiers.

[0122] In some embodiments, the method further includes:

[0123] The incremental upgrade package is tested using a preset number of test environments, and the results are used to determine whether the incremental upgrade package meets the upgrade requirements.

[0124] Multiple representative test environments were selected to simulate the software upgrade process. The upgrade package was applied to different versions of the software system to check whether the upgrade could be completed smoothly, whether the upgraded software system could run normally, and whether all functions were implemented correctly. Simultaneously, the code and data of the software system before and after the upgrade were compared to ensure that the upgrade package accurately implemented the expected code changes. If problems were found during testing, the upgrade package was promptly adjusted and optimized, and re-verified and tested until the upgrade package met the requirements.

[0125] The following example illustrates a method for constructing an incremental upgrade package provided in this application; please refer to... Figure 2 , Figure 2 This is a schematic diagram illustrating an incremental upgrade package creation process provided in an embodiment of this application, such as... Figure 2 As shown, it includes:

[0126] Build an upgrade package creation tool and write a Python script tool that takes the current version of the application system as input and calls the Python script.

[0127] Obtain the commit ID of each code commit record using a Python script;

[0128] Based on the version number passed to the script, obtain the tag number and commitid corresponding to its last commit record;

[0129] Based on the commit ID corresponding to the tag number and the commit IDs of all commit records, filter out all commit records after the tag number;

[0130] Iterate through all commit records to obtain information about all modified files involved in each commit record, as well as the service corresponding to each file;

[0131] Generate incremental upgrade packages and upgrade scripts based on the file information, and add service restart operations to the upgrade scripts. The restart targets are the services obtained in the previous step, thus avoiding unnecessary service restarts.

[0132] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0133] Embodiments of this application also provide an apparatus for building incremental upgrade packages; please refer to [link to relevant documentation]. Figure 3 , Figure 3 This is a schematic diagram of the structure of an incremental upgrade package construction apparatus provided in an embodiment of this disclosure, as shown below. Figure 3 As shown, it includes:

[0134] Unit 21 is used to retrieve code commit records;

[0135] Extraction unit 22 is used to extract the file list and change type from the code commit record;

[0136] Comparison unit 23 is used to compare the differences between the files in the original version and the target version based on the file list and its change type, and generate code difference data;

[0137] Construction unit 24 is used to construct an incremental upgrade package based on the code difference data.

[0138] Furthermore, in one possible implementation of this disclosure, the acquisition unit 21 is further configured to:

[0139] The system receives the current version of the application system as input parameters through a preset script, and calls the version control system interface to obtain the tag number and commit identifier corresponding to that version.

[0140] Based on the tag number and the submission identifier, all submission records following the tag number are filtered out to obtain the code submission record.

[0141] Furthermore, in one possible implementation of this disclosure, the extraction unit 22 is further configured to:

[0142] The file change type in each commit record of the code commit history is analyzed; wherein the file change type includes addition, modification, and deletion.

[0143] Based on a pre-defined mapping table, each file is associated with a corresponding service.

[0144] Furthermore, in one possible implementation of this disclosure, the comparison unit 23 is further configured to:

[0145] Based on the file list and its change types, the files in the original version and the target version are compared line by line to generate the content before modification, the content after modification, and the line number information of the difference lines;

[0146] The difference lines are stored in a structured manner according to the file dimension to obtain the code difference data.

[0147] Furthermore, in one possible implementation of the embodiments of this disclosure, such as Figure 4 As shown, the device further includes:

[0148] The signature unit 25 is used to digitally sign the completed incremental upgrade package and verify the validity of the digital signature before deployment.

[0149] Verification unit 26 is used to refuse to deploy the incremental upgrade package in response to the invalid digital signature, and to record an exception log and trigger a rollback mechanism.

[0150] Furthermore, in one possible implementation of this disclosure, the code commit record includes:

[0151] Add the complete content of a new file, modify the differences between files, and delete file identifiers.

[0152] Furthermore, in one possible implementation of the embodiments of this disclosure, such as Figure 4 As shown, the device further includes:

[0153] Test unit 27 is used to test the incremental upgrade package based on a preset number of test environments, and determine whether the incremental upgrade package meets the upgrade requirements based on the test results.

[0154] For a description of the features in the embodiment corresponding to the incremental upgrade package construction apparatus, please refer to the relevant description in the embodiment corresponding to the incremental upgrade package construction method, which will not be repeated here.

[0155] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above embodiments of the incremental upgrade package construction method.

[0156] Embodiments of this application also provide a computer-readable storage medium storing a computer program configured to execute the steps in any of the above-described incremental upgrade package construction method embodiments at runtime.

[0157] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0158] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described incremental upgrade package construction method embodiments.

[0159] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described incremental upgrade package construction method embodiments.

[0160] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0161] The foregoing has provided a detailed description of the method, apparatus, electronic device, and storage medium for constructing an incremental upgrade package provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for constructing an incremental upgrade package, characterized in that, include: Get code commit history; Extract the file list and change types from the code commit history; Based on the file list and its change types, the files in the original version and the target version are compared to generate code difference data. Based on the code difference data, construct an incremental upgrade package.

2. The method for constructing an incremental upgrade package according to claim 1, characterized in that, The process of obtaining code commit records also includes: The system receives the current version of the application system as input parameters through a preset script, and calls the version control system interface to obtain the tag number and commit identifier corresponding to that version. Based on the tag number and the submission identifier, all submission records following the tag number are filtered out to obtain the code submission record.

3. The method for constructing an incremental upgrade package according to claim 1, characterized in that, The process of extracting the file list and change type from the code commit record also includes: The file change type in each commit record of the code commit history is analyzed; wherein the file change type includes addition, modification, and deletion. Based on a pre-defined mapping table, each file is associated with a corresponding service.

4. The method for constructing an incremental upgrade package according to claim 1, characterized in that, The step of comparing the files in the original version and the target version based on the file list and their change types to generate code difference data also includes: Based on the file list and its change types, the files in the original version and the target version are compared line by line to generate the content before modification, the content after modification, and the line number information of the difference lines; The difference lines are stored in a structured manner according to the file dimension to obtain the code difference data.

5. The method for constructing an incremental upgrade package according to claim 1, characterized in that, The method further includes: The completed incremental upgrade package is digitally signed, and the validity of the digital signature is verified before deployment; In response to the invalid digital signature, the deployment of the incremental upgrade package is rejected, and an exception log is logged and a rollback mechanism is triggered.

6. The method for constructing an incremental upgrade package according to claim 2, characterized in that, The code commit history includes: Add the complete content of a new file, modify the differences between files, and delete file identifiers.

7. The method for constructing an incremental upgrade package according to any one of claims 1-6, characterized in that, The method further includes: The incremental upgrade package is tested using a preset number of test environments, and the results are used to determine whether the incremental upgrade package meets the upgrade requirements.

8. An apparatus for constructing an incremental upgrade package, characterized in that, include: The retrieval unit is used to retrieve code commit records; The extraction unit is used to extract a list of files and change types from the code commit record; The comparison unit is used to perform difference comparison on the files in the original version and the target version based on the file list and its change type, and generate code difference data; A building unit is used to build an incremental upgrade package based on the code difference data.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the method for constructing an incremental upgrade package as described in any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, it implements the steps of the method for constructing an incremental upgrade package as described in any one of claims 1 to 7.

Images