CN100442230C - Method and system for software multi-version upgrade - Google Patents

Abstract

The present invention provides a method and system for upgrading software with multiple versions. The method includes establishing different designated directories for the upgrade tasks between different designated versions. The designated directories are used to store corresponding upgrade scripts. By activating and The public component upgrade script in the specified directory corresponding to the upgrade task between the specified versions completes the upgrade between the specified versions, and the public component upgrade script is used to store the execution commands needed to call the required upgrade script. The present invention efficiently, safely and quickly realizes the multi-version upgrade task. For example, it can conveniently complete the upgrade task from different old versions to the same new version. Quickly and safely complete the task of software multi-version upgrade, effectively solving the problem of unreasonable storage directory of upgrade scripts and confusing naming of version upgrade scripts; thus improving the work efficiency of multi-version upgrade and the maintainability of multi-version upgrade.

Description

Method and system for software multi-version upgrade

technical field

The invention relates to the field of software, in particular to a method and system for upgrading software versions.

Background technique

As a software product, every time the development reaches a certain stage and the specified functions can be performed, the current software needs to be solidified and released as a product in the form of a version. Then continue to add new functions on this basis, or modify the BUG in the existing software.

The content of the version includes compiled executable programs, compiled dynamic libraries, configuration files for controlling software functions, version descriptive documents, and so on.

During the use of software products, customers will put forward many new requirements for software products, or find many places that need to be modified. After the software product has been modified, a new version will appear to meet the requirements of the product. At this time, the issue of version upgrade must be considered.

The software product version upgrade can enhance the security of the software, improve the reliability and compatibility of the software product, and can also realize more functions to meet more demands.

In the process of upgrading software products, it is necessary to consider that a lot of useful data has been generated during the use of software products. Even after the upgrading of software products, more and better functions can be realized, these useful data should be kept intact. , to ensure that these useful data will not be overwritten. Otherwise, it will bring great inconvenience to the continued use of the software product. For example, in an old version of a software product, the user has set many configuration items, and the configuration file has been modified. If the configuration data is lost during the upgrade process, then The part modified by the user will be lost, which is not acceptable to the user.

The database will not be automatically upgraded. The way the new version stores data in the database may be different from the old version, and the format of the data table may have changed. If you simply overwrite the old version's executable files and library files Corresponding files, but the format of the database remains the same as the old version, then the problem of database reading and writing failures will occur.

Therefore, the version upgrade of software products must add the functions of the new version and modify the bugs of the old version on the basis of ensuring the user's existing labor results. For example, for the integrated management application platform iMAP, it is necessary to save the data in the existing database. and existing configuration files etc.

At present, there are two methods for upgrading the software version. The first method is: write individual upgrade programs for all the features that need to be upgraded in the version upgrade, and put these upgrade programs in a directory; then use the configuration file Control these upgrade programs; in the configuration file, each group of possible upgrades is listed, and which upgrade programs need to be called for this group of upgrades are indicated later; when the user upgrades, as long as the original version number and the new version number are provided, the upgrade script You can find the upgrade program that needs to be called from the configuration file, and then call the upgrade program. This method is only suitable for simple software upgrades. The larger the software scale and the more upgrade programs, the more difficult this method is to control. The second method is: it is necessary to write a special upgrade program for the upgrade of each version according to the characteristics of the new and old versions. There are no special regulations on the naming method of the upgrade program and the storage location of the upgrade program. The functions included in the script of the upgrade command include the upgrade of each module database format of the original software product (if the database format changes), the upgrade of each module configuration file (merging the configuration items modified by the user into the configuration file of the new version) )etc. The upgrade script is an executable file, which stores a set of commands that need to be executed when upgrading the old version to the new version.

The following will take the iMAP version upgrade process as an example to describe the current software product upgrade method 2 in detail:

As an integrated management application platform, iMAP is a distributed system developed based on CORBA standard. Its goal is to provide a centralized network management platform for products. iMAP includes multiple modules such as fault management, security management, topology management, and public components, and each module is developed and maintained by a dedicated person. Figure 1 describes the generation of iMAP versions: in the development process of iMAP, versions such as version1, version2, ..., version7 are generated in sequence, and the dots in Figure 1 represent the versions. iMAP uses professional version management software (Rational Clearcase) for version management. When the development of each version of iMAP is completed, use the version management software to mark a version label for all current codes of iMAP, such as version1, version2, etc. In the future, the corresponding iMAP version can be obtained from the version management software according to the tag name. When a certain iMAP version is submitted to the product, the product will put forward many new requirements for the version, or find some problems that need to be modified. In order not to interact with the main version being developed, developers will use version management software to create a branch on a certain version, and then develop and maintain it specifically for the needs of the product on this branch. Figure 2 describes the generation of iMAP version branches.

It can be seen from Figure 2 that with the continuous development and maintenance of iMAP, there will be more and more versions and branches of iMAP and more and more complex.

With the increasing number of iMAP users, the differences between the versions used by users are also increasing. This makes the relationship between the new version and the old version very complicated when the version is upgraded, and the workload of the version upgrade is very large. . For example, the version v7b1_version1 in Figure 2 is released, and the versions currently used by users may include version1, version2, version3, v2b1_version1, v2b1_version2, etc., then the new and old version upgrades that need to be considered may include: version1 => v7b1_version1, version2=>v7b1_version1, version3=>v7b1_version1, v2b1_version1=>v7b1_version1, v2b1_version2=>v7b1_version1, and so on.

The version upgrade must be based on the guarantee of the user's existing labor results. For iMAP, it is to add the functions of the new version and modify the BUG of the old version on the basis of the data in the existing database and the existing configuration files.

Therefore, R&D personnel need to write scripts for version upgrade commands based on the characteristics of the old and new versions. The scripts for upgrade commands include many functions. For iMAP, the upgrade scripts include at least the following functions: upgrade of each module database format (if the database If the format changes), the upgrade of each module configuration file is to incorporate the configuration items modified by the user into the new version of the configuration file.

Based on the above-mentioned existing technologies about software version upgrades, and still taking iMAP as an example, it can be concluded that the defects of existing technologies are as follows:

1. The storage directory of the upgrade script is unreasonable.

Assuming that the iMAP version is stored in the IMAP_ROOT directory, the storage directory of the upgrade script is the IMAP_ROOT/upgrade directory. When there are many upgraded versions, the number of upgrade script files in this directory also increases, reaching the point where it is hard to tell which upgrade script files should be used for which version.

2. The name of the version upgrade script is confusing.

iMAP does not have a unified script naming method. When writing upgrade scripts, the maintainers of each module name the upgrade scripts of their respective modules according to their own habits. When there are many versions to be upgraded, the number of upgrade script files also increases, and the names of the upgrade scripts appear to be varied and dazzling. After a long time, it is very difficult to maintain.

3. Too much repetitive work.

For the upgrades of different old and new versions, although the upgrade content is not exactly the same, there are some similarities. At present, a set of independent upgrade scripts is written for each upgrade of the old and new versions, resulting in a lot of duplication of labor.

In short, the existing version upgrade method for software products has a long development cycle, low software version upgrade efficiency, and is not easy to manage and maintain.

Contents of the invention

In view of the above-mentioned problems in the prior art, the object of the present invention is to provide a method and system for upgrading software with multiple versions, so as to improve the efficiency of software version upgrading and make the multi-version upgrading software easier to manage and maintain.

A method for upgrading software with multiple versions provided by the present invention includes:

a. Establish different designated directories for upgrade tasks between different designated versions, and the designated directories are used to store corresponding upgrade scripts;

b. Complete the upgrade between the specified versions by activating the public component upgrade script in the specified directory corresponding to the upgrade task between the specified versions. The public component upgrade script is used to store the execution commands required to call the required upgrade script.

The technical solutions of the following methods are optional technical solutions.

The specified directories upgraded from different old versions to the same new version have the same upper-level directory, and the upper-level directory is called the new version directory. Different new versions correspond to different new version directories, and different new version directories have the same upper-level directory.

Said step a also includes:

Store common resources common to each upgrade task in different upgrade scripts in a fixed directory;

And the step b further includes: the public component upgrade script is also used to store execution commands required for invoking required public resources.

The public resources include: general tools and general documents that are required in each upgrade process.

The general tools and general documents have fixed directories respectively.

The step a also includes: dividing the content of the upgrade script that executes the upgrade of the predetermined target module into predetermined target module upgrade scripts according to the predetermined target module; and the step b specifically includes:

The upgrade scripts of each predetermined target module are uniformly invoked by the public component upgrade scripts in the specified directory corresponding to the upgrade tasks between specified versions, so as to complete the upgrade between specified versions.

The present invention also provides a software multi-version upgrade system, the system includes: one or more designated directory units, the upgrade tasks between different designated versions correspond to a designated directory unit, each designated directory unit stores the corresponding upgrade script, The upgrade between the specified versions is completed by activating the public component upgrade script under the specified directory unit corresponding to the upgrade task between the specified versions. The public component upgrade script is used to store the execution commands needed to call the required upgrade script.

The system also includes a public resource storage unit, the public resource storage unit is used to store the public resources needed in each upgrade process, and is called by the public component upgrade script under the specified directory unit to complete the upgrade task; The above-mentioned public component upgrade script is also used to store a set of execution commands required for invoking the required public resources, so as to perform upgrade tasks between specified versions.

The public resource storage unit includes a general tool storage subunit and a general document storage subunit.

The upgrade scripts are divided into predetermined target module upgrade scripts according to the predetermined target modules, and are uniformly invoked by the public component upgrade scripts under the specified directory unit corresponding to the upgrade tasks between specified versions to execute the specified upgrade tasks.

From the description of the above technical solution, it can be seen that the present invention can efficiently, safely and quickly realize multi-version upgrade tasks by storing the upgrade scripts corresponding to upgrade tasks between different versions in different designated directories, such as conveniently completing The upgrade tasks from different old versions such as old version 1, old version 2, and old version 3 to the same new version can be completed efficiently, quickly and safely even in the case of upgrading from multiple old versions to multiple new versions. The version upgrade task effectively solves the problem of unreasonable storage directory of the upgrade script and confusing name of the version upgrade script; the present invention stores the public resources used by each upgrade task in a fixed directory, such as putting common tools or documents in In a fixed directory, the repeated development of the upgrade script is avoided, and the development workload of the upgrade script is reduced; by dividing the upgrade script into multiple predetermined target module upgrade scripts, when a certain target module is not involved in the upgrade task , then there is no need to maintain the corresponding target module upgrade script, which further reduces the development workload of the upgrade script, and makes the upgrade script easy to manage and maintain. Therefore, through the technical solution provided by the present invention, the objectives of improving the work efficiency of software multi-version upgrade and improving the maintainability of software multi-version upgrade are realized.

Description of drawings

Figure 1 shows the generation of iMAP version;

Figure 2 shows the generation of iMAP version branches;

Fig. 3 is the software multi-version upgrade flowchart of the embodiment of the present invention;

FIG. 4 is a directory structure of an iMAP multi-version upgrade according to an embodiment of the present invention.

Detailed ways

The present invention provides a convenient and flexible method to solve the above-mentioned problems in the prior art. When a software product has a new version that needs to be updated or upgraded, it only needs to activate the specified directory corresponding to the upgrade task between specified versions. The upgrade script can complete the upgrade between specified versions. Utilizing the technology provided by the invention makes it easier to realize the upgrade among different versions of the software product, thereby improving the working efficiency of the software product version upgrade.

The core of the present invention is to establish different designated directories for the upgrade tasks between different designated versions, and the designated directories are used to store the corresponding upgrade scripts. The script completes the upgrade between the specified versions.

In the present invention, the designated directories upgraded from different old versions to the same new version should be parallel directories of the same level, that is, the designated directories upgraded from different old versions to the same new version have the same upper-level directory. This upper-level directory is: a directory established for a new version, and directories of different new versions may have the same upper-level directory.

In order to avoid repeated development of upgrade scripts and improve the upgrade efficiency of software versions, the present invention can store common resources common to each upgrade task in different upgrade scripts in a fixed directory, and can also set upgrade scripts for each predetermined target module.

Specifically, the setting steps when the present invention realizes software product version upgrade include:

(1) Establish a designated directory for the upgrade task between every two designated versions of the software product, and the designated directory is used to store the upgrade script between the designated versions.

For ease of understanding, iMAP is still taken as an example for illustration. For iMAP, if there is an upgrade task of version1=>v7b1_version1, then a designated directory is established for this upgrade task, and if the above upgrade task does not exist, the designated directory does not need to be established.

(2) The upgrade scripts are divided according to the functional modules of the software product, that is, the predetermined target modules. In this way, the upgrade scripts of different modules can be independently maintained, and then, the common component upgrade scripts are used to uniformly organize and call them.

(3) Put the relatively unchanged public resources that need to be used in each upgrade task, such as general tools, general documents, etc., into a fixed directory, and the public component upgrade script is used to uniformly organize and call them. Common documents here include upgrade guidance documents, etc. Through the setting of this step, each upgrade script does not need to include the content of the public resource part, thereby avoiding the repeated development of the upgrade script and reducing the development workload of the upgrade script.

Still taking iMAP as an example, the software version upgrading method provided by the present invention will be described in conjunction with accompanying drawings 3 and 4 .

In Fig. 3, in step 31, a directory is established for each new version, and the new version directory includes a plurality of designated directories, and different designated directories are used to store upgrade scripts corresponding to upgrade tasks from different old versions to the new version. The invention should ensure that one upgrade task corresponds to one designated directory.

The directory structure of the software version upgrade is described below by taking FIG. 4 as an example.

In Fig. 4, all upgrade scripts are in an upgrade directory. Under the upgrade directory, a directory is established for each new version to store upgrade scripts, that is, upgrade scripts from current old versions to the new version. It should be noted that in Figure 4, a directory is only created for a new version, that is, the Version_NEW directory. If there are other updated versions, such as Version_NEW1 (new version 1), you can create a directory for this updated version in the upgrade directory. Create directory Version_NEW1.

When iMAP releases a new version Version_NEW, it is necessary to upgrade the current old version to Version_NEW. It is set that there are currently three places using iMAP, and the corresponding versions are Version_OLD_ONE (old version 1), Version_OLD_TWO (old version 2), Version_OLD_THREE (old Version 3), at this time, the iMAP version needs to be upgraded from Version_OLD_ONE, Version_OLD_TWO, Version_OLD_THREE to Version_NEW respectively. Like this, it is necessary to set up specified directories for Version_OLD_ONE=>Version_NEW, Version_OLD_TWO=>Version_NEW, Version_OLD_THREE=>Version_NEW respectively, that is, in the directory Three subdirectories are established under Version_NEW1: Version_OLD_ONE subdirectory, Version_OLD_TWO subdirectory, and Version_OLD_THREE subdirectory, so that an upgrade task corresponds to a specified directory.

Go to step 32: Divide the upgrade script according to the predetermined target modules, ie function modules, where the predetermined target modules are MOSve module, FaultSvc module, SecuritySvc module and so on.

In Fig. 4, the present invention divides all the upgrade scripts in the upgrade directory into the following three upgrade scripts according to the predetermined target modules: upgrade_MOSvc.sh, upgrade_FaultSvc.sh, upgrade_SecuritySvc.sh. These three upgrade scripts correspond to the MOSvc module, FaultSvc module, and SecuritySvc module respectively. The upgrade.sh in Figure 4 is used as the upgrade script of the public component, that is, the upgrade script of the platform module. If a new functional module is added to iMAP in the future, an upgrade script needs to be created for the newly added functional module in each designated directory.

If a certain function module does not need to be upgraded in an upgrade task, then the upgrade script of the function module can be empty, that is, no update and upgrade operation is performed on the function module. The development process of the upgrade version thus becomes clear and controllable.

Go to step 33: Store the relatively unchanged public resources that need to be used in each upgrade task, such as general tools, general documents, etc., in a fixed directory, so as to avoid the need to repeat common Resource authoring process.

The public resource directory in Figure 4 is: the Tools and Docs subdirectories established under the upgrade directory. The Tools subdirectory is used to store the general tools needed in each upgrade task, and the Docs subdirectory is used to store the General documentation needed. If there are public resources of other manifestations in the future, and it is not appropriate to place the public resources of this manifestation under the Tools and Docs directories, a new subdirectory can be created for the public resources of this manifestation under the upgrade directory.

Go to step 34: Store the upgrade scripts corresponding to different versions in the corresponding specified directory.

As shown in Figure 4, store the upgrade script corresponding to the upgrade task Version_OLD_ONE→Version_NEW: upgrade.sh, upgrade_MOSvc.sh, upgrade_FaultSvc.sh, upgrade_SecuritySvc.sh in the specified directory Version_OLD_ONE; save the upgrade script corresponding to the upgrade task Version_OLD_TWO→Version_NEW : upgrade.sh, upgrade_MOSvc.sh, upgrade_FaultSvc.sh, upgrade_SecuritySvc.sh are stored in the specified directory Version_OLD_TWO; upgrade scripts corresponding to the upgrade task Version_OLD_THREE→Version_NEW: upgrade.sh, upgrade_MOSvc.sh, upgrade_FaultSvc.sh, upgrade_SecuritySvc. Store in the specified directory Version_OLD_THREE.

Go to step 35: when upgrading the software version, activate the public component upgrade script corresponding to the upgrade task between the specified versions, and execute the upgrade task between the specified versions.

For example, when a user needs to upgrade iMAP from Version_OLD_TWO to Version_NEW, the user can directly find the upgrade.sh upgrade script in the corresponding specified directory upgrade/Version_NEW/Version_OLD_TWO/, activate upgrade.sh, and execute the upgrade from Version_OLD_TWO to Version_NEW The upgrade task of Version_NEW; use the same method to complete the upgrade task between any versions.

The present invention also provides a system for upgrading software with multiple versions. The system includes one or more specified directory units. The upgrade tasks between different specified versions correspond to one specified directory unit, and each specified directory unit stores the corresponding Upgrade script.

The upgrade scripts in the present invention can be divided into predetermined target module upgrade scripts according to the predetermined target modules, and are uniformly called by the public component upgrade scripts in the upgrade script units under the designated directory unit corresponding to the upgrade tasks between designated versions. The public component upgrade script stores a collection of execution commands required when calling the upgrade scripts of different predetermined target modules. Upgrade tasks between specified versions can be performed by activating the public self-upgrade script under the specified directory unit. Execute upgrade tasks between specified versions. The predetermined target module may be a functional module, specifically as described in the above method.

The system of the present invention also includes a public resource storage unit, which is used for storing public resources needed in each upgrading task. The public resources stored in the public resource storage unit are invoked by the public component upgrade script under the specified directory unit to complete the upgrade task. The public component upgrade script stores a collection of execution commands required for invoking different predetermined target module upgrade scripts and public resources. The upgrade task between specified versions can be performed by activating the public resource upgrade script under the specified directory unit. Specifically as described in the above method.

The above-mentioned public resource storage unit may include: a general tool storage subunit, a general document storage subunit, etc., to store general tools and general documents in the public resources, such as upgrade guidance documents, and the like. Specifically as described in the above method.

In the above-mentioned embodiment, the present invention takes iMAP as an example to describe the method and system for software multi-version upgrade, but the present invention is not limited to the software upgrade of iMAP, as long as the upgrade tasks between different specified versions are established separately The technical solutions for realizing multi-version upgrade of software in the specified directory of the specified directory are all within the scope of protection of the present invention.

The above is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art within the technical scope disclosed in the present invention can easily think of changes or Replacement should be covered within the protection scope of the present invention. Therefore, the protection scope of the present invention should be determined by the protection scope of the claims.

Claims (10)

1. A method for upgrading software with multiple versions, characterized in that the method comprises: a. Establish different designated directories for upgrade tasks between different designated versions, and the designated directories are used to store corresponding upgrade scripts; b. Complete the upgrade between the specified versions by activating the public component upgrade script in the specified directory corresponding to the upgrade task between the specified versions. The public component upgrade script is used to store the execution commands required to call the required upgrade script. 2. The method according to claim 1, characterized in that, each designated directory for upgrading from different old versions to the same new version has the same upper-level directory, and the upper-level directory is called the new version directory, and different new versions correspond to different new Version directory, different new version directories have the same parent directory. 3. The method according to claim 1, wherein said step a further comprises: Store common resources common to each upgrade task in different upgrade scripts in a fixed directory; And the step b also includes: The public component upgrade script is also used to store execution commands required for invoking required public resources. 4. The method according to claim 3, wherein the public resources include common tools and common documents that are required in every upgrading process. 5. The method according to claim 4, characterized in that fixed directories are respectively set up for the common tools and common documents. 6. The method according to claim 1 or 2 or 3 or 4 or 5, characterized in that said step a further comprises: dividing the content in the upgrade script for performing the upgrade of the predetermined target module into predetermined target modules according to the predetermined target modules Upgrade the script; and the step b specifically includes: The upgrade scripts of each predetermined target module are uniformly invoked by the public component upgrade scripts in the specified directory corresponding to the upgrade tasks between specified versions, so as to complete the upgrade between specified versions. 7. A software multi-version upgrade system, characterized in that the system includes: one or more designated directory units, the upgrade tasks between different designated versions correspond to a designated directory unit, and each designated directory unit stores the corresponding The upgrade script between the specified versions is completed by activating the public component upgrade script under the specified directory unit corresponding to the upgrade task between the specified versions. The public component upgrade script is used to store the execution required to call the required upgrade script Order. 8. The system according to claim 7, characterized in that the system further comprises a public resource storage unit, the public resource storage unit is used to store the public resources needed in each upgrade process, and the specified directory The public component upgrade script under the unit is invoked to complete the upgrade task; the public component upgrade script is also used to store a set of execution commands required when calling the required public resources, so as to perform the upgrade task between specified versions. 9. The system according to claim 8, wherein the public resource storage unit includes a general tool storage subunit and a general document storage subunit. 10. The system according to claim 7, wherein the upgrade script is divided into predetermined target module upgrade scripts according to the predetermined target modules, and the public components under the specified directory unit corresponding to the upgrade tasks between specified versions are upgraded The script is called uniformly to execute the specified upgrade task.

Images