Lightweight software upgrading and software rollback method and device

Abstract

The invention discloses a lightweight software upgrading and software rollback method, which comprises the following steps of: acquiring all to-be-upgraded original files between to-be-upgraded new-version software and old-version software of equipment and corresponding new-version files during each software upgrading; according to the lightweight software upgrading and software rollback method and device, the patch files are uploaded and verified, and the patch files which do not pass the verification are independently uploaded again, so that the uploading bandwidth requirement of the files under the condition of less program change is greatly reduced; according to the method, the problems that the performance of the embedded device is insufficient and breakpoint resume upgrading cannot be achieved in the upgrading process under a low-speed interface are solved, meanwhile, an automatic and reliable program version rollback method is provided, and the risk caused by manual intervention of version rollback is avoided; in the upgrade software and the backspace software, before each flexible connection file is replaced, the flexible connection file pointing to the corresponding version can be created according to the requirement of the version, so that the version switching can be quickly realized in a matched manner.

Description

Technical Field

[0001] The present invention belongs to the technical field of software upgrade and rollback, and in particular relates to a lightweight software upgrade and software rollback method. Background Art

[0002] Product feature upgrades and maintenance are used to enhance user experience, adapt to product technology developments, and maintain product competitiveness. Software upgrades can not only fix known vulnerabilities and issues, but also update program functionality and optimize performance. If an upgrade encounters problems or doesn't meet specific requirements, a software rollback can restore the system to a previously stable version, ensuring business continuity and stability, a crucial safeguard for the product.

[0003] In the prior art, there are the following problems:

[0004] (1) For program problem repairs or new functional modules, no matter how large the program code modification scale is, the upgrade methods such as uploading and decompressing the new version file through the serial port or USB interface or uploading the new version file to replace the old version file require a certain upload bandwidth. Specifically: when fixing some program bugs, the code modification amount is small, and in theory, only some files related to the program need to be replaced. However, the traditional upgrade method of replacing the old version with the new version of the program will result in low efficiency of program upgrades on low-speed interfaces such as serial ports. Moreover, it is theoretically feasible to only update some files related to the program, but the replacement and update management of the corresponding files after uploading requires additional management, and even requires human participation, but human participation will inevitably lead to version switching problems; or in some embedded devices working in special environments such as aerospace, the serial port or interface is generally only used for debugging and maintenance. In order to fix bugs, the method of upgrading by disassembling the product and then installing it is not very convenient in certain scenarios and will bring maintenance costs;

[0005] (2) When upgrading traditional software, if the program update fails due to abnormal power failure of the device, the old version of the entire software needs to be updated again, which is not convenient.

[0006] (3) In traditional software rollback, if the method of repeatedly injecting files to upgrade is adopted, it is both time-consuming and labor-intensive; using the old and new versions of software for backup will occupy storage space and there will inevitably be the risk of version confusion due to manual switching and recovery. Summary of the Invention

[0007] The purpose of the present invention is to solve the problems raised in the background technology and to propose a lightweight software upgrade and software rollback method.

[0008] To achieve the above object, the technical solution adopted by the present invention is:

[0009] The present invention proposes a lightweight software upgrade and software rollback method, comprising:

[0010] For each software upgrade, obtain all original files to be upgraded and the corresponding new version files between the new version of the device and the old version of the software, as well as the unchanged files of the old version of the software, build a patch file between the corresponding original files and the new version files, and generate the first MD5 hash for each patch file;

[0011] Upload the unmodified files and the original files to the main program area of the device, upload the patch files to the patch area of the device, and verify the patch files using the first MD5 value.

[0012] When all patch files have passed verification, the new version files corresponding to each patch file are generated in sequence by combining the patch files and the corresponding original files, and each new version file is stored in the new and old backup areas;

[0013] Migrate the original files corresponding to each new version file to the new and old backup areas in sequence. For each migrated original file, create a first soft link file in the program main area pointing to the new version file corresponding to the original file;

[0014] All the first soft link files and the unmodified files together constitute the new version of the software, and the new version of the software is verified. When the verification passes, the first soft link file in the new version of the software is replaced with the new version file pointed to to complete the software upgrade of the device;

[0015] For each software rollback, the software rollback version number is obtained, and each new version file to be rolled back in the program main area is migrated to the new and old backup areas. For each new version file migrated to the new and old backup areas, a second soft link file pointing to the rollback version number file corresponding to the new version file is recreated in the program main area;

[0016] All the second soft link files and the unmodified files together constitute the software with the fallback version number, and the software with the fallback version number is verified. When the verification passes, the second soft link file in the software with the fallback version number is replaced with the pointed fallback version file to complete the software rollback of the device.

[0017] Preferably, verifying each patch file by using the first MD5 value includes:

[0018] Generate a second MD5 value for each patch file uploaded to the patch area, and compare the first MD5 value of each patch file with the corresponding second MD5 value to see if they are the same. If they are the same, the corresponding patch file passes the verification.

[0019] Preferably, the lightweight software upgrade and software rollback method further comprises: adding each patch file to a description file, recording the number of patch files in the description file, and packaging the description file, the unmodified partial files, each original file, and all patch files into an upgrade package;

[0020] After uploading the upgrade package to the device, the patch files in the upgrade package are verified in sequence according to the number of patch files in the description file of the upgrade package. For patch files that fail the verification, the patch files are deleted from the patch area of the device and uploaded again.

[0021] Preferably, in the process of constructing the patch file between the corresponding original file and the new version file, the bsdiff algorithm is used to compare the corresponding original file and the new version file to obtain the difference between the original file and the new version file to form the patch file.

[0022] Preferably, when verifying the new version software or the software with a rolled-back version number, it is verified whether the version number of the new version software or the version number of the software with a rolled-back version number is correct.

[0023] A lightweight software upgrade and software rollback device is applied to the software upgrade of a device, and the lightweight software upgrade and software rollback device includes:

[0024] The first unit is used to obtain, for each software upgrade, all original files to be upgraded and corresponding new version files between the new version software to be upgraded and the old version software of the device, as well as the unchanged files of the old version software, construct a patch file between the corresponding original files and the new version files, and generate a first MD5 hash for each patch file;

[0025] The second unit is configured to upload the unmodified partial files and the original files to the main program area of the device, upload the patch files to the patch area of the device, and verify the patch files using the first MD5 value;

[0026] The third unit is used to combine the patch files and the corresponding original files to generate new version files corresponding to the patch files in sequence after all the patch files have passed the verification, and store the new version files in the new and old backup areas;

[0027] The fourth unit is used to migrate the original files corresponding to the new version files to the new and old backup areas in sequence, and for each migrated original file, create a first soft link file pointing to the new version file corresponding to the original file in the program main area;

[0028] The fifth unit is configured to combine all the first soft link files and the unmodified files into a new version of the software, verify the new version of the software, and replace the first soft link file in the new version of the software with the new version file pointed to by the new version of the software after the verification passes, thereby completing the software upgrade of the device;

[0029] The sixth unit is used to obtain the version number of the software rollback each time the software is rolled back, and migrate each new version file to be rolled back in the program main area to the new and old backup areas. For each new version file migrated to the new and old backup areas, a second soft link file pointing to the rollback version number file corresponding to the new version file is recreated in the program main area;

[0030] The seventh unit is used to combine all the second soft link files and the unmodified part of the files to form the software with the fallback version number, and verify the software with the fallback version number. When the verification is passed, the second soft link file in the software with the fallback version number is replaced with the pointed fallback version file to complete the software rollback of the device.

[0031] Preferably, the second unit verifies each patch file using the first MD5 value, and operates as follows:

[0032] The second unit generates a second MD5 value for each patch file uploaded to the patch area, and compares the first MD5 value of each patch file with the corresponding second MD5 value to see if they are the same. If they are the same, the corresponding patch file passes the verification.

[0033] Preferably, the second unit further adds each patch file to the description file, records the number of patch files in the description file, and packages the description file, the unmodified partial files, each original file, and all patch files into an upgrade package;

