CN113094280B - Upgrade method, system, and readable storage medium - Google Patents

Upgrade method, system, and readable storage medium Download PDF

Info

Publication number
CN113094280B
CN113094280B CN202110460156.8A CN202110460156A CN113094280B CN 113094280 B CN113094280 B CN 113094280B CN 202110460156 A CN202110460156 A CN 202110460156A CN 113094280 B CN113094280 B CN 113094280B
Authority
CN
China
Prior art keywords
software
version
container
test
upgraded
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202110460156.8A
Other languages
Chinese (zh)
Other versions
CN113094280A (en
Inventor
曹先胜
金宏洲
程亮
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hangzhou Tiangu Information Technology Co ltd
Original Assignee
Hangzhou Tiangu Information Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hangzhou Tiangu Information Technology Co ltd filed Critical Hangzhou Tiangu Information Technology Co ltd
Priority to CN202110460156.8A priority Critical patent/CN113094280B/en
Publication of CN113094280A publication Critical patent/CN113094280A/en
Application granted granted Critical
Publication of CN113094280B publication Critical patent/CN113094280B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3672Test management
    • G06F11/3688Test management for test execution, e.g. scheduling of test suites
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/65Updates
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/70Software maintenance or management
    • G06F8/71Version control; Configuration management
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00Energy efficient computing, e.g. low power processors, power management or thermal management

Abstract

The invention discloses an upgrading method, a system and a readable storage medium, wherein the method comprises the following steps: acquiring dependent data of software to be upgraded, and acquiring first dependent data; performing container version upgrading on the software to be upgraded based on the target container to generate test software; obtaining the dependent data of the test software, and obtaining second dependent data; and comparing the first dependent data with the second dependent data, carrying out regression testing on the test software when the comparison is successful to obtain a test result, and releasing the test software when the test result is passed. According to the invention, the first dependency data and the second dependency data are compared, so that the dependency change condition of the software after the container is upgraded is known, the software capable of upgrading the container version is detected, the regression test is performed on the upgraded test software, and the logic correctness of the test software is checked, so that the quality of the software is ensured.

Description

Upgrade method, system, and readable storage medium
Technical Field
The invention relates to the technical field of software upgrading, in particular to a technology for upgrading a container version of software.
Background
In the software field, software refers to an executable binary package running business logic code, and a container refers to a piece of meta-software acting on the software, the software running in the container.
In the prior art, the software is often upgraded with emphasis on upgrading the version of the software, and when a new container is released, a developer is required to manually upgrade the container on which the software depends, so that the software runs on the new version container, and the corresponding function of the new version container is used.
Disclosure of Invention
Aiming at the defect that the prior art needs to manually upgrade the version of each software, the invention provides an upgrade technology which can automatically judge whether the version of the container can be upgraded or not, automatically upgrade and release the version of the container when the version of the container can be upgraded, and quicken the upgrade efficiency.
In order to solve the technical problems, the invention is solved by the following technical scheme:
an upgrade method comprising the steps of:
acquiring dependence data of software to be upgraded, namely, software to be upgraded needing to upgrade a container version, and acquiring first dependence data;
performing container version upgrading on the software to be upgraded based on the target container to generate test software;
obtaining the dependent data of the test software, and obtaining second dependent data;
and comparing the first dependent data with the second dependent data, carrying out regression testing on the test software when the comparison is successful to obtain a test result, and releasing the test software when the test result is passed.
And when the comparison fails or the test fails, the software to be upgraded is not matched with the target container, and the upgrade is abandoned at the moment, so that the normal operation of the software is prevented from being influenced.
The method is practically used for automatically screening the software capable of upgrading the container version and releasing the software after upgrading the container version.
As one possible implementation:
when the target container is monitored to carry out version change, pulling the service software released before the version change based on a preset pulling rule, and taking the obtained service software as the software to be upgraded.
As one possible implementation:
acquiring target software and extracting a container version of the target software;
and acquiring the version of the target container, and judging the target software as the software to be upgraded when the version of the target container is higher than the version of the container.
As one possible implementation:
and acquiring software to be distributed, and acquiring target software based on the software to be distributed.
As an implementation manner, the method for obtaining the dependency data of the software to be upgraded further includes a dependency change detection step after obtaining the first dependency data, and the specific steps are as follows:
acquiring historical test software corresponding to the software to be upgraded, and extracting dependency data of the historical test software when the container version of the historical test software is consistent with the version of the target container to acquire third dependency data;
judging whether the dependence of the software to be upgraded is changed or not based on the third dependence data and the first dependence data, and acquiring a test result of the historical test software when the dependence of the software to be upgraded is not changed;
when the test result of the history test software is that the test passes, the software to be upgraded carries out container version upgrading based on the target container, generates and distributes the upgrading software.
As one possible implementation:
the first dependency data comprises at least one first dependency component and a version number thereof;
the second dependency data includes at least one second dependency component and its version number;
when the first dependent component lacks a second dependent component corresponding to the first dependent component, or the version number of the first dependent component is larger than that of the corresponding second dependent component, the comparison is judged to be failed.
The invention also provides an upgrading system, which comprises:
the first acquisition module is used for acquiring the dependent data of the software to be upgraded and acquiring first dependent data;
the upgrading module is used for upgrading the version of the container of the software to be upgraded based on the target container to generate test software;
the second acquisition module is also used for acquiring the dependent data of the test software and acquiring second dependent data;
and the verification module is used for comparing the first dependent data with the second dependent data, carrying out regression testing on the test software when the comparison is successful, obtaining a test result, and releasing the test software when the test result is passed.
As an embodiment, the device further comprises a trigger module, which comprises a first trigger unit and a second trigger unit;
the first triggering unit is used for pulling the service software released before version change based on a preset pulling rule when the target container is monitored to carry out version change, and taking the obtained service software as the software to be upgraded;
the second triggering unit is used for acquiring target software, extracting a container version of the target software, and acquiring a version of a target container, and when the version of the target container is higher than the container version, judging that the target software is to be updated.
As one embodiment, the system further includes a change detection module including:
the extraction unit is used for acquiring historical test software corresponding to the software to be upgraded, and extracting the dependent data of the historical test software when the container version of the historical test software is consistent with the version of the target container so as to acquire third dependent data;
the detection unit is used for judging whether the dependence of the software to be upgraded is changed or not based on the third dependence data and the first dependence data, and acquiring a test result of the historical test software when the dependence of the software to be upgraded is not changed;
and the upgrading unit is used for upgrading the container version of the software to be upgraded based on the target container when the test result of the historical test software is that the test is passed, generating and releasing the upgraded software.
The invention also proposes a readable storage medium storing a computer program which, when executed by a processor, implements the steps of any of the methods described above.
The invention has the remarkable technical effects due to the adoption of the technical scheme:
according to the invention, the first dependency data and the second dependency data are compared, so that the dependency change condition of the software after the container is upgraded is known, the software capable of upgrading the container version is detected, the regression test is performed on the upgraded test software, and the logic correctness of the test software is checked, so that the quality of the software is ensured.
The invention can upgrade the version of the container for the service software released before the version upgrade of the target container, so that the version of the container can be timely upgraded to the latest version.
The invention can automatically and noninductively upgrade the container in the daily iterative process of the software, and has high upgrade efficiency.
The invention can utilize the test software and the corresponding test result as the reference basis in the next upgrading process, thereby avoiding repeated comparison and test and accelerating the upgrading speed.
Drawings
In order to more clearly illustrate the embodiments of the invention or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described, it being obvious that the drawings in the following description are only some embodiments of the invention, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
FIG. 1 is a schematic workflow diagram of the upgrade method disclosed in example 1;
FIG. 2 is a schematic workflow diagram of the upgrade method disclosed in example 2;
FIG. 3 is a schematic diagram of the modular connections of the upgrade system disclosed in embodiment 3;
FIG. 4 is a schematic diagram of the module connection of the upgrade system disclosed in embodiment 4.
Detailed Description
The present invention will be described in further detail with reference to the following examples, which are illustrative of the present invention and are not intended to limit the present invention thereto.
Embodiment 1, an upgrade method, comprising the steps of:
s100, acquiring dependent data of software to be upgraded, and acquiring first dependent data;
the software to be upgraded refers to business software which needs to be upgraded for the version of the container;
s200, upgrading a container version of software to be upgraded based on a target container to generate test software;
the target container refers to the latest version of the container;
s300, acquiring the dependent data of the test software, and acquiring second dependent data;
s400, comparing the first dependent data with the second dependent data, carrying out regression testing on the test software when the comparison is successful, obtaining a test result, and releasing the test software when the test result is passed.
And when the comparison failure or the test result in the step S400 is failed, directly releasing the software to be upgraded.
In the actual use process, the comparison data and the test data generated in the step S400 can be fed back to the corresponding developer, so that the developer can optimize the codes of the software based on the comparison data and the test data, and the codes are adapted to the target container.
Taking Java software as an example, the Java software is packaged by using a container so that the Java software runs in the container, and the container passes Maven
Managing component library dependencies, maven is an item management tool that contains a dependency management system (Dependency Management System). Java (Java)
The software is sensitive to the version of the container because a change in the version of the container means that all component libraries are dependent on the change in version, which can cause problems in the running of Java software. With the upgrade of the container version, a new function is added, and if Java software wants to use the new function, the container version on which the Java software depends must be upgraded;
upgrading the version of the container on which the software depends, not only modifying the version number of the container, but also modifying the version of the container, which leads to the version modification of the component library, thereby leading to Java
The components on which the software depends are indirectly upgraded, downgraded and even deleted, so that jar packet conflict occurs, and the corresponding Java software cannot be started or normally run.
Because jar cannot be predicted in advance
The package conflict, so after the new container version is released, the developer manually modifies the container version on which the software depends to obtain the updated software of the container version, and operates the updated software of the container version to detect if the jar exists
And when running normally, the software (software after the version of the container is updated) is released, otherwise, the original software (software after the version of the container is updated) is released, and a subsequent developer can optimally update the software according to the jar packet conflict condition, so that the software can run normally in the updated container frame.
As can be seen from the above, the scheme of manually upgrading the version of the container corresponding to the software requires the developer to detect the software one by one, and upgrade the version of the container for the software based on the detection result, which has low efficiency and high labor cost, and cannot quickly, stably and correctly promote the application of the new version of the container in the software.
According to the embodiment, the first dependent data and the second dependent data are compared, so that the dependence change condition of the software after the container is upgraded is known, and when the first dependent data are matched with the corresponding second dependent data, the container version is preliminarily determined to be upgraded; the embodiment also carries out regression testing on the software (namely testing software) after the version upgrading of the container, and checks the logic correctness of the software so as to ensure the quality of the software.
Further, the method for acquiring the software to be upgraded comprises the following two modes:
method 1: when the target container is monitored to carry out version change, pulling the service software released before the version change based on a preset pulling rule, and taking the obtained service software as the software to be upgraded, wherein the monitoring triggering part is shown in fig. 1.
The target container is the container with the latest version, the version of the target container changes, and the target container indicates that the container with the new version is released; monitoring version changes of the target container, which is the prior art, and a person skilled in the art can monitor the release of a new version of the container based on the prior published MQTT technology, so the release of the new version of the container is not described in detail;
those skilled in the art can set the pulling rule by themselves according to actual needs, such as pulling the 10 pieces of software recently released or pulling the software released in one day.
Method 2: acquiring software to be upgraded from target software:
extracting version data of the target software, wherein the version data comprises a container version, namely, a version of a container on which the target software depends;
and acquiring the version of the target container, namely the latest version of the container, when the version of the target container is higher than the version of the container, indicating that the version of the container on which the target software depends is intersected, and judging that the target software is to-be-upgraded software by upgrading the version of the container.
The target software may manually select the software to be upgraded or the software to be distributed for the user, and in this embodiment, the software to be distributed is used as the target software.
As shown in the dashed line part of fig. 1, when the service software is released based on the operation of the user, the upgrade method proposed in the embodiment is triggered, and at this time, the service software to be released is used as the target software to upgrade the container version according to the above steps.
In the actual use process, the service software to be released can be intercepted and released after the container version is updated, the service software to be released can be backed up to obtain corresponding backup software, the release operation is carried out on the original service software, the backup software is used as target software to carry out the container version update until the container version update is successfully released, and the original service software is updated by the test software of the updated container version, namely, when the container version update is carried out on the service software automatically and uninteresting, the release of the original service software is not influenced, and the influence on the release of the service software caused by overlong time (such as longer time for regression test) of the update is avoided.
In the actual use process, a person skilled in the art can select any one of the methods to obtain the software to be upgraded, or adopt the two methods to obtain the software to be upgraded at the same time.
In embodiment 2, a dependent change detection step is added to embodiment 1, that is, a step a dependent change detection step is added between step S100 and step 200 in embodiment 1, and the rest is the same as embodiment 1, and the step a dependent change detection step specifically includes:
a1, acquiring historical test software corresponding to software to be upgraded, and extracting dependency data of the historical test software when the container version of the historical test software is consistent with the version of a target container to obtain third dependency data;
the historical test software is the test software prior to the corresponding software.
The history test software can be empty, and when the history test software is empty, the inconsistent versions are judged;
when the versions are inconsistent, the dependent change detection step is skipped, step S200 is executed, and the upgrade is performed according to steps S200 to S400 in embodiment 1.
A2, judging whether the dependence of the software to be upgraded is changed or not based on the third dependence data and the first dependence data, and acquiring a test result of the historical test software when the dependence of the software to be upgraded is not changed;
and if not, executing the step S200, and upgrading according to the steps S200 to S400 in the embodiment 1.
A3, when the test result of the history test software is that the test passes, the software to be upgraded carries out container version upgrading based on the target container, and upgrade software is generated and released.
When the container version of the historical test software is consistent with the container version of the target container, and when the third dependent data is consistent with the first dependent data, the test result of the historical test software can be used as a basis for whether to upgrade the container version of the software to be upgraded, when the test result of the historical test software is that the test is passed, the test software corresponding to the software to be upgraded also passes, so that the container version of the software to be upgraded can be directly upgraded based on the target container, and similarly, when the test result of the historical test software is that the test is not passed, the software to be upgraded can also be directly judged, and the software to be upgraded is directly released.
According to the embodiment, through the design of the dependency change detection step, when the dependency corresponding to the software to be upgraded is unchanged and the software corresponding to the historical version of the software is executed in the steps from S200 to S400, the steps of dependency comparison, regression test and the like do not need to be repeated in the upgrading process, and the upgrading time is greatly shortened.
Further:
the first dependency data comprises at least one first dependency component and a version number thereof;
the second dependency data includes at least one second dependency component and its version number;
when the first dependent component lacks a second dependent component corresponding to the first dependent component, or the version number of the first dependent component is larger than that of the corresponding second dependent component, the comparison is judged to be failed.
In other words, in step S400, when the dependency data of the target container has component version missing, degrading, etc. in relation to the dependency data of the software to be upgraded, it is considered that if the version of the upgrade container will not be started or normally run, the comparison is determined to fail, otherwise, if the component version missing, degrading, etc. does not occur, the version upgrade can be considered, and the comparison is determined to be successful.
The comparison between the dependent components belongs to the prior art, and those skilled in the art know that the acquisition mode of the dependent components of the comparison can be easily implemented, so specific comparison steps are not described in detail in this embodiment.
In this embodiment, step S400 performs a regression test on the test software, and the specific steps for obtaining the test result are as follows:
regression testing is performed by using Jenkins (an existing open source automated server disclosed), and corresponding test data including coverage rate and success rate are obtained.
And acquiring a preset qualified coverage rate and a qualified success rate, and judging that the test passes when the coverage rate is greater than or equal to the qualified coverage rate and the success rate is greater than or equal to the qualified success rate, or else, judging that the test fails.
The upgrading method disclosed in this embodiment is described in detail with a specific case:
1. releasing a new version of the container:
after releasing the X2 version container, the container is the latest version container, so the container is taken as a target container;
at the moment, monitoring the change of the version of the target container, pulling 10 recently released different service software from the devots platform according to a preset pulling rule, and taking the obtained service software as the software to be upgraded;
the following container frames are sequentially updated for each piece of software to be updated, and the following container frames for upgrading one piece of software to be updated are taken as examples for carrying out detailed description:
and acquiring maven dependent data of the software to be upgraded, and acquiring corresponding first dependent data, wherein the maven dependent data is an array set of component versions.
And modifying the container version of the software to be upgraded, i.e. changing the container version of the software to be upgraded from X1 to X2 to obtain corresponding test software, so as to upgrade the container version of the software to be upgraded, automatically obtaining maven dependent data of the test software based on a dom operation mavenxml configuration file in the case, obtaining corresponding second dependent data, and obtaining the maven dependent data by executing mvn dependency list command in the case.
Comparing the two maven dependent data, namely comparing the first dependent data and the second dependent data, if the condition that the dependent component version is degraded or missing occurs, discarding the upgrade, otherwise, executing the regression test on the test software, and automatically submitting the test software to Jenkins to execute the regression test in the embodiment.
And obtaining corresponding coverage rate and qualification rate, and judging that the test passes when the coverage rate is greater than or equal to the qualification coverage rate and the success rate is greater than or equal to the qualification success rate, or else, judging that the test does not pass.
And when the test passes, issuing test software to the corresponding decops platform to finish upgrading the container frame.
In the case, the obtained test software is updated with historical test software, and the test result is recorded, so that the dependency change detection can be conveniently carried out when the corresponding service software is updated in the next container.
2. Release software:
referring to fig. 2, a solid line flow in fig. 2 represents a process in which software iterates in time order, and a dotted line flow represents a process in which a developer upgrades a container frame of the software when the developer issues a new version of the software.
The developer issues daily iterative software to the decops platform, and triggers the upgrading step proposed in the embodiment, for example, the upgrading can be performed according to the following steps:
executing the release step, backing up and releasing the software to be released to obtain backup software;
and obtaining the container version of the backup software and comparing the container version with the version of the target container, if the container version and the version of the target container are both X2, terminating the upgrading step, and referring to FIG. 2, continuing the upgrading step when the container version of the software A is X1 and smaller than the version X2 of the target container.
In practice the software has a software number, a software version and a container version; inquiring historical test software corresponding to the software based on the software number, and acquiring a container version of the historical test software;
when the container version of the history test software is inconsistent with the version of the target container, such as the software version V1 of the A software released by a developer, the history test software is absent, and a test result for reference is absent, so that the upgrade is performed according to the steps disclosed in the steps S200 to S400, and the test software when the test passes is released;
if the container version of the historical test software is X1 and is smaller than the version X2 of the target container, the reference cannot be provided for upgrading the container version of the backup software to X2, so that the test software with the container version of X2 needs to be generated, the dependency comparison and regression test are carried out again, and the generated test software is used as the historical test software to provide the reference for the next upgrading.
When the container version of the history test software is consistent with the version of the target container, the dependency data of the history test software and the backup container are obtained, the obtained dependency data are compared, when the dependency data of the two software are consistent, the dependency data are not changed, and the container version to be upgraded is consistent, so that the test result of the history test software can be used as a reference for the current upgrade, and when the test result of the history test is passed, the container version of the backup software can be directly modified to the version of the target container, and the upgrade of the container version is realized.
In fig. 2, when the developer issues the software with the software version V2 and the container version X1, the developer needs to perform container upgrade, and because the history test software (the software version V1 and the container version X2) has passed the test, the dependency data of the software version V1 and the software version V2 are not changed, and the test result of the history test software can be directly referred to, the container version of the software is modified, and the corresponding upgraded software is generated and then issued.
In summary, the upgrading method disclosed in the embodiment can automatically and noninductively upgrade the container in the daily iterative process of the software, has high upgrading efficiency, and can rapidly, stably and correctly promote the application of the container in the service code, namely, the latest technical result is rapidly applied to the production environment, so that the efficiency of a developer and the performance of an application program are improved;
the daily iteration of the software has a certain interval duration, when the version of the target container is changed, the service software just released can not be updated in a short time, so that the new version of the service software can not be timely applied to the target container.
Embodiment 3, an upgrade system, as shown in fig. 3, includes:
the first obtaining module 100 is configured to obtain dependency data of software to be upgraded, and obtain first dependency data;
the upgrade module 200 is configured to upgrade a version of a container of software to be upgraded based on a target container, and generate test software;
the second obtaining module 300 is further configured to obtain dependency data of the test software, and obtain second dependency data;
and the verification module 400 is configured to compare the first dependent data with the second dependent data, perform a regression test on the test software when the comparison is successful, obtain a test result, and release the test software when the test result is passed.
Further, the trigger module 500 includes a first trigger unit and a second trigger unit;
the first triggering unit is used for pulling the service software released before version change based on a preset pulling rule when the target container is monitored to carry out version change, and taking the obtained service software as the software to be upgraded;
the second triggering unit is used for acquiring target software, extracting a container version of the target software, and acquiring a version of a target container, and when the version of the target container is higher than the container version, judging that the target software is to be updated.
This embodiment is an embodiment of the apparatus corresponding to embodiment 1, and since it is substantially similar to embodiment 1, the description is relatively simple, and the relevant points will be described with reference to the section of embodiment 1.
In embodiment 4, as shown in fig. 4, a change detection module 600 is added to the embodiment 3, and the rest is the same as the embodiment 3;
the change detection module 600 includes:
the extraction unit is used for acquiring historical test software corresponding to the software to be upgraded, and extracting the dependent data of the historical test software when the container version of the historical test software is consistent with the version of the target container so as to acquire third dependent data;
the detection unit is used for judging whether the dependence of the software to be upgraded is changed or not based on the third dependence data and the first dependence data, and acquiring a test result of the historical test software when the dependence of the software to be upgraded is not changed;
and the upgrading unit is used for upgrading the container version of the software to be upgraded based on the target container when the test result of the historical test software is that the test is passed, generating and releasing the upgraded software.
This embodiment is an embodiment of the apparatus corresponding to embodiment 2, and since it is substantially similar to embodiment 1, the description is relatively simple, and the relevant points will be described with reference to the section of embodiment 2.
Embodiment 5, a readable storage medium storing a computer program which, when executed by a processor, performs the steps of the method of any one of embodiment 1 or embodiment 2.
In this specification, each embodiment is described in a progressive manner, and each embodiment is mainly described by differences from other embodiments, and identical and similar parts between the embodiments are all enough to be referred to each other.
It will be apparent to those skilled in the art that embodiments of the present invention may be provided as a method, apparatus, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, terminal devices (systems), and computer program products according to the invention. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
It should be noted that:
reference in the specification to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the invention. Thus, the appearances of the phrase "one embodiment" or "an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment.
While preferred embodiments of the present invention have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. It is therefore intended that the following claims be interpreted as including the preferred embodiments and all such alterations and modifications as fall within the scope of the invention.
In addition, it should be noted that, in the specific embodiments described in the present specification, names and the like of functional modules may be different. All equivalent or simple changes of the structure, characteristics and principle according to the inventive concept are included in the protection scope of the present invention. Those skilled in the art may make various modifications or additions to the described embodiments or substitutions in a similar manner without departing from the scope of the invention as defined in the accompanying claims.

Claims (7)

1. An upgrade method, characterized by comprising the steps of:
acquiring dependence data of software to be upgraded, and acquiring first dependence data, wherein the first dependence data comprises at least one first dependence component and a version number thereof;
performing dependency change detection on the first dependency data, wherein the dependency change detection comprises: acquiring historical test software corresponding to the software to be upgraded, and extracting dependency data of the historical test software when the container version of the historical test software is consistent with the version of the target container to acquire third dependency data; judging whether the dependence of the software to be upgraded is changed or not based on the third dependence data and the first dependence data, and acquiring a test result of the historical test software when the dependence of the software to be upgraded is not changed; when the test result of the history test software is that the test passes, the software to be upgraded upgrades the version of the container based on the target container, generates and distributes the upgrade software;
when the historical test software is empty or the container version of the historical test software is inconsistent with the version of the target container, upgrading the container version of the software to be upgraded based on the target container to generate test software;
obtaining the dependent data of the test software, and obtaining second dependent data, wherein the second dependent data comprises at least one second dependent component and a version number thereof;
comparing the first dependent data with the second dependent data, and judging that the comparison fails when the first dependent component lacks the corresponding second dependent component or the version number of the first dependent component is larger than that of the corresponding second dependent component;
and when the comparison is successful, carrying out regression testing on the test software to obtain a test result, and when the test result is passed, releasing the test software.
2. The upgrade method according to claim 1, wherein:
when the target container is monitored to carry out version change, pulling the service software released before the version change based on a preset pulling rule, and taking the obtained service software as the software to be upgraded.
3. The upgrade method according to claim 1, wherein:
acquiring target software and extracting a container version of the target software;
and acquiring the version of the target container, and judging the target software as the software to be upgraded when the version of the target container is higher than the version of the container.
4. The upgrade method according to claim 3, wherein the method of acquiring the target software is:
and acquiring software to be distributed, and acquiring target software based on the software to be distributed.
5. An upgrade system, comprising:
the first acquisition module is used for acquiring the dependent data of the software to be upgraded and acquiring first dependent data;
the detection module is used for performing dependency change detection on the first dependency data, wherein the dependency change detection comprises the following steps: acquiring historical test software corresponding to the software to be upgraded, and extracting dependency data of the historical test software when the container version of the historical test software is consistent with the version of the target container to acquire third dependency data; judging whether the dependence of the software to be upgraded is changed or not based on the third dependence data and the first dependence data, and acquiring a test result of the historical test software when the dependence of the software to be upgraded is not changed; when the test result of the history test software is that the test passes, the software to be upgraded upgrades the version of the container based on the target container, generates and distributes the upgrade software;
the upgrading module is used for upgrading the container version of the software to be upgraded based on the target container to generate the test software when the history test software is empty or the container version of the history test software is inconsistent with the version of the target container;
the second acquisition module is used for acquiring the dependent data of the test software and acquiring second dependent data, wherein the second dependent data comprises at least one second dependent component and a version number thereof;
and the verification module is used for comparing the first dependent data with the second dependent data, judging that the comparison fails when the second dependent component corresponding to the first dependent component is absent from the first dependent component or the version number of the first dependent component is larger than that of the corresponding second dependent component, carrying out regression test on the test software when the comparison is successful, obtaining a test result, and releasing the test software when the test result is passed.
6. The upgrade system of claim 5, further comprising a trigger module comprising a first trigger unit and a second trigger unit;
the first triggering unit is used for pulling the service software released before version change based on a preset pulling rule when the target container is monitored to carry out version change, and taking the obtained service software as the software to be upgraded;
the second triggering unit is used for acquiring target software, extracting a container version of the target software, and acquiring a version of a target container, and when the version of the target container is higher than the container version, judging that the target software is to be updated.
7. A readable storage medium storing a computer program, characterized in that the program when executed by a processor implements the steps of the method of any one of claims 1 to 4.
CN202110460156.8A 2021-04-27 2021-04-27 Upgrade method, system, and readable storage medium Active CN113094280B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110460156.8A CN113094280B (en) 2021-04-27 2021-04-27 Upgrade method, system, and readable storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110460156.8A CN113094280B (en) 2021-04-27 2021-04-27 Upgrade method, system, and readable storage medium

Publications (2)

Publication Number Publication Date
CN113094280A CN113094280A (en) 2021-07-09
CN113094280B true CN113094280B (en) 2023-07-25

Family

ID=76680299

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110460156.8A Active CN113094280B (en) 2021-04-27 2021-04-27 Upgrade method, system, and readable storage medium

Country Status (1)

Country Link
CN (1) CN113094280B (en)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107193615A (en) * 2017-06-29 2017-09-22 北京全域医疗技术有限公司 The renewal dispositions method and device of item code information
CN108037941A (en) * 2017-12-27 2018-05-15 掌阅科技股份有限公司 Application program update method, electronic equipment based on public plug-in unit, storage medium
CN109117143A (en) * 2018-06-11 2019-01-01 阿里巴巴集团控股有限公司 A kind of application dispositions method and system
CN111258614A (en) * 2020-05-06 2020-06-09 深圳开源互联网安全技术有限公司 Method, system, equipment and storage medium for detecting upgrade exception of project third-party library

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8813031B2 (en) * 2012-03-02 2014-08-19 Oracle International Corporation System and method for automatically resolving dependencies of Java Archive files for use with Maven
US9348582B2 (en) * 2014-02-13 2016-05-24 Linkedin Corporation Systems and methods for software dependency management
CN104461873B (en) * 2014-11-19 2018-03-23 青岛海信电器股份有限公司 The method of testing and device of a kind of application program
CN106155724B (en) * 2015-04-14 2020-03-13 阿里巴巴集团控股有限公司 Upgrading method and device
US11775273B2 (en) * 2016-06-08 2023-10-03 Veriversion Labs Ltd. Methods and systems of software testing, distribution, installation and deployment
CN110244967A (en) * 2019-06-18 2019-09-17 政采云有限公司 Method for updating edition and device
CN111158741B (en) * 2019-12-23 2024-04-12 北京五八信息技术有限公司 Method and device for monitoring dependency relationship change of service module on third party class library
CN111475422A (en) * 2020-06-28 2020-07-31 四川新网银行股份有限公司 Dependence checking method based on Jenkins tool

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107193615A (en) * 2017-06-29 2017-09-22 北京全域医疗技术有限公司 The renewal dispositions method and device of item code information
CN108037941A (en) * 2017-12-27 2018-05-15 掌阅科技股份有限公司 Application program update method, electronic equipment based on public plug-in unit, storage medium
CN109117143A (en) * 2018-06-11 2019-01-01 阿里巴巴集团控股有限公司 A kind of application dispositions method and system
CN111258614A (en) * 2020-05-06 2020-06-09 深圳开源互联网安全技术有限公司 Method, system, equipment and storage medium for detecting upgrade exception of project third-party library

Also Published As

Publication number Publication date
CN113094280A (en) 2021-07-09

Similar Documents

Publication Publication Date Title
US20030051235A1 (en) Method and apparatus for verifying and analyzing computer software installation
EP2888685A2 (en) Transaction-level health monitoring of online services
WO2018103216A1 (en) Method and apparatus for detecting memory leakages
US10579513B2 (en) Test run control method and apparatus
CN107357731A (en) Process produces monitoring, analysis and the processing method of core dump problems
CN110908674A (en) Automatic deployment method and device of application program
CN111258591A (en) Program deployment task execution method and device, computer equipment and storage medium
CN112306552A (en) System software version management method, device and storage medium
CN115202680A (en) System and method for automatically upgrading local client on line in remote manner
CN113094280B (en) Upgrade method, system, and readable storage medium
CN112905230A (en) Application program management method and device, terminal equipment and storage medium
CN110764785A (en) Power industry cloud platform tool chain based on open source assembly and cloud platform operation and maintenance method
CN114879977A (en) Application deployment method, device and storage medium
CN115168175A (en) Program error solving method, device, electronic equipment and storage medium
CN111752735A (en) SDK (software development kit) abnormity troubleshooting method and device and computer readable storage medium
CN112486511A (en) Method for generating operating system installation mirror image through web
CN113672269B (en) Data processing method, system, electronic device and program product
JP2010086108A (en) Test support system
CN114020301A (en) System upgrading device and system upgrading method
CN113703804A (en) System upgrading method, system, device and storage medium
CN114528071A (en) Application detection method, device, equipment and storage medium
CN113312079A (en) Hot patch upgrading method and device, electronic equipment and storage medium
CN116339788A (en) System updating method, device, equipment and storage medium of big data platform
CN114780133A (en) Data processing method, electronic device and computer program product
CN115658388A (en) Application program compatible mode operation method and device and computing equipment

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant