CA2299850C - System and method for the management of computer software maintenance - Google Patents
System and method for the management of computer software maintenance Download PDFInfo
- Publication number
- CA2299850C CA2299850C CA 2299850 CA2299850A CA2299850C CA 2299850 C CA2299850 C CA 2299850C CA 2299850 CA2299850 CA 2299850 CA 2299850 A CA2299850 A CA 2299850A CA 2299850 C CA2299850 C CA 2299850C
- Authority
- CA
- Canada
- Prior art keywords
- service
- service bundle
- files
- bundle
- update
- 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.)
- Expired - Fee Related
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
- G06F11/1433—Saving, restoring, recovering or retrying at system level during software upgrading
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Quality & Reliability (AREA)
- Stored Programmes (AREA)
Abstract
The present invention is a system and method for managing at least one computer software update. The system and method comprise the steps of creating a service bundle comprising at least one software update; retrieving and storing the service bundle on a target system; and executing and tracking actions of the at least one software update on the target system.
Description
SYSTEM AND METHOD FOR THE MANAGEMENT
OF COMPUTER SOFTWARE MAINTENANCE
Field of the Invention The present invention relates in general to computer software maintenance and more specifically to a system and method for managing updates to be applied to computer software products.
Background of the Invention Software vendors constantly update their computer software products to maintain market and customer acceptance. The software updates may add new features to the computer software product, remove unnecessary filed and/or correct existing problems, commonly referred to as bugs. In some cases, software updates are released on a regular basis by vendors. As a result, keeping track of the software updates can be difficult. Also, many vendors release different versions of the same computer software product. Different software updates may therefore be required for these different releases.
Presently, software vendors typically use one software program to create, test and package software updates and a separate software program to release and install the software updates. Using separate programs to test and package software updates and to release and install software updates, results in software updates being released to consumers without validating the appropriateness of the software updates for individual consumers.
It is therefore an object of the present invention to provide a novel system and method for managing updates to be applied to computer software products.
Summary of the Invention In order to overcome the problems in the prior art, the system and method of the present invention provide a single software module or tool to manage the packaging and tracking of software updates for multiple versions of a software application on a service system and to manage the installation, removal and tracking of software updates for multiple versions of a software application on a target system to maintain system integrity.
By including tools to track the execution of software updates on the target system, the present invention is able to monitor the updates and provide assistance in case an error occurs during execution. If an error occurs, execution of the update may be restarted from the error point instead of from the beginning to provide automatic recovery from a failed update install.
Furthermore, the system and method of the present invention provide tools to verify that the software update is applicable to the target system in order to maintain system integrity.
According to one aspect of the invention, there is provided a method of updating computer software running on a target remote computer site using a system tool running on a vendor computer site that can be conditioned to a bundling mode and an install mode, said method comprising the steps of:
conditioning said system tool to said bundling mode and using said system tool to create an update for said computer software; and thereafter conditioning said system tool to said install mode and using said system tool to apply said update to the computer software running on said target remote computer site, during said applying said system tool performing rule-based checks to verify the integrity of said update and performing automatic failed service recovery when an installation error occurs thereby to inhibit the computer software running on said target remote computer site from being compromised by application of said update thereto.
According to another aspect of the invention there is provided a method of updating computer software running on a target remote computer site using a system tool running on a vendor computer site that can be conditioned to a bundling mode and an install mode, said method comprising the steps of conditioning said system tool to said bundling mode and using said system tool to create a service bundle for said computer software, said service bundle including one or more update files and control files associated with said update files that identify target directories for said update files and the location of archived files stored in a service history database maintained by said system tool; and thereafter conditioning said system tool to said install mode and using said system tool to apply said service bundle to the computer software running on said target remote computer site, during said applying said system tool performing rule-based checks to verify the integrity of said service bundle and performing automatic failed service recovery when an event failure occurs during installation of said service bundle thereby to inhibit the computer software running on said target remote computer site from being compromised by application of said service bundle thereto.
In yet another aspect of the invention there is provided a computer readable medium having a computer program embodied thereon for updating computer software running on a target remote computer site, said computer program for running on a vendor computer site and being conditionable to a bundling mode and an install mode, said computer program including:
computer program code for creating an update for said computer software when said computer program is conditioned to said bundling mode; and computer program code for applying said update to the computer software running on said target remote computer site when said computer program is conditioned to said install mode, said computer program code for applying performing rule-based checks to verify the integrity of said update and performing automatic failed service recovery when an installation error occurs thereby to inhibit the computer software running on said target remote computer site from being compromised by application of said update thereto.
In still yet another aspect of the present invention, there is provided a computer readable medium having a computer program embodied thereon for updating computer software running on a target remote computer site, said computer program for running on a vendor computer site and being conditionable to a bundling mode and an install mode, said computer program including:
computer program code for creating a service bundle for said computer software when said computer program is conditioned to said bundling mode, said service bundle including one or more update files and control files associated with said update files that identify target directories for said update files and the location of archived files stored in a service history database maintained by said system tool; and computer program code for applying said service bundle to the computer software running on said target remote computer site when said computer program is conditioned to said install mode, said computer program code for applying performing rule-based checks to verify the integrity of said service bundle and performing automatic failed service recovery when an event failure occurs during installation of said service bundle thereby to inhibit the computer software running on said target remote computer site from being compromised by application of said service bundle thereto.
Brief Description of the Detailed Drawings A preferred embodiment of the present invention will now be described more fully with reference to the accompanying drawings, in which like numerals denote like parts throughout, and in which:
Figure 1 is a schematic diagram of a service bundle;
Figure 2 is a flowchart showing a service bundle creation process;
Figure 3 is a flowchart showing a service bundle installation process;
Figure 4 is a flowchart showing a service bundle removal process;
Figure S is a flowchart showing a self service file process;
Figure 6 is a flowchart showing a basic service rules check process;
Figure 7 is a flowchart showing a service file relationship check process;
Figure 8 is a flowchart showing a loadtime failure recovery process;
Figure 9 is a flowchart showing a recover on pre-service command failure process;
Figure 10 is a flowchart showing a recover on post service command failure process;
Figure 11 is a flowchart showing a recover on failed file copy process;
and Figure 12 is a flowchart showing a recover on failed database transaction process.
Detailed Description of the Preferred Embodiment S ~ As mentioned above, software vendors typically release software updates to customers on a continuing basis to enhance computer software products.
Generally, the software updates correct existing and/or foreseeable bugs, enhance applications and/or add new features. To manage computer software product updates in this environment, the present invention provides a system and method for packaging, tracking, installing and removing computer software updates for a computer software product having multiple versions. A preferred embodiment of the present invention will now be described.
The present invention provides a service system tool to allow computer software product updates or "service items" to be created, tracked and packaged on a vendor's computer site and to allow computer software products on customer computer sites to be tracked and updated with appropriate service items. The service system tool is operable in a bundler mode and in a tool mode. Specifically, the service system tool is conditioned to the bundler mode on the vendor's computer site when it is desired to create, manage and package service items for installation on target customers' computer sites. The service system tool is conditioned to the tool mode when it is desired to install and track the service items on target customers' computer sites. The service system tool also includes a command line interface to record service item installations in a service history database. In the tool mode, the service history database includes computer product version information and applied service item information. In the bundler mode, the service history database tracks service items available to versions of the computer software products.
In the bundler mode, the service system tool creates, manages and packages service items into service bundles. Turning to Figure 1, a schematic representation of a service bundle is shown and is generally identified by reference numeral 1. As can be seen, service bundle 1 includes a service type information section 3, which identifies the type of software update, or updates in the service items associated with the service bundle. The service bundle 1 also includes a service levellhot fix information section 4. Section 4 includes information concerning the service status of the service bundle i.e. Beta version, Alpha version or released version. Section 4 also includes information relating to the smallest service item within the service bundle.
The service bundle 1 also includes a files/updates section 5 storing service item files making up the service item. A service control files section 6 stores control files associated with the service items files. The service control files are used to control the operation of the various service types of the service bundle.
The name of each service control file is based on the service level and a description of the service item file. In the present embodiment, the service control files can include service map files, service command files, service history database entry files and service fix list files.
Service map files list the service item files included in the service bundle 1 and the target directory for each service item file. During installation of the software update, outdated service item files, from previous updates, are archived and replaced by the update files. The service map files store the locations of the archived files in case the archived files have to be restored due to an error during the installation of the software update. This property is intended to maintain system integrity.
The service command files aid in the parsing of contents of service commands and for executing service commands. Examples of service commands include installation and removal programs used in connection with the service bundle.
The service history database entry files store pertinent information concerning updates in a database entry file. They also store information in a bundler section of the service history database during service bundle creation and information in a tool section of the service history database during installation of the service bundle. The service history database entry files also maintain information relating to the installation/removal of service bundles.
Service fix list files list the service item files contained in the service bundle. The service items are placed in a service fix list during service bundle creation. The service fix list control file uses the service fix list during installation or removal of the service bundle.
The service bundle 1 also includes a name field 7 identifying the service bundle. The name of the service bundle 1 is created by combining the service level information and a description of the service item, to yield a file name that is unique for the service bundle. The file extension of the service bundle indicates whether the service bundle includes new service items to be installed or archived service files to be re-installed. In the preferred embodiment, a .CSB
extension denotes a service bundle that installs new service item files while a .CSA
extension denotes a service bundle that re-installs archival service item files.
The service bundle 1 also includes a target directory representing the location on the vendor computer site where the software update is to be stored and executed.
Turning to Figure 2, a flow chart displaying the steps performed during creation of a service bundle using the service system tool is shown. It will be understood that during creation of the service bundle, the system service tool is conditioned to the bundler mode. Firstly, at step 10, creation of the service bundle is initiated. Afterwards, at step 12, the service type of the service bundle is selected. If the service item is to contain service item files relating to more than one software update, more than one service type may be selected. Service level and/or hot fix information is then selected for the service bundle at step 14 and a basic packaging rules check is executed at step 16 to verify that the service level of the service bundle matches the service level of the computer software product to which the service bundle is to be applied. If the service bundle fails the basic packaging rules check, service bundle creation is halted (step 18).
If the service bundle creation passes the basic packaging rules check, the appropriate service item files making up the service item are selected for inclusion in the service bundle and the service bundle is named (step 20). Target directories for the service item files are then selected (step 22). Afterwards, a set of service control files is created (step 24). If an error occurs during the creation of the service control files, service bundle creation is halted (step 26). Otherwise, the service bundle is _g_ compressed and stored in a zipped file format (step 28). If an error occurs during service bundle compression, service bundle creation is halted (step 30). Once the zipped service bundle is created, the zipped service bundle is logged and stored in the service history database (step 32) and the service bundle creation program is exited (step 34).
Once the service bundle has been created and stored in the service history database, the service bundle may be distributed to the target customer computer site for installation.
Figure 6 better illustrates the steps performed during the basic packaging rules check. During the basic packaging rules check, the service bundle is first tested for failed service recovery (step 159). The test is performed to determine if the service bundle is able to support recovery from errors during the installation or removal process. If the service bundle passes this test, the basic packaging rules check is exited (step 160). If the service bundle fails the service recovery test, the service level of the service bundle is determined (step 162). If a bad service bundle is detected, the basic packaging rules check is exited (step 164) and service bundle creation is stopped (step 168). Otherwise, the current service level of the service bundle is determined from the service history database (step 166). If a database error is detected, the basic packaging rules check is exited (step 168) and service bundle creation is halted (step 18). If no database error is detected, the service bundle level is compared with the service level required by the target customer computer site (step 170).
This comparison is used to verify that the service item stored in the service bundle is appropriate for the target customer computer site. If no match is found, the basic rules packaging check is exited (step 172) and the service bundle creation is halted (step 18). Otherwise, the service bundle is considered to have basic packaging rules check and the basic packaging rules check is exited (step 173).
Turning to Figure 3, a flowchart outlining the process for installing the service bundle on a target customer computer site using the service system tool is shown. It will be understood that during this process the service system tool is conditioned to the tool mode. Initially, the target customer computer site accesses the vendor computer site through a dial-up or Internet connection and initializes the installation process (step 35). At this point, the service bundle to be applied to the target customer computer site is selected (step 36).
A basic service rules check is then performed (step 38) to verify that the service bundle is appropriate for the target customer computer site. If the service bundle fails the basic service rules check, installation of the service bundle is halted (step 40). Otherwise, the service control files are extracted from the service bundle (step 42). If the service control files are not correctly extracted, installation of the service bundle is halted (step 44). If no errors arise during extraction of the service control files, the service control files are checked for self service, or self executable files (step 46). In most cases, icons are selected in order to execute a program but, in some cases, files are self executing and therefore, no icons need to be selected. If a self service file is detected, the file is immediately executed, by a self service module, at step 48 as will be described.
If there is no self service file present, the service control files are parsed (step 50) to determine the service bundle level along with its contents. If a failure occurs while parsing the service control files, installation of the service bundle is halted (step 52). Otherwise, a service files relationship rules check is performed (step 53). If the service files relationship rules check fails, service bundle installation is stopped (step 54). Otherwise, outdated service item files, from previous service bundles, are replaced with new service item files (step 56). At this point, the service bundle changes from a .CSB extension to a .CSA extension. The outdated service item files that have been replaced are archived in the service map file. This allows the previous version of the computer software product to be restored. Information concerning the location of the archived files and also their original location is stored in the service map file. If the archiving process fails, service bundle installation is halted (step 58) Following the file archiving process, pre-apply service commands are executed (step 60). If a failure occurs, a pre-apply service command failure recovery program is executed at step 62 to correct the failure. The pre-apply service command failure recover program will be described below. Otherwise, each of the service item update files is copied to its target directory (step 64). If a failure occurs, a file copy failure recovery program is executed at step 66 to correct the file copy failure. The file copy failure recovery program is described below. If the service item files are correctly copied, post-apply service commands are executed (step 68). Failure to execute the post-apply service commands results in the execution of a post-apply service command failure recovery program at step 70 to correct the service command error. The post-apply service command recovery program is described below.
Upon successful execution of the post-apply service commands, service bundle installation is checked to determine if it is a result of a failed service recovery (step 72). If it is a result of a failed service recovery, installation of the service bundle is complete (step 74). Otherwise, the service history database is updated to indicate that the service bundle was successfully applied to the target customer computer site on the date/time, at step 76. If an error occurs during the service history database update, a database transaction failure recovery program is executed at step 78. If the service history database is successfully updated, installation of the service bundle is complete (step 80). As will be appreciated, each step of the installation process of the service bundle is tracked to ensure integrity. If an error occurs during installation, recovery programs are executed as will be described further herein.
Figure 4 is a flow chart detailing the steps for removing a service bundle from a target customer computer site. Once, the removal process has been initiated (step 81 ), the service bundle to be removed is selected (step 82).
A basic service rules check is then performed on the selected service bundle (step 84). If the service bundle fails the basic service rules check, service bundle removal is halted (step 86). Otherwise, the service control files are extracted from the service bundle (step 88). Service bundle removal is also terminated if an error occurs during extraction of the service control files (step 90). If no error occurs, the service bundle is checked for self service files (step 92). If a self service file exists, the service bundle removal program enters a self service operation module (step 94).
Otherwise, the service control files are parsed (step 96). If an error occurs during the service control file parsing, service bundle removal is stopped (step 98). If no error occurs, a service files relationship rules check is performed (step 100). If the service files relationship rules check fails, service bundle removal is halted (step 102).
If the service files relationship rules check passes, pre-remove service commands are executed (step 104). If a failure occurs during command execution, a pre-remove service command failure recovery program is executed at step 106.
If no failure occurs, each of the service item files is copied to its target directory (step 108).
If a failure occurs, a file copy failure recovery program is executed at step 110.
Otherwise, post-remove service commands are executed (step 112). If the post-remove service commands cannot be executed, a post-remove service command failure recovery program is executed at step 114. If the post-remove service commands are successfully executed, the service bundle execution is monitored to determine if it is a result of a failed service recovery occurred (step 116).
If it is a result of a failed service recovery, the service bundle removal is considered to be completed and the process is exited (step 118). Otherwise, the service history 1 S database is updated to indicate that the service bundle was successfully removed, at step 120. If an error occurs during the service history database update, a database transaction failure recovery program is executed at step 122. If the service history database is successfully updated, the service bundle removal process is completed (step 124).
Figure 5 is a flow chart showing the steps performed to deal with self service files. When a self service file is detected, the self service module is initiated (step 125). The self service module attempts to obtain service mutex from the target customer computer site (step 126). This causes the actions of the service bundle to be mutually exclusive and run independently with respect to other computer applications.
If the self service module is unable to obtain service mutex, execution of the self service file is halted (step 128). Otherwise, the target customer computer site registry is checked to monitor the progress of the request for service mutex. (step 130). If the target customer computer site returns a message of nothing to do or uncorrectable failure, execution of the self service file is halted (step 132). If service mutex is received, the self service file is extracted from the service bundle (step 134). An extraction failure results in the termination of self service file execution (step 136).
Otherwise, the service control files are parsed (step 138).
If an error occurs during parsing of the service control files, self service file execution is halted (step 139). If no error occurs, a service file relationships rules check is performed (step 140). Failure to pass the service file relationships rules check, results in the termination of self service file execution (step 142). Upon passing the service file relationships rules check, the outdated service files from previous service bundles that are replaced by the self service files are archived (step 144). If the file archive process fails, execution of the self service file is halted (step 146). Otherwise, at step 148, the self service file is copied to its target directory (step 148). If a failure occurs during copying, the file copy failure recovery program is executed (step 1 SO). If no copying errors occur, the service system tool is launched to complete service operation by installing the service item file (step 152).
If the service system tool is unable to launch, execution is halted (step 154). Once the service operation has been completed the service mutex is returned to the target customer computer site (step 156) and the self service module is exited (step 157).
In order to monitor and verify integrity, the service system tool utilizes two separate methodologies. One methodology is based on rules based service operations and the other is based on automatic failed service recovery. The implementation of these methodologies causes an integrity check to be performed at almost every step during the creation, installation and/or removal of a service bundle.
The rules based service operations perform checks during all service operations to ensure that target customer computer site integrity is not compromised as a result of the installation or removal of a service bundle. These operations are specific to service operation types. The basic packaging rules are implemented so that no service bundle is created, which duplicates a service bundle stored in the service history database. This is achieved by using a unique service bundle naming procedure. System integrity is also maintained since the contents of the service bundle cannot be changed after the service bundle has been created and logged in the service history database.
The steps performed during the service files relationships rules check are shown in Figure 7. This check is performed to verify that application of the service bundle does not cause a regression of a previous service item and/or to verify that installation of the service bundle does not cause improper removal of a pre-y requisite service item. This check also monitors the actions of files during installation of the service bundle.
Once initiated (step 174), a failed service recovery test is performed (step 174). If this test is passed, the service bundle returns to the function from which it exited (step 176). If the test is not passed, the service bundle begins a loop to search through the service bundle files for the service map control file (step 178).
Version information is then read from the target customer computer site and the service item files (step 180). If a file read error occurs, the service files relationship rules check is exited (step 182). Otherwise, the archived service item files stored on the target customer computer site are compared with the service item files stored in the service 1 S bundle (step 184). If a required software service item file is missing from the service bundle, a check is performed to see if the service item file is being installed or removed (step 186). If a match is found, the service files relationship rules check is exited due to the presence of a regression (step 188). Otherwise, the target customer computer site prerequisites are compared with the service item files in the service bundle (step 190).
After comparing the target customer computer site prerequisites, if a prerequisite is missing, a check is performed to see if the missing prerequisite is being installed or removed (step 191). If a match is found, the service files relationship rules check is exited due to the presence of the missing prerequisite (step 192).
Otherwise, the prerequisites of the service item are compared with the prerequisites in the archived service item files (step 194). This step also occurs after the comparison between the target customer computer site prerequisites and the service item files when no missing prerequisite is located. Prerequisites are used to verify that the installation of the service bundle is appropriate for the target customer computer site.
For instance, if a target customer computer site is running version S of an application and the service bundle is providing an update to version 4, then installation of the service bundle is not appropriate.
If there are any unmet target customer computer site prerequisites, a check is performed to see if the missing target customer computer site prerequisites S are the ones being applied or removed (step 196). If the result is negative, the service files relationship rules check is exited (step 198). Otherwise, other service item files that need to be checked are determined (step 200). If more service item files need to be checked, the module returns to step 178 to search through the remaining service item files listed in the service map control file. Otherwise the service files relationship rules check is passed and a message is returned to the function from which it exited (step 202).
The service system tool also verifies the appropriateness of a service bundle, as well as, correctness of execution based on the automatic recovery from failed service methodology. Examples are shown with respect to Figures 8 to 12.
Figure 8 shows a loadtime recovery process to monitor the service bundle installation and removal processes for errors. If an error occurs, the loadtime recovery process attempts to solve the problem and allow, upon fixing of the problem, the service bundle installation or removal to continue from the point where the error occurred instead of requiring the process to restart. Once the loadtime recovery process is initiated (step 203), a test is performed to check for the presence of any other loadtime recovery processes (step 204). If another loadtime recovery process is being executed, the present loadtime recovery process is halted (step 206).
Otherwise, a test for service in progress is performed on the target customer computer site (step 208). If the loadtime recovery process does not locate any errors, the loadtime recovery process is halted since no recovery is necessary (step 210).
Otherwise, a test is performed to find out what type of recovery is necessary (step 212).
If no recovery appears necessary, the loadtime recovery process is stopped (step 214). Otherwise, a failed service operation (step 215) and a failed service step (step 216) are invoked. The failed service operation (step 21 S) determines which process was being executed when the error occurred and the failed service step (step 216) determines at which step the error occurred. A check is then performed to see if the failure is recoverable (step 217). If recovery is not possible, the loadtime recovery process is halted and installation or removal of the service bundle is restarted (step 218). Otherwise, the loadtime recovery process locates where the error occurred (step 219) and executes routines necessary to fix the error. This includes, but is not limited to the failed pre-service command recovery program (step 220), the failed post service command recovery program (step 222), the failed service file copy recovery program (step 224) and/or the failed database transaction recovery program (step 226). Afterwards, the loadtime recovery process verifies that the recovery was successful (step 228).
As described above, during installation or removal of a service bundle, various failure recovery processes are executed based on event failure. One such process is the pre-service command failure recovery as shown in the flowchart of Figure 9.
Upon initiation of the command failure recovery process (step 233), the service bundle is checked to see if the function from which it exited was the installation process (step 234). If the function is not the installation process, the post apply service command is executed at step 236. Otherwise, the post remove service command is executed at step 238. After execution of either service command, a check is performed to verify that the service command was successfully executed (step 240).
A message is then returned to the function from which it exited indicating whether execution of the service command execution was successful (step 242) or a failure (step 244). If the service command execution is successful, the function from which it exited continues from the point where the error occurred.
The post-service command failure process is shown in Figure 10.
Once the post-service command failure process is initiated (step 245), the service bundle is checked to see if the function from which it exited was the installation of the service bundle (step 246). If the function from which it exited is not installation, the service bundle is re-instated (step 248). Otherwise, the execution of the service bundle returns to the start of the remove service (step 250). Afterwards, a check is executed to verify that the service command was successfully executed (step 252). A
message is then returned to the function from which is exited indicating whether the service command execution was successful (step 254) or a failure (step 256). If the service command execution is successful, the function from which it exited continues from the point where the error occurred.
The service file copy failure recovery process is shown in Figure 11.
Once this recovery process is initiated (step 257), the service bundle is checked to see if the function from which it exited was installation of the service bundle (step 258).
If the function from which it exited is not installation, the service bundle installation returns to the apply service (step 260). Otherwise, the execution of the service bundle returns to the start of the remove service (step 262). Afterwards, a check is executed to verify that the service operation was successfully executed (step 264). A
message is then returned to the function from which it exited indicating whether the service command execution was successful (step 266) or a failure (step 268). If the service command execution is successful, the function from which it exited continues from the point where the error occurred.
The database transaction failure recovery process is shown in Figure 12. After initiation of the database recovery process (step 269), the service bundle is checked to see if the recovery mode was inline (step 270). An inline recovery process is a method to write progress and diagnostic information during a service operation in a form from which a failing operation can be determined. If the function from which it exited is not inline, a partial record is removed from the database (step 272).
Otherwise, the entire transaction is rolled back and restarted (step 274).
After execution of either database transaction, a check is executed to verify that database integrity is restored (step 276). A message is then returned to the function from which it exited indicating whether the database integrity has been restored (step 278) or not restored (step 280).
It will be appreciated that, although only one embodiment of the invention has been described and illustrated in detail, various changes and modification may be made. All such changes and modifications may be made without departing from the spirit and scope of the invention as defined by the claims appended herein.
OF COMPUTER SOFTWARE MAINTENANCE
Field of the Invention The present invention relates in general to computer software maintenance and more specifically to a system and method for managing updates to be applied to computer software products.
Background of the Invention Software vendors constantly update their computer software products to maintain market and customer acceptance. The software updates may add new features to the computer software product, remove unnecessary filed and/or correct existing problems, commonly referred to as bugs. In some cases, software updates are released on a regular basis by vendors. As a result, keeping track of the software updates can be difficult. Also, many vendors release different versions of the same computer software product. Different software updates may therefore be required for these different releases.
Presently, software vendors typically use one software program to create, test and package software updates and a separate software program to release and install the software updates. Using separate programs to test and package software updates and to release and install software updates, results in software updates being released to consumers without validating the appropriateness of the software updates for individual consumers.
It is therefore an object of the present invention to provide a novel system and method for managing updates to be applied to computer software products.
Summary of the Invention In order to overcome the problems in the prior art, the system and method of the present invention provide a single software module or tool to manage the packaging and tracking of software updates for multiple versions of a software application on a service system and to manage the installation, removal and tracking of software updates for multiple versions of a software application on a target system to maintain system integrity.
By including tools to track the execution of software updates on the target system, the present invention is able to monitor the updates and provide assistance in case an error occurs during execution. If an error occurs, execution of the update may be restarted from the error point instead of from the beginning to provide automatic recovery from a failed update install.
Furthermore, the system and method of the present invention provide tools to verify that the software update is applicable to the target system in order to maintain system integrity.
According to one aspect of the invention, there is provided a method of updating computer software running on a target remote computer site using a system tool running on a vendor computer site that can be conditioned to a bundling mode and an install mode, said method comprising the steps of:
conditioning said system tool to said bundling mode and using said system tool to create an update for said computer software; and thereafter conditioning said system tool to said install mode and using said system tool to apply said update to the computer software running on said target remote computer site, during said applying said system tool performing rule-based checks to verify the integrity of said update and performing automatic failed service recovery when an installation error occurs thereby to inhibit the computer software running on said target remote computer site from being compromised by application of said update thereto.
According to another aspect of the invention there is provided a method of updating computer software running on a target remote computer site using a system tool running on a vendor computer site that can be conditioned to a bundling mode and an install mode, said method comprising the steps of conditioning said system tool to said bundling mode and using said system tool to create a service bundle for said computer software, said service bundle including one or more update files and control files associated with said update files that identify target directories for said update files and the location of archived files stored in a service history database maintained by said system tool; and thereafter conditioning said system tool to said install mode and using said system tool to apply said service bundle to the computer software running on said target remote computer site, during said applying said system tool performing rule-based checks to verify the integrity of said service bundle and performing automatic failed service recovery when an event failure occurs during installation of said service bundle thereby to inhibit the computer software running on said target remote computer site from being compromised by application of said service bundle thereto.
In yet another aspect of the invention there is provided a computer readable medium having a computer program embodied thereon for updating computer software running on a target remote computer site, said computer program for running on a vendor computer site and being conditionable to a bundling mode and an install mode, said computer program including:
computer program code for creating an update for said computer software when said computer program is conditioned to said bundling mode; and computer program code for applying said update to the computer software running on said target remote computer site when said computer program is conditioned to said install mode, said computer program code for applying performing rule-based checks to verify the integrity of said update and performing automatic failed service recovery when an installation error occurs thereby to inhibit the computer software running on said target remote computer site from being compromised by application of said update thereto.
In still yet another aspect of the present invention, there is provided a computer readable medium having a computer program embodied thereon for updating computer software running on a target remote computer site, said computer program for running on a vendor computer site and being conditionable to a bundling mode and an install mode, said computer program including:
computer program code for creating a service bundle for said computer software when said computer program is conditioned to said bundling mode, said service bundle including one or more update files and control files associated with said update files that identify target directories for said update files and the location of archived files stored in a service history database maintained by said system tool; and computer program code for applying said service bundle to the computer software running on said target remote computer site when said computer program is conditioned to said install mode, said computer program code for applying performing rule-based checks to verify the integrity of said service bundle and performing automatic failed service recovery when an event failure occurs during installation of said service bundle thereby to inhibit the computer software running on said target remote computer site from being compromised by application of said service bundle thereto.
Brief Description of the Detailed Drawings A preferred embodiment of the present invention will now be described more fully with reference to the accompanying drawings, in which like numerals denote like parts throughout, and in which:
Figure 1 is a schematic diagram of a service bundle;
Figure 2 is a flowchart showing a service bundle creation process;
Figure 3 is a flowchart showing a service bundle installation process;
Figure 4 is a flowchart showing a service bundle removal process;
Figure S is a flowchart showing a self service file process;
Figure 6 is a flowchart showing a basic service rules check process;
Figure 7 is a flowchart showing a service file relationship check process;
Figure 8 is a flowchart showing a loadtime failure recovery process;
Figure 9 is a flowchart showing a recover on pre-service command failure process;
Figure 10 is a flowchart showing a recover on post service command failure process;
Figure 11 is a flowchart showing a recover on failed file copy process;
and Figure 12 is a flowchart showing a recover on failed database transaction process.
Detailed Description of the Preferred Embodiment S ~ As mentioned above, software vendors typically release software updates to customers on a continuing basis to enhance computer software products.
Generally, the software updates correct existing and/or foreseeable bugs, enhance applications and/or add new features. To manage computer software product updates in this environment, the present invention provides a system and method for packaging, tracking, installing and removing computer software updates for a computer software product having multiple versions. A preferred embodiment of the present invention will now be described.
The present invention provides a service system tool to allow computer software product updates or "service items" to be created, tracked and packaged on a vendor's computer site and to allow computer software products on customer computer sites to be tracked and updated with appropriate service items. The service system tool is operable in a bundler mode and in a tool mode. Specifically, the service system tool is conditioned to the bundler mode on the vendor's computer site when it is desired to create, manage and package service items for installation on target customers' computer sites. The service system tool is conditioned to the tool mode when it is desired to install and track the service items on target customers' computer sites. The service system tool also includes a command line interface to record service item installations in a service history database. In the tool mode, the service history database includes computer product version information and applied service item information. In the bundler mode, the service history database tracks service items available to versions of the computer software products.
In the bundler mode, the service system tool creates, manages and packages service items into service bundles. Turning to Figure 1, a schematic representation of a service bundle is shown and is generally identified by reference numeral 1. As can be seen, service bundle 1 includes a service type information section 3, which identifies the type of software update, or updates in the service items associated with the service bundle. The service bundle 1 also includes a service levellhot fix information section 4. Section 4 includes information concerning the service status of the service bundle i.e. Beta version, Alpha version or released version. Section 4 also includes information relating to the smallest service item within the service bundle.
The service bundle 1 also includes a files/updates section 5 storing service item files making up the service item. A service control files section 6 stores control files associated with the service items files. The service control files are used to control the operation of the various service types of the service bundle.
The name of each service control file is based on the service level and a description of the service item file. In the present embodiment, the service control files can include service map files, service command files, service history database entry files and service fix list files.
Service map files list the service item files included in the service bundle 1 and the target directory for each service item file. During installation of the software update, outdated service item files, from previous updates, are archived and replaced by the update files. The service map files store the locations of the archived files in case the archived files have to be restored due to an error during the installation of the software update. This property is intended to maintain system integrity.
The service command files aid in the parsing of contents of service commands and for executing service commands. Examples of service commands include installation and removal programs used in connection with the service bundle.
The service history database entry files store pertinent information concerning updates in a database entry file. They also store information in a bundler section of the service history database during service bundle creation and information in a tool section of the service history database during installation of the service bundle. The service history database entry files also maintain information relating to the installation/removal of service bundles.
Service fix list files list the service item files contained in the service bundle. The service items are placed in a service fix list during service bundle creation. The service fix list control file uses the service fix list during installation or removal of the service bundle.
The service bundle 1 also includes a name field 7 identifying the service bundle. The name of the service bundle 1 is created by combining the service level information and a description of the service item, to yield a file name that is unique for the service bundle. The file extension of the service bundle indicates whether the service bundle includes new service items to be installed or archived service files to be re-installed. In the preferred embodiment, a .CSB
extension denotes a service bundle that installs new service item files while a .CSA
extension denotes a service bundle that re-installs archival service item files.
The service bundle 1 also includes a target directory representing the location on the vendor computer site where the software update is to be stored and executed.
Turning to Figure 2, a flow chart displaying the steps performed during creation of a service bundle using the service system tool is shown. It will be understood that during creation of the service bundle, the system service tool is conditioned to the bundler mode. Firstly, at step 10, creation of the service bundle is initiated. Afterwards, at step 12, the service type of the service bundle is selected. If the service item is to contain service item files relating to more than one software update, more than one service type may be selected. Service level and/or hot fix information is then selected for the service bundle at step 14 and a basic packaging rules check is executed at step 16 to verify that the service level of the service bundle matches the service level of the computer software product to which the service bundle is to be applied. If the service bundle fails the basic packaging rules check, service bundle creation is halted (step 18).
If the service bundle creation passes the basic packaging rules check, the appropriate service item files making up the service item are selected for inclusion in the service bundle and the service bundle is named (step 20). Target directories for the service item files are then selected (step 22). Afterwards, a set of service control files is created (step 24). If an error occurs during the creation of the service control files, service bundle creation is halted (step 26). Otherwise, the service bundle is _g_ compressed and stored in a zipped file format (step 28). If an error occurs during service bundle compression, service bundle creation is halted (step 30). Once the zipped service bundle is created, the zipped service bundle is logged and stored in the service history database (step 32) and the service bundle creation program is exited (step 34).
Once the service bundle has been created and stored in the service history database, the service bundle may be distributed to the target customer computer site for installation.
Figure 6 better illustrates the steps performed during the basic packaging rules check. During the basic packaging rules check, the service bundle is first tested for failed service recovery (step 159). The test is performed to determine if the service bundle is able to support recovery from errors during the installation or removal process. If the service bundle passes this test, the basic packaging rules check is exited (step 160). If the service bundle fails the service recovery test, the service level of the service bundle is determined (step 162). If a bad service bundle is detected, the basic packaging rules check is exited (step 164) and service bundle creation is stopped (step 168). Otherwise, the current service level of the service bundle is determined from the service history database (step 166). If a database error is detected, the basic packaging rules check is exited (step 168) and service bundle creation is halted (step 18). If no database error is detected, the service bundle level is compared with the service level required by the target customer computer site (step 170).
This comparison is used to verify that the service item stored in the service bundle is appropriate for the target customer computer site. If no match is found, the basic rules packaging check is exited (step 172) and the service bundle creation is halted (step 18). Otherwise, the service bundle is considered to have basic packaging rules check and the basic packaging rules check is exited (step 173).
Turning to Figure 3, a flowchart outlining the process for installing the service bundle on a target customer computer site using the service system tool is shown. It will be understood that during this process the service system tool is conditioned to the tool mode. Initially, the target customer computer site accesses the vendor computer site through a dial-up or Internet connection and initializes the installation process (step 35). At this point, the service bundle to be applied to the target customer computer site is selected (step 36).
A basic service rules check is then performed (step 38) to verify that the service bundle is appropriate for the target customer computer site. If the service bundle fails the basic service rules check, installation of the service bundle is halted (step 40). Otherwise, the service control files are extracted from the service bundle (step 42). If the service control files are not correctly extracted, installation of the service bundle is halted (step 44). If no errors arise during extraction of the service control files, the service control files are checked for self service, or self executable files (step 46). In most cases, icons are selected in order to execute a program but, in some cases, files are self executing and therefore, no icons need to be selected. If a self service file is detected, the file is immediately executed, by a self service module, at step 48 as will be described.
If there is no self service file present, the service control files are parsed (step 50) to determine the service bundle level along with its contents. If a failure occurs while parsing the service control files, installation of the service bundle is halted (step 52). Otherwise, a service files relationship rules check is performed (step 53). If the service files relationship rules check fails, service bundle installation is stopped (step 54). Otherwise, outdated service item files, from previous service bundles, are replaced with new service item files (step 56). At this point, the service bundle changes from a .CSB extension to a .CSA extension. The outdated service item files that have been replaced are archived in the service map file. This allows the previous version of the computer software product to be restored. Information concerning the location of the archived files and also their original location is stored in the service map file. If the archiving process fails, service bundle installation is halted (step 58) Following the file archiving process, pre-apply service commands are executed (step 60). If a failure occurs, a pre-apply service command failure recovery program is executed at step 62 to correct the failure. The pre-apply service command failure recover program will be described below. Otherwise, each of the service item update files is copied to its target directory (step 64). If a failure occurs, a file copy failure recovery program is executed at step 66 to correct the file copy failure. The file copy failure recovery program is described below. If the service item files are correctly copied, post-apply service commands are executed (step 68). Failure to execute the post-apply service commands results in the execution of a post-apply service command failure recovery program at step 70 to correct the service command error. The post-apply service command recovery program is described below.
Upon successful execution of the post-apply service commands, service bundle installation is checked to determine if it is a result of a failed service recovery (step 72). If it is a result of a failed service recovery, installation of the service bundle is complete (step 74). Otherwise, the service history database is updated to indicate that the service bundle was successfully applied to the target customer computer site on the date/time, at step 76. If an error occurs during the service history database update, a database transaction failure recovery program is executed at step 78. If the service history database is successfully updated, installation of the service bundle is complete (step 80). As will be appreciated, each step of the installation process of the service bundle is tracked to ensure integrity. If an error occurs during installation, recovery programs are executed as will be described further herein.
Figure 4 is a flow chart detailing the steps for removing a service bundle from a target customer computer site. Once, the removal process has been initiated (step 81 ), the service bundle to be removed is selected (step 82).
A basic service rules check is then performed on the selected service bundle (step 84). If the service bundle fails the basic service rules check, service bundle removal is halted (step 86). Otherwise, the service control files are extracted from the service bundle (step 88). Service bundle removal is also terminated if an error occurs during extraction of the service control files (step 90). If no error occurs, the service bundle is checked for self service files (step 92). If a self service file exists, the service bundle removal program enters a self service operation module (step 94).
Otherwise, the service control files are parsed (step 96). If an error occurs during the service control file parsing, service bundle removal is stopped (step 98). If no error occurs, a service files relationship rules check is performed (step 100). If the service files relationship rules check fails, service bundle removal is halted (step 102).
If the service files relationship rules check passes, pre-remove service commands are executed (step 104). If a failure occurs during command execution, a pre-remove service command failure recovery program is executed at step 106.
If no failure occurs, each of the service item files is copied to its target directory (step 108).
If a failure occurs, a file copy failure recovery program is executed at step 110.
Otherwise, post-remove service commands are executed (step 112). If the post-remove service commands cannot be executed, a post-remove service command failure recovery program is executed at step 114. If the post-remove service commands are successfully executed, the service bundle execution is monitored to determine if it is a result of a failed service recovery occurred (step 116).
If it is a result of a failed service recovery, the service bundle removal is considered to be completed and the process is exited (step 118). Otherwise, the service history 1 S database is updated to indicate that the service bundle was successfully removed, at step 120. If an error occurs during the service history database update, a database transaction failure recovery program is executed at step 122. If the service history database is successfully updated, the service bundle removal process is completed (step 124).
Figure 5 is a flow chart showing the steps performed to deal with self service files. When a self service file is detected, the self service module is initiated (step 125). The self service module attempts to obtain service mutex from the target customer computer site (step 126). This causes the actions of the service bundle to be mutually exclusive and run independently with respect to other computer applications.
If the self service module is unable to obtain service mutex, execution of the self service file is halted (step 128). Otherwise, the target customer computer site registry is checked to monitor the progress of the request for service mutex. (step 130). If the target customer computer site returns a message of nothing to do or uncorrectable failure, execution of the self service file is halted (step 132). If service mutex is received, the self service file is extracted from the service bundle (step 134). An extraction failure results in the termination of self service file execution (step 136).
Otherwise, the service control files are parsed (step 138).
If an error occurs during parsing of the service control files, self service file execution is halted (step 139). If no error occurs, a service file relationships rules check is performed (step 140). Failure to pass the service file relationships rules check, results in the termination of self service file execution (step 142). Upon passing the service file relationships rules check, the outdated service files from previous service bundles that are replaced by the self service files are archived (step 144). If the file archive process fails, execution of the self service file is halted (step 146). Otherwise, at step 148, the self service file is copied to its target directory (step 148). If a failure occurs during copying, the file copy failure recovery program is executed (step 1 SO). If no copying errors occur, the service system tool is launched to complete service operation by installing the service item file (step 152).
If the service system tool is unable to launch, execution is halted (step 154). Once the service operation has been completed the service mutex is returned to the target customer computer site (step 156) and the self service module is exited (step 157).
In order to monitor and verify integrity, the service system tool utilizes two separate methodologies. One methodology is based on rules based service operations and the other is based on automatic failed service recovery. The implementation of these methodologies causes an integrity check to be performed at almost every step during the creation, installation and/or removal of a service bundle.
The rules based service operations perform checks during all service operations to ensure that target customer computer site integrity is not compromised as a result of the installation or removal of a service bundle. These operations are specific to service operation types. The basic packaging rules are implemented so that no service bundle is created, which duplicates a service bundle stored in the service history database. This is achieved by using a unique service bundle naming procedure. System integrity is also maintained since the contents of the service bundle cannot be changed after the service bundle has been created and logged in the service history database.
The steps performed during the service files relationships rules check are shown in Figure 7. This check is performed to verify that application of the service bundle does not cause a regression of a previous service item and/or to verify that installation of the service bundle does not cause improper removal of a pre-y requisite service item. This check also monitors the actions of files during installation of the service bundle.
Once initiated (step 174), a failed service recovery test is performed (step 174). If this test is passed, the service bundle returns to the function from which it exited (step 176). If the test is not passed, the service bundle begins a loop to search through the service bundle files for the service map control file (step 178).
Version information is then read from the target customer computer site and the service item files (step 180). If a file read error occurs, the service files relationship rules check is exited (step 182). Otherwise, the archived service item files stored on the target customer computer site are compared with the service item files stored in the service 1 S bundle (step 184). If a required software service item file is missing from the service bundle, a check is performed to see if the service item file is being installed or removed (step 186). If a match is found, the service files relationship rules check is exited due to the presence of a regression (step 188). Otherwise, the target customer computer site prerequisites are compared with the service item files in the service bundle (step 190).
After comparing the target customer computer site prerequisites, if a prerequisite is missing, a check is performed to see if the missing prerequisite is being installed or removed (step 191). If a match is found, the service files relationship rules check is exited due to the presence of the missing prerequisite (step 192).
Otherwise, the prerequisites of the service item are compared with the prerequisites in the archived service item files (step 194). This step also occurs after the comparison between the target customer computer site prerequisites and the service item files when no missing prerequisite is located. Prerequisites are used to verify that the installation of the service bundle is appropriate for the target customer computer site.
For instance, if a target customer computer site is running version S of an application and the service bundle is providing an update to version 4, then installation of the service bundle is not appropriate.
If there are any unmet target customer computer site prerequisites, a check is performed to see if the missing target customer computer site prerequisites S are the ones being applied or removed (step 196). If the result is negative, the service files relationship rules check is exited (step 198). Otherwise, other service item files that need to be checked are determined (step 200). If more service item files need to be checked, the module returns to step 178 to search through the remaining service item files listed in the service map control file. Otherwise the service files relationship rules check is passed and a message is returned to the function from which it exited (step 202).
The service system tool also verifies the appropriateness of a service bundle, as well as, correctness of execution based on the automatic recovery from failed service methodology. Examples are shown with respect to Figures 8 to 12.
Figure 8 shows a loadtime recovery process to monitor the service bundle installation and removal processes for errors. If an error occurs, the loadtime recovery process attempts to solve the problem and allow, upon fixing of the problem, the service bundle installation or removal to continue from the point where the error occurred instead of requiring the process to restart. Once the loadtime recovery process is initiated (step 203), a test is performed to check for the presence of any other loadtime recovery processes (step 204). If another loadtime recovery process is being executed, the present loadtime recovery process is halted (step 206).
Otherwise, a test for service in progress is performed on the target customer computer site (step 208). If the loadtime recovery process does not locate any errors, the loadtime recovery process is halted since no recovery is necessary (step 210).
Otherwise, a test is performed to find out what type of recovery is necessary (step 212).
If no recovery appears necessary, the loadtime recovery process is stopped (step 214). Otherwise, a failed service operation (step 215) and a failed service step (step 216) are invoked. The failed service operation (step 21 S) determines which process was being executed when the error occurred and the failed service step (step 216) determines at which step the error occurred. A check is then performed to see if the failure is recoverable (step 217). If recovery is not possible, the loadtime recovery process is halted and installation or removal of the service bundle is restarted (step 218). Otherwise, the loadtime recovery process locates where the error occurred (step 219) and executes routines necessary to fix the error. This includes, but is not limited to the failed pre-service command recovery program (step 220), the failed post service command recovery program (step 222), the failed service file copy recovery program (step 224) and/or the failed database transaction recovery program (step 226). Afterwards, the loadtime recovery process verifies that the recovery was successful (step 228).
As described above, during installation or removal of a service bundle, various failure recovery processes are executed based on event failure. One such process is the pre-service command failure recovery as shown in the flowchart of Figure 9.
Upon initiation of the command failure recovery process (step 233), the service bundle is checked to see if the function from which it exited was the installation process (step 234). If the function is not the installation process, the post apply service command is executed at step 236. Otherwise, the post remove service command is executed at step 238. After execution of either service command, a check is performed to verify that the service command was successfully executed (step 240).
A message is then returned to the function from which it exited indicating whether execution of the service command execution was successful (step 242) or a failure (step 244). If the service command execution is successful, the function from which it exited continues from the point where the error occurred.
The post-service command failure process is shown in Figure 10.
Once the post-service command failure process is initiated (step 245), the service bundle is checked to see if the function from which it exited was the installation of the service bundle (step 246). If the function from which it exited is not installation, the service bundle is re-instated (step 248). Otherwise, the execution of the service bundle returns to the start of the remove service (step 250). Afterwards, a check is executed to verify that the service command was successfully executed (step 252). A
message is then returned to the function from which is exited indicating whether the service command execution was successful (step 254) or a failure (step 256). If the service command execution is successful, the function from which it exited continues from the point where the error occurred.
The service file copy failure recovery process is shown in Figure 11.
Once this recovery process is initiated (step 257), the service bundle is checked to see if the function from which it exited was installation of the service bundle (step 258).
If the function from which it exited is not installation, the service bundle installation returns to the apply service (step 260). Otherwise, the execution of the service bundle returns to the start of the remove service (step 262). Afterwards, a check is executed to verify that the service operation was successfully executed (step 264). A
message is then returned to the function from which it exited indicating whether the service command execution was successful (step 266) or a failure (step 268). If the service command execution is successful, the function from which it exited continues from the point where the error occurred.
The database transaction failure recovery process is shown in Figure 12. After initiation of the database recovery process (step 269), the service bundle is checked to see if the recovery mode was inline (step 270). An inline recovery process is a method to write progress and diagnostic information during a service operation in a form from which a failing operation can be determined. If the function from which it exited is not inline, a partial record is removed from the database (step 272).
Otherwise, the entire transaction is rolled back and restarted (step 274).
After execution of either database transaction, a check is executed to verify that database integrity is restored (step 276). A message is then returned to the function from which it exited indicating whether the database integrity has been restored (step 278) or not restored (step 280).
It will be appreciated that, although only one embodiment of the invention has been described and illustrated in detail, various changes and modification may be made. All such changes and modifications may be made without departing from the spirit and scope of the invention as defined by the claims appended herein.
Claims (19)
1. A method of updating computer software running on a target remote computer site using a system tool running on a vendor computer site that can be conditioned to a bundling mode and an install mode, said method comprising the steps of:
conditioning said system tool to said bundling mode and using said system tool to create an update for said computer software; and thereafter conditioning said system tool to said install mode and using said system tool to apply said update to the computer software running on said target remote computer site, during said applying said system tool performing rule-based checks to verify the integrity of said update and performing automatic failed service recovery when an installation error occurs thereby to inhibit the computer software running on said target remote computer site from being compromised by application of said update thereto.
conditioning said system tool to said bundling mode and using said system tool to create an update for said computer software; and thereafter conditioning said system tool to said install mode and using said system tool to apply said update to the computer software running on said target remote computer site, during said applying said system tool performing rule-based checks to verify the integrity of said update and performing automatic failed service recovery when an installation error occurs thereby to inhibit the computer software running on said target remote computer site from being compromised by application of said update thereto.
2. The method of claim 1 wherein in said bundling mode, said system tool creates and packages said update into a service bundle, during said creating said system tool performing a rule-based check to ensure said service bundle is appropriate for the computer software running on said target remote computer site.
3. The method of claim 2 wherein during performance of said rule-based check, version levels of said update and the computer software running on said target remote computer are compared to ensure they are the same.
4. The method of claim 2 or 3 wherein during said creating said system tool tests said service bundle to determine if said service bundle can support automatic failed service recovery, said system tool terminating said creating step if said service bundle fails the test.
5. The method of any one of claims 2 to 4 wherein said creating further includes the step of compressing said service bundle and storing said compressed service bundle in a database.
6. The method of claim 4 or 5 wherein said service bundle includes one or more update files and control files associated with said update files, said control files identifying target directories for said update files.
7. The method of claim 6 wherein said control files further identify the location of archived files stored in a service history database maintained by said system tool.
8. The method of claim 7 wherein said applying comprises the steps of:
extracting said control files from said service bundle to determine the target directories for said update files;
replacing files of said computer software with corresponding update files in said service bundle;
archiving the replaced files in said service history database; and updating said control files to identify the location of the archived replaced files.
extracting said control files from said service bundle to determine the target directories for said update files;
replacing files of said computer software with corresponding update files in said service bundle;
archiving the replaced files in said service history database; and updating said control files to identify the location of the archived replaced files.
9. The method of claim 8 wherein said rules-based checks include verifying that the service bundle is appropriate for the computer software running on said target remote computer site; verifying extraction of said control files;
and verifying updating of said control files, service bundle installation being halted upon failure of one of said rules-based checks.
and verifying updating of said control files, service bundle installation being halted upon failure of one of said rules-based checks.
10. The method of claim 9 wherein said automatic failed service recovery is performed when an event failure occurs during installation of said service bundle.
11. The method of claim 10 wherein when an event failure occurs, said system tool determines if installation of said service bundle can be re-commenced from the point at which the event failure occurred or whether the service bundle needs to be completely re-installed prior, installation of said service bundle proceeding based on the result of said determination.
12. A method of updating computer software running on a target remote computer site using a system tool running on a vendor computer site that can be conditioned to a bundling mode and an install mode, said method comprising the steps of:
conditioning said system tool to said bundling mode and using said system tool to create a service bundle for said computer software, said service bundle including one or more update files and control files associated with said update files that identify target directories for said update files and the location of archived files stored in a service history database maintained by said system tool; and thereafter conditioning said system tool to said install mode and using said system tool to apply said service bundle to the computer software running on said target remote computer site, during said applying said system tool performing rule-based checks to verify the integrity of said service bundle and performing automatic failed service recovery when an event failure occurs during installation of said service bundle thereby to inhibit the computer software running on said target remote computer site from being compromised by application of said service bundle thereto.
conditioning said system tool to said bundling mode and using said system tool to create a service bundle for said computer software, said service bundle including one or more update files and control files associated with said update files that identify target directories for said update files and the location of archived files stored in a service history database maintained by said system tool; and thereafter conditioning said system tool to said install mode and using said system tool to apply said service bundle to the computer software running on said target remote computer site, during said applying said system tool performing rule-based checks to verify the integrity of said service bundle and performing automatic failed service recovery when an event failure occurs during installation of said service bundle thereby to inhibit the computer software running on said target remote computer site from being compromised by application of said service bundle thereto.
13. The method of claim 12 wherein when an event failure occurs, said system tool determines if installation of said service bundle can be re-commenced from the point at which the event failure occurred or whether the service bundle needs to be completely re-installed prior, installation of said service bundle proceeding based on the result of said determination.
14. The method of claim 13 wherein said applying comprises the steps of:
extracting said control files from said service bundle to determine the target directories for said update files;
replacing files of said computer software with corresponding update files in said service bundle;
archiving the replaced files in said service history database; and updating said control files to identify the location of the archived replaced files.
extracting said control files from said service bundle to determine the target directories for said update files;
replacing files of said computer software with corresponding update files in said service bundle;
archiving the replaced files in said service history database; and updating said control files to identify the location of the archived replaced files.
15. The method of claim 14 wherein said rules-based checks include verifying that the service bundle is appropriate for the computer software running on said target remote computer site; verifying extraction of said control files;
and verifying updating of said control files, service bundle installation being halted upon failure of one of said rules-based checks.
and verifying updating of said control files, service bundle installation being halted upon failure of one of said rules-based checks.
16. The method of claim 15 wherein during said creating said system tool performs a check to ensure version levels of said service bundle and the computer software running on said target remote computer site are equivalent and testing said service bundle to ensure said service bundle can support automatic failed service recovery, said system tool terminating said creating step if said service bundle fails said check.
17. The method of claim 16 wherein said creating further includes the step of compressing said service bundle and storing said compressed service bundle in a database.
18. A computer readable medium having a computer program embodied thereon for updating computer software running on a target remote computer site, said computer program for running on a vendor computer site and being conditionable to a bundling mode and an install mode, said computer program including:
computer program code for creating an update for said computer software when said computer program is conditioned to said bundling mode; and computer program code for applying said update to the computer software running on said target remote computer site when said computer program is conditioned to said install mode, said computer program code for applying performing rule-based checks to verify the integrity of said update and performing automatic failed service recovery when an installation error occurs thereby to inhibit the computer software running on said target remote computer site from being compromised by application of said update thereto.
computer program code for creating an update for said computer software when said computer program is conditioned to said bundling mode; and computer program code for applying said update to the computer software running on said target remote computer site when said computer program is conditioned to said install mode, said computer program code for applying performing rule-based checks to verify the integrity of said update and performing automatic failed service recovery when an installation error occurs thereby to inhibit the computer software running on said target remote computer site from being compromised by application of said update thereto.
19. A computer readable medium having a computer program embodied thereon for updating computer software running on a target remote computer site, said computer program for running on a vendor computer site and being conditionable to a bundling mode and an install mode, said computer program including:
computer program code for creating a service bundle for said computer software when said computer program is conditioned to said bundling mode, said service bundle including one or more update files and control files associated with said update files that identify target directories for said update files and the location of archived files stored in a service history database maintained by said system tool; and computer program code for applying said service bundle to the computer software running on said target remote computer site when said computer program is conditioned to said install mode, said computer program code for applying performing rule-based checks to verify the integrity of said service bundle and performing automatic failed service recovery when an event failure occurs during installation of said service bundle thereby to inhibit the computer software running on said target remote computer site from being compromised by application of said service bundle thereto.
computer program code for creating a service bundle for said computer software when said computer program is conditioned to said bundling mode, said service bundle including one or more update files and control files associated with said update files that identify target directories for said update files and the location of archived files stored in a service history database maintained by said system tool; and computer program code for applying said service bundle to the computer software running on said target remote computer site when said computer program is conditioned to said install mode, said computer program code for applying performing rule-based checks to verify the integrity of said service bundle and performing automatic failed service recovery when an event failure occurs during installation of said service bundle thereby to inhibit the computer software running on said target remote computer site from being compromised by application of said service bundle thereto.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA 2299850 CA2299850C (en) | 2000-03-01 | 2000-03-01 | System and method for the management of computer software maintenance |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA 2299850 CA2299850C (en) | 2000-03-01 | 2000-03-01 | System and method for the management of computer software maintenance |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2299850A1 CA2299850A1 (en) | 2001-09-01 |
| CA2299850C true CA2299850C (en) | 2005-06-14 |
Family
ID=4165424
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA 2299850 Expired - Fee Related CA2299850C (en) | 2000-03-01 | 2000-03-01 | System and method for the management of computer software maintenance |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2299850C (en) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7310801B2 (en) * | 2000-04-27 | 2007-12-18 | Microsoft Corporation | Servicing a component-based software product throughout the software product lifecycle |
| US7251812B1 (en) | 2001-10-31 | 2007-07-31 | Microsoft Corporation | Dynamic software update |
| US7472286B2 (en) | 2003-08-29 | 2008-12-30 | Microsoft Corporation | Selectively authorizing software functionality after installation of the software |
| US7747998B2 (en) | 2004-08-31 | 2010-06-29 | Microsoft Corporation | Elevated patching |
| US8819668B2 (en) | 2007-02-08 | 2014-08-26 | Microsoft Corporation | Accessible limited distribution release software change catalog |
| US8196134B2 (en) | 2007-02-08 | 2012-06-05 | Microsoft Corporation | Network service for a software change catalog |
-
2000
- 2000-03-01 CA CA 2299850 patent/CA2299850C/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| CA2299850A1 (en) | 2001-09-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7870547B2 (en) | Method and apparatus for managing patchable software systems | |
| US6161218A (en) | Software patch architecture | |
| CN107608706B (en) | Automatic hot updating method for application program based on functional module | |
| KR100655124B1 (en) | Software installation and testing system for a built-to-order computer system | |
| JP5444368B2 (en) | Application restore point | |
| US6381694B1 (en) | System for automatic recovery from software problems that cause computer failure | |
| US8886995B1 (en) | Fault tolerant state machine for configuring software in a digital computer | |
| US6981252B1 (en) | Method and apparatus for automatically uninstalling software on a network | |
| US6385766B1 (en) | Method and apparatus for windows-based installation for installing software on build-to-order computer systems | |
| US6678639B2 (en) | Automated problem identification system | |
| US7185335B2 (en) | Programmatic application installation diagnosis and cleaning | |
| KR100348007B1 (en) | Method and apparatus for restoration of a computer system hard drive | |
| US8352916B2 (en) | Facilitating the automated testing of daily builds of software | |
| US7509544B2 (en) | Data repair and synchronization method of dual flash read only memory | |
| US7370233B1 (en) | Verification of desired end-state using a virtual machine environment | |
| US11113169B2 (en) | Automatic creation of best known configurations | |
| CA2299850C (en) | System and method for the management of computer software maintenance | |
| US8132047B2 (en) | Restoring application upgrades using an application restore point | |
| CN112764789A (en) | Distributed software upgrading method and node | |
| US11782800B2 (en) | Methods to automatically correct and improve system recovery and replication processes | |
| CN107766072A (en) | Video card refreshes BIOS method under a kind of linux system | |
| US8316444B2 (en) | Third-party software product certification | |
| CN111625840A (en) | Program checking method, program upgrading method and device | |
| CN117850827A (en) | Domestic operating system security upgrading device and method with transaction characteristics | |
| CN118132136A (en) | Automatic packaging method and device for application program |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |
Effective date: 20140303 |