[0034] After uploading the upgrade package to the device, the patch files in the upgrade package are verified in sequence according to the number of patch files in the description file of the upgrade package. For patch files that fail the verification, the patch files are deleted from the patch area of the device and uploaded again.

[0035] Preferably, when the first unit constructs a patch file between the corresponding original file and the new version file, it uses a bsdiff algorithm to compare the corresponding original file and the new version file to obtain the difference between the original file and the new version file to form a patch file.

[0036] Preferably, when the fifth unit verifies the new version software or the seventh unit verifies the software with a rolled-back version number, it verifies whether the version number of the new version software or the version number of the software with a rolled-back version number is correct.

[0037] Compared with the prior art, the present invention has the following beneficial effects:

[0038] This lightweight software upgrade and software rollback method and device verifies each patch file uploaded and re-uploads patch files that fail verification. This greatly reduces the upload bandwidth requirements for files with minor program changes, solves the problems of insufficient performance and inability to resume upgrades when upgrading embedded devices on low-speed interfaces, and provides an automated and reliable program version rollback method, avoiding the risks of manual intervention in version rollbacks.

[0039] In the process of upgrading and rolling back software, before replacing the soft link files, you can create a soft link file pointing to the corresponding version according to the version requirements and delete the original soft link file to quickly achieve version switching. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 A software upgrade flow chart of the lightweight software upgrade and software rollback method of the present invention;

[0041] Figure 2 The software rollback flowchart of the lightweight software upgrade and software rollback method of the present invention. DETAILED DESCRIPTION

[0042] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0043] In one embodiment, Figure 1-Figure 2 As shown, a lightweight software upgrade and software rollback method is provided, including:

[0044] For each software upgrade:

[0045] All original files to be upgraded between the new version software to be upgraded and the old version software of the device (in this embodiment, the device is an embedded device) (wherein the old version software to be upgraded contains multiple original files, wherein the original files to be upgraded are the original files of the parts that need to be upgraded in the old version software) and the corresponding new version files (i.e., the new version files obtained after the original files are upgraded), as well as the unmodified files of the old version software (i.e., the parts of the files that do not need to be upgraded during the upgrade process of the old version software) are obtained, patch files are constructed between the corresponding original files and the new version files (i.e., patch files are constructed between the original files before the upgrade and the new version files after the upgrade, specifically using the bsdiff algorithm to compare the corresponding original files and the new version files to obtain the differences between the original files and the new version files to form patch files), and a first MD5 value is generated for each patch file; wherein the bsdiff algorithm is an algorithm for comparing and merging file differences, based on the incremental comparison principle, only comparing the newly added and modified parts between two version files, and the generated patch files are very small, with high space utilization. Program files, including binary files and configuration script files, all have regular content layouts. Applying this algorithm can improve the efficiency of patch package generation, reduce patch file size, and optimize file transmission bandwidth.

[0046] First of all, it should be noted that the device has a main program area, a patch area, and new and old backup areas;

[0047] Upload the unmodified files and the original files to the main program area of the device, upload the patch files to the patch area of the device, and verify the patch files using the first MD5 value.

[0048] wherein, each patch file is added to the description file, and the number of patch files is recorded in the description file; and the description file, the unmodified part of the files, each original file and all the patch files are packaged into an upgrade package;

[0049] After uploading the upgrade package to the device (that is, uploading the unmodified files and the original files to the device's main program area, and uploading the patch files to the device's patch area), the patch files in the upgrade package are verified in sequence according to the number of patch files in the upgrade package's description file. If the patch file fails the verification, it is deleted from the device's patch area and uploaded again.

[0050] The specific verification process is as follows: generate a second MD5 value for each patch file uploaded to the patch area, compare the first MD5 value of each patch file with the corresponding second MD5 value to see if they are the same. If they are the same, the corresponding patch file passes the verification.

[0051] When all patch files have passed verification, the new version files corresponding to each patch file are generated in sequence by combining the patch files and the corresponding original files, and each new version file is stored in the new and old backup areas;

[0052] Migrate the original files corresponding to each new version file to the new and old backup areas in sequence. For each migrated original file, create a first soft link file in the program main area pointing to the new version file corresponding to the original file;

[0053] All the first soft link files and the unmodified files together constitute the new version of the software, and the new version of the software is verified (that is, the version number is verified to be correct). When the verification passes, the first soft link file in the new version of the software is replaced with the new version file pointed to (and the first soft link file is deleted) to complete the software upgrade of the device;

[0054] For each software rollback:

[0055] Obtain the version number of the software rollback, and migrate each new version file to be rolled back in the program main area to the new and old backup areas. For each new version file migrated to the new and old backup areas, recreate a second soft link file in the program main area pointing to the rollback version number file corresponding to the new version file;

[0056] All the second soft link files and the unmodified files together constitute the software with the fallback version number, and the software with the fallback version number is verified (that is, whether the version number is correct). When the verification passes, the second soft link file in the software with the fallback version number is replaced with the pointed fallback version file (and the second soft link file is deleted) to complete the software rollback of the device.

[0057] Among them, in the process of upgrading and rolling back the software, before replacing the soft link files, you can create a soft link file pointing to the corresponding version according to the version requirements and delete the original soft link file to quickly achieve version switching.

[0058] In another embodiment, based on the previous embodiment, a lightweight software upgrade and software rollback device is further disclosed, which is applied to the software upgrade of a device. The lightweight software upgrade and software rollback device includes:

[0059] The first unit is used to obtain, for each software upgrade, all original files to be upgraded and corresponding new version files between the new version software to be upgraded and the old version software of the device, as well as the unchanged files of the old version software, construct a patch file between the corresponding original files and the new version files, and generate a first MD5 hash for each patch file;

[0060] The second unit is used to upload the unmodified files and the original files to the main program area of the device, upload the patch files to the patch area of the device (specifically, the upload can be performed through an interface such as the network or serial port), and verify the patch files using the first MD5 value;

[0061] The third unit is used to combine the patch files and the corresponding original files to generate new version files corresponding to the patch files in sequence after all the patch files have passed the verification, and store the new version files in the new and old backup areas;

[0062] The fourth unit is used to migrate the original files corresponding to the new version files to the new and old backup areas in sequence, and for each migrated original file, create a first soft link file pointing to the new version file corresponding to the original file in the program main area;

[0063] The fifth unit is configured to combine all the first soft link files and the unmodified files into a new version of the software, verify the new version of the software, and replace the first soft link file in the new version of the software with the new version file pointed to by the new version of the software after the verification passes, thereby completing the software upgrade of the device;

[0064] The sixth unit is used to obtain the version number of the software rollback each time the software is rolled back, and migrate each new version file to be rolled back in the program main area to the new and old backup areas. For each new version file migrated to the new and old backup areas, a second soft link file pointing to the rollback version number file corresponding to the new version file is recreated in the program main area;

[0065] The seventh unit is used to combine all the second soft link files and the unmodified part of the files to form the software with the fallback version number, and verify the software with the fallback version number. When the verification is passed, the second soft link file in the software with the fallback version number is replaced with the pointed fallback version file to complete the software rollback of the device.

[0066] Software updates can be executed automatically or triggered by commands: in the automatic upgrade execution mode, the software update will be automatically carried out after all patch files are verified; in the command-triggered upgrade mode, the update execution work needs to be initiated by the control terminal. In this working mode, the patch file verification result fed back by the second unit will be handed over to the control terminal command trigger for execution. This working mode is particularly used for breakpoint update software upgrades, or when the current embedded device is executing a task and cannot be interrupted.

[0067] In this embodiment, the second unit verifies each patch file using the first MD5 value, and operates as follows:

[0068] The second unit generates a second MD5 value for each patch file uploaded to the patch area, and compares the first MD5 value of each patch file with the corresponding second MD5 value to see if they are the same. If they are the same, the corresponding patch file passes the verification.

[0069] In this embodiment, the second unit further adds each patch file to the description file, records the number of patch files in the description file, and packages the description file, the unmodified partial files, each original file, and all patch files into an upgrade package;

[0070] After uploading the upgrade package to the device, the patch files in the upgrade package are verified in sequence according to the number of patch files in the description file of the upgrade package. For patch files that fail the verification, the patch files are deleted from the patch area of the device and uploaded again.

[0071] In this embodiment, when the first unit constructs a patch file between the corresponding original file and the new version file, it uses the bsdiff algorithm to compare the corresponding original file and the new version file, obtains the difference between the original file and the new version file, and forms a patch file.

[0072] In this embodiment, when the fifth unit verifies the new version software or the seventh unit verifies the software with a rolled-back version number, it verifies whether the version number of the new version software or the version number of the software with a rolled-back version number is correct.

[0073] The definition of a lightweight software upgrade and software rollback method is also applicable to the definition of a lightweight software upgrade and software rollback device, and will not be described repeatedly.

[0074] This lightweight software upgrade and software rollback method and device verifies the upload of each patch file and re-uploads the patch files that fail the verification separately, which greatly reduces the upload bandwidth requirements for files with fewer program changes, solves the problems of insufficient performance and inability to resume upgrades when upgrading embedded devices under low-speed interfaces, and at the same time provides an automated and reliable program version rollback method, avoiding the risks brought by human intervention in version rollback. In the process of upgrading and rolling back software, before replacing each soft link file, you can create a soft link file pointing to the corresponding version according to version requirements and delete the original soft link file to facilitate rapid version switching.

[0075] It should be understood that although Figure 1-Figure 2 The steps in the flowchart are shown in sequence as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified in this document, there is no strict order restriction for the execution of these steps, and these steps can be executed in other orders. In addition, Figure 1-Figure 2 At least part of the steps may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least part of the sub-steps or stages of other steps.

[0076] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that a person skilled in the art could make various modifications and improvements without departing from the spirit of the present application, all of which fall within the scope of protection of the present application. Therefore, the scope of protection of the present patent application shall be determined by the appended claims.

Claims

1. A lightweight software upgrade and software rollback method, characterized by: The lightweight software upgrade and software rollback method includes: For each software upgrade, obtain all original files to be upgraded and the corresponding new version files between the new version of the device and the old version of the software, as well as the unchanged files of the old version of the software, build a patch file between the corresponding original files and the new version files, and generate the first MD5 hash for each patch file; Upload the unmodified files and the original files to the main program area of the device, upload the patch files to the patch area of the device, and verify the patch files using the first MD5 value. When all patch files have passed verification, the new version files corresponding to each patch file are generated in sequence by combining the patch files and the corresponding original files, and each new version file is stored in the new and old backup areas; Migrate the original files corresponding to each new version file to the new and old backup areas in sequence. For each migrated original file, create a first soft link file in the program main area pointing to the new version file corresponding to the original file; All the first soft link files and the unmodified files together constitute the new version of the software, and the new version of the software is verified. When the verification passes, the first soft link file in the new version of the software is replaced with the new version file pointed to to complete the software upgrade of the device; For each software rollback, the software rollback version number is obtained, and each new version file to be rolled back in the program main area is migrated to the new and old backup areas. For each new version file migrated to the new and old backup areas, a second soft link file pointing to the rollback version number file corresponding to the new version file is recreated in the program main area; All the second soft link files and the unmodified files together constitute the software with the fallback version number, and the software with the fallback version number is verified. When the verification passes, the second soft link file in the software with the fallback version number is replaced with the pointed fallback version file to complete the software rollback of the device.

2. The lightweight software upgrade and software rollback method according to claim 1, characterized in that: Verifying each patch file using the first MD5 value includes: Generate a second MD5 value for each patch file uploaded to the patch area, and compare the first MD5 value of each patch file with the corresponding second MD5 value to see if they are the same. If they are the same, the corresponding patch file passes the verification.

3. The lightweight software upgrade and software rollback method according to claim 1, characterized in that: The lightweight software upgrade and software rollback method further includes: adding each patch file to a description file, recording the number of patch files in the description file, and packaging the description file, the unmodified portion of files, each original file, and all patch files into an upgrade package; After uploading the upgrade package to the device, the patch files in the upgrade package are verified in sequence according to the number of patch files in the description file of the upgrade package. For patch files that fail the verification, the patch files are deleted from the patch area of the device and uploaded again.

4. The lightweight software upgrade and software rollback method according to claim 1, wherein: In the process of constructing the patch file between the corresponding original file and the new version file, the bsdiff algorithm is used to compare the corresponding original file and the new version file to obtain the difference between the original file and the new version file to form the patch file.

5. The lightweight software upgrade and software rollback method according to claim 1, wherein: When verifying a new version of software or verifying a rolled-back version of software, verify whether the version number of the new version of software or the version number of the rolled-back version of software is correct.

6. A lightweight software upgrade and software rollback device, characterized by: The lightweight software upgrade and software rollback device is applied to the software upgrade of the device, and the lightweight software upgrade and software rollback device includes: The first unit is used to obtain, for each software upgrade, all original files to be upgraded and corresponding new version files between the new version software to be upgraded and the old version software of the device, as well as the unchanged files of the old version software, construct a patch file between the corresponding original files and the new version files, and generate a first MD5 hash for each patch file; The second unit is configured to upload the unmodified partial files and the original files to the main program area of the device, upload the patch files to the patch area of the device, and verify the patch files using the first MD5 value; The third unit is used to combine the patch files and the corresponding original files to generate new version files corresponding to the patch files in sequence after all the patch files have passed the verification, and store the new version files in the new and old backup areas; The fourth unit is used to migrate the original files corresponding to the new version files to the new and old backup areas in sequence, and for each migrated original file, create a first soft link file pointing to the new version file corresponding to the original file in the program main area; The fifth unit is configured to combine all the first soft link files and the unmodified files into a new version of the software, verify the new version of the software, and replace the first soft link file in the new version of the software with the new version file pointed to by the new version of the software after the verification passes, thereby completing the software upgrade of the device; The sixth unit is used to obtain the version number of the software rollback each time the software is rolled back, and migrate each new version file to be rolled back in the program main area to the new and old backup areas. For each new version file migrated to the new and old backup areas, a second soft link file pointing to the rollback version number file corresponding to the new version file is recreated in the program main area; The seventh unit is used to combine all the second soft link files and the unmodified part of the files to form the software with the fallback version number, and verify the software with the fallback version number. When the verification is passed, the second soft link file in the software with the fallback version number is replaced with the pointed fallback version file to complete the software rollback of the device.

7. The lightweight software upgrade and software rollback device according to claim 6, characterized in that: The second unit verifies each patch file using the first MD5 value, and operates as follows: The second unit generates a second MD5 value for each patch file uploaded to the patch area, and compares the first MD5 value of each patch file with the corresponding second MD5 value to see if they are the same. If they are the same, the corresponding patch file passes the verification.

8. The lightweight software upgrade and software rollback device according to claim 6, characterized in that: The second unit also adds each patch file to the description file, records the number of patch files in the description file, and packages the description file, the unmodified files, the original files, and all the patch files into an upgrade package; After uploading the upgrade package to the device, the patch files in the upgrade package are verified in sequence according to the number of patch files in the description file of the upgrade package. For patch files that fail the verification, the patch files are deleted from the patch area of the device and uploaded again.

9. The lightweight software upgrade and software rollback device according to claim 6, characterized in that: In the process of constructing the patch file between the corresponding original file and the new version file, the first unit uses the bsdiff algorithm to compare the corresponding original file and the new version file, obtains the difference between the original file and the new version file, and forms the patch file.

10. The lightweight software upgrade and software rollback device according to claim 6, characterized in that: When the fifth unit verifies the new version software or the seventh unit verifies the software with a rolled-back version number, it verifies whether the version number of the new version software or the version number of the software with a rolled-back version number is correct.

Images