Automation tool for application installations

TECHNICAL FIELD

0001Embodiments relate to the field of data processing, in particular, to methods and apparatuses for identifying and executing installations of a plurality of application modules based on installation relationship(s) of the modules, where the relationships may be described by a data structure.

BACKGROUND

0002Continuous advances in processing speed, storage size, and networking have allowed for the development of applications, applications suites, and platforms of increasing complexity. Often such software components comprise a plurality of modules, each module having its own installation executable responsible for installing that module. To meet these installation needs, programs have been developed that are capable of chaining the multiple installations of the multiple modules, such as install wizards. These programs sometimes include scripts capable of checking codes returned by executions of installations to determine whether the installations were successful. Such programs, however, have a number of disadvantages. First, these programs fail to monitor parent-child relationships between the modules, insuring that installations of child modules of a parent module have been completed before executing an installation of another module that is not a child of the parent. Second, such programs do not include specific success criteria for each installation, and thus do not allow multiple installations to be simultaneously launched while ensuring the successful completion of each.

BRIEF DESCRIPTION OF THE DRAWINGS

0003Embodiments of the present invention will be described by way of exemplary embodiments, but not limitations, illustrated in the accompanying drawings in which like references denote similar elements, and in which:

0004<figref idref="DRAWINGS">FIG. 1</figref> illustrates an overview of various embodiments of the present invention, identifying and executing installations of a plurality of application modules based on installation relationship(s) of the modules, the relationships may be described by a data structure;

0005<figref idref="DRAWINGS">FIG. 2</figref> illustrates a flow chart view of selected operations of the methods of various embodiments of the present invention; and

0006<figref idref="DRAWINGS">FIG. 3</figref> illustrates an example computer system suitable for use to practice various embodiments of the present invention.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

0007Illustrative embodiments of the present invention include, but are not limited to, methods and apparatuses for identifying, by a state machine, a first module installation of a first module of a plurality of modules of one or more applications, at least a subset of the modules each having one or more installation relationships with one or more other modules of the plurality of modules, and the identifying being based at least in part on the first module's installation relationship(s), if any, with the other modules as described by a data structure describing the installation relationships of the plurality of modules. In various embodiments, the state machine may further execute the first module installation and repeat the identifying and the executing for at least a second module installation of a second module of the plurality of modules.

0008Various aspects of the illustrative embodiments will be described using terms commonly employed by those skilled in the art to convey the substance of their work to others skilled in the art. However, it will be apparent to those skilled in the art that alternate embodiments may be practiced with only some of the described aspects. For purposes of explanation, specific numbers, materials, and configurations are set forth in order to provide a thorough understanding of the illustrative embodiments. However, it will be apparent to one skilled in the art that alternate embodiments may be practiced without the specific details. In other instances, well-known features are omitted or simplified in order not to obscure the illustrative embodiments.

0009Further, various operations will be described as multiple discrete operations, in turn, in a manner that is most helpful in understanding the illustrative embodiments; however, the order of description should not be construed as to imply that these operations are necessarily order dependent. In particular, these operations need not be performed in the order of presentation.

0010The phrase “in one embodiment” is used repeatedly. The phrase generally does not refer to the same embodiment; however, it may. The terms “comprising,” “having,” and “including” are synonymous, unless the context dictates otherwise. The phrase “A/B” means “A or B”. The phrase “A and/or B” means “(A), (B), or (A and B)”. The phrase “at least one of A, B and C” means “(A), (B), (C), (A and B), (A and C), (B and C) or (A, B and C)”. The phrase “(A) B” means “(B) or (A B)”, that is, A is optional.

0011<figref idref="DRAWINGS">FIG. 1</figref> illustrates an overview of various embodiments of the present invention, identifying and executing installations of a plurality of application modules based on installation relationship(s) of the modules, the relationships described by a data structure. As illustrated, a computing environment <b>102</b> may include a data structure <b>104</b> and a state machine <b>106</b>, the state machine <b>106</b> adapted to identify installations of modules <b>110</b> of application(s) <b>108</b> based on installation relationships between ones of the modules <b>110</b>. The installation relationships, such as parent-child relationships, may be described by data structure <b>104</b>. The state machine <b>106</b> may further execute identified installations, receive return values from the execution of the installations, and compare the returned values to installation success criteria for the modules to determine whether the installations were successful. Each module <b>110</b> may have its own one or more success criteria, which may be stored in data structure <b>104</b>. In some embodiments, the state machine <b>106</b> may store indicia of the success of installations in one or both of a registry <b>112</b> and a log file <b>114</b>.

0012In various embodiments, computing environment <b>102</b> may comprise one or more of any single- or multi-processor or processor core central processing unit (CPU) computing system. Computing environment <b>102</b> may be or include a personal computer (PC), a workstation, a server, a router, a mainframe, a modular computer within a blade server or high-density server, a personal digital assistant (PDA), an entertainment center, a set-top box, or a mobile device. Each computing system of computing environment <b>102</b> may be capable of operating a plurality of operating systems (OS) in a plurality of virtual machines using virtualization technologies. An exemplary single-/multi-processor or processor core computing system of computing environment <b>102</b> is illustrated by <figref idref="DRAWINGS">FIG. 3</figref>, and is described in greater detail below. Hereinafter, including in the claims, processor and processor core shall be used interchangeable, with each term including the other.

0013In embodiments where computing environment <b>102</b> is comprised of two or more computing systems, the computing systems may be connected by a networking fabric and may each include all or portions of at least one of data structure <b>104</b>, state machine <b>106</b>, application(s) <b>108</b>, modules <b>110</b>, registry <b>112</b>, and log file <b>114</b>. The networking fabric connecting the computing systems may be any sort of networking fabric known in the art, such as one or more of a local area network (LAN), a wide area network (WAN), and the Internet. The computing systems may further use any communication protocol known in the art, such as the Hypertext Transfer Protocol (HTTP), and any transport protocol known in the art, such as the Transmission Control Protocol/Internet Protocol (TCP/IP) suite of protocols.

0014As illustrated, data structure <b>104</b> may be any one or more files of computing environment <b>102</b> capable of storing data relevant to installations of modules <b>110</b>. In some embodiments, portions of data structure <b>104</b>: may be located on a plurality of computing systems of computing environment <b>102</b>. Data structure <b>104</b> may comprise, for example, an extensible markup language (XML) file capable of storing installation information in a nested fashion. In one embodiment, the XML file/data structure <b>104</b> may have a root element corresponding to application(s) <b>108</b>, and may include, nested within that element, further elements for each of the plurality of modules <b>110</b>. Such elements may comprise nodes of a tree structure implemented through XML, with a plurality of branches of the tree structure corresponding to installation relationships of at least some of the modules <b>110</b> with others of the modules <b>110</b>. Each element for a module <b>110</b> may also include, in a nested fashion, other elements for other modules <b>110</b>. Such nested relationships between elements associated with modules <b>110</b> may be indicative of parent-child relationships between the modules <b>110</b>. A parent-child relationship may be one where an installer of one module <b>110</b> (the “parent”) is adapted to spawn one or more installers of other modules <b>110</b> (the “child/children”). The ordering of the elements of the XML file/data structure <b>104</b> may correspond to an ordering of the installations of modules <b>110</b>. In addition to elements corresponding to modules, data structure <b>104</b> may also include one or more success criteria for at least one of the modules <b>110</b>. The success criteria may be represented, for example, as attributes of the module <b>110</b> elements, and may include a value expected to be returned by an installer of a module <b>110</b> upon its execution to indicate success, a registry key and/or registry key value/setting expected to be present in registry <b>112</b> upon a successful installation, and a file version of a successfully installed module <b>110</b>. Additional information may also be stored as attributes of the elements of data structure <b>104</b>, such as values indicating the criticality level of a failed installation of a module <b>110</b>, including “warning” and/or “critical”, and command lines capable of being invoked to execute an installer of the module <b>110</b> associated with the element having the attribute. Although data structure <b>104</b> has been primarily described herein as an XML file, any other data structure known in the art capable of storing the above information and of storing module <b>110</b> ordering and relationships may serve as data structure <b>104</b>.

0015In some embodiments, data structure <b>104</b> may be created by a computing system user. The computing system used to create data structure <b>104</b> may be a computing system of computing environment <b>102</b>, but need not be. In one embodiment, the user may first create a new file, such as an XML file, and may enter all of the XML information, such as the above described elements and attributes. In another embodiment, the data structure may be at least partially generated by an application, such as state machine <b>106</b>, which may be adapted to read plurality of modules <b>110</b>, determine success criteria and installations relationships, and write data structure <b>104</b> to store at least some of the installation information based on the reading. The generated file/data structure <b>104</b> may then be reviewed and edited by a user.

0016As is shown, state machine <b>106</b> may be any sort of process or thread adapted to read data structure <b>104</b>, execute or cause to be executed installations of modules <b>110</b> based on data structure <b>104</b>, write results of the executions to registry <b>112</b> and/or log file <b>114</b>. In some embodiments, state machine <b>106</b> may be further adapted to compare success criteria read in from data structure <b>104</b> to the execution results written by state machine <b>106</b>, and if an installation was unsuccessful, re-execute the installer for the unsuccessfully installed module <b>110</b>. In one embodiment, state machine <b>106</b> may be an ActiveX dynamic link library (DLL), developed, for instance, in the VB.net programming language. In another embodiment, state machine <b>106</b> may comprise an installer wizard/application having a graphic user interface to enable a user to view and/or interact in the installation process.

0017In some embodiments, state machine <b>106</b> may first be initialized. State machine <b>106</b> may be initialized in response to user inputs, such as command line entry or selection of a graphic user interface (GUI) component, may be initialized at start up of a computing system of computing environment <b>102</b>, or may be invoked when a user attempts to install application(s) <b>108</b> based, for example, on a setting electing to use state machine <b>106</b> as a default installer. Upon initialization, state machine <b>106</b> may determine which application(s) <b>108</b> is/are to be installed, and may locate and read a data structure <b>104</b> having information associated with the installations of modules <b>110</b> of application(s) <b>108</b>. The state machine <b>106</b> may receive an indication of the appropriate application(s) <b>108</b> and/or of the data structure <b>104</b> either automatically from another process or through manual user inputs, such as the entry of a file path of the data structure <b>104</b>. Upon receiving an indication of the appropriate data structure <b>104</b>, state machine <b>106</b> may read the data structure <b>104</b> to extract installation ordering and relationships of modules <b>110</b>, and success criteria that may be stored for at least some of the modules <b>110</b>. The data structure <b>104</b> may be completely read all at once, or read incrementally, one element associated with one module <b>110</b> at a time. State machine <b>106</b> may read the information from data structure <b>104</b> into a tree structure, creating a node of the tree for each module <b>110</b>, and using the nesting arrangement of data structure <b>104</b>, described above as a basis for the structure of the tree. State machine <b>106</b> may then also read in a registry hive, registry keys, and capsule names associated with application(s) <b>108</b> and application(s) <b>108</b><i>s</i>' module <b>110</b><i>s</i>' installers, enabling state machine <b>106</b> to read to and write from appropriates keys/portions of registry <b>112</b>. In other embodiments, the above registry information may be obtained by reading through application(s) <b>108</b>, or from another source. In addition to reading the installation information from data structure <b>104</b> and registry information, state machine <b>106</b> may create one or both of registry <b>112</b> and log file <b>114</b> to write installation execution results to. Registry <b>112</b> and log file <b>114</b> may be created or initialized in any sort of manner known in the art, as is described further below.

0018Upon reading data structure <b>104</b>, state machine <b>106</b> may execute installations of modules <b>110</b> in the order set forth in data structure <b>104</b>. For example, state machine <b>106</b> may identify the first module <b>110</b> read from data structure <b>104</b>, and may execute an installer associated with that module <b>110</b>. In some embodiments, executing the installer may involve invocation by the state machine <b>106</b> of a command line. The path of the command line may, in some embodiments, be read from the data structure <b>104</b>. After executing the installer of the first module <b>110</b>, the state machine <b>106</b> may determine if there are additional modules <b>110</b> to install, and identify the next module by reference to the ordering read from the data structure <b>104</b>. State machine <b>106</b> may then execute the installer associated with the next identified module <b>110</b>. The processes of identifying and executing may be repeated until state machine <b>106</b> determines that an installation of the last module <b>110</b> read from data structure <b>104</b> has been executed. In determining both the next installation and whether there are additional modules <b>110</b> to install, state machine <b>106</b> may use a tree structure which may represent the modules <b>110</b>, their installation ordering, and parent-child relationships, such as the tree structure described above. Reference to the tree structure by state machine <b>106</b> may facilitate the state machine <b>106</b> in recognizing parent-child relationships between installations of modules <b>110</b>. For example, upon recognizing that “children” installations of modules <b>110</b> have yet to complete, state machine <b>106</b> may wait until each child installation is complete before proceeding with further installations.

0019Upon executing the installer of each module <b>110</b>, state machine <b>106</b> may write information such as the identity of module <b>110</b>, the command line invoked, and the date and time of execution of the module's installer to registry <b>112</b> and log file <b>114</b>. State machine <b>106</b> may also write a value indicating whether installation has been attempted to registry <b>112</b> and/or log file <b>114</b>. The value may simply be a binary value, or may be a counter indicating a number of times installation has been attempted. Also, state machine <b>106</b> may receive a return value from each installer after its invocation which may be indicative of success or failure. To determine whether each installation is successful, state machine <b>106</b> may compare the return value to an expected return value of the success criteria, in one embodiment. In other embodiments, rather than comparing the return value to one of the success criteria, state machine <b>106</b> may check for the presence of one of the success criteria, such as a registry key or a file version, after executing an installation. For example, if a certain setting in registry <b>112</b> is associated with a successful installation, state machine <b>106</b> may check the setting to determine whether installation was successful.

0020If the comparison indicates that the installation was successful, state machine <b>106</b> may write a value to registry <b>112</b> and log file <b>114</b> indicating success, and may remove the node from the tree structure associated with the module <b>110</b> determined to have been successfully installed. If the comparison indicates that the installation was unsuccessful, state machine <b>106</b> may write a value to registry <b>112</b> and log file <b>114</b> indicating failure. In one embodiment, data structure <b>104</b> may include a criticality level for at least one of the modules <b>110</b>, as described above. State machine <b>106</b> may be adapted to read the criticality levels into the tree structure, and upon determining that an installation has failed, state machine <b>106</b> may check the criticality level of the installation-failed module <b>110</b> to determine whether the criticality level is “warning” or “critical.” If “warning”, state machine <b>106</b> may continue to identify and execute further module <b>110</b> installations and may remove the node from the tree structure associated with the module <b>110</b>. If “critical”, state machine <b>106</b> may halt all installation processes and, in some embodiments, uninstall one or more of the module <b>110</b> of application(s) <b>108</b> that have been installed thus far. In such an event, state machine <b>106</b> may also clear registry <b>112</b> and build log <b>114</b> of information written during the installation processes.

0021Upon determining that an installation of each module <b>110</b> has been executed by reference to the tree structure (which should be empty of nodes), state machine <b>106</b> may read through registry <b>112</b> and/or log file <b>114</b> to determine whether each module has been successfully installed. If state machine <b>106</b> encounters any module <b>110</b> which is associated with a failed installation, state machine <b>106</b> may retrieve the command line associated with that module and re-execute it. If the module <b>110</b> is associated with a counter value tracking the number of times installation has been attempted, as described above, state machine <b>106</b> may read the counter from the registry <b>112</b> and/or log file <b>114</b>, increment the counter value by one, and write the incremented counter value to the registry <b>112</b> and/or log file <b>114</b>. State machine <b>106</b> may perform the re-execution of the installation and testing of installation success in the manner described above. After re-executing the installation, determining its success, and writing to the registry <b>112</b> and/or log file <b>114</b>, state machine <b>106</b> may continue to identify and re-execute previously failed installations. Upon determining that all modules <b>110</b> have been successfully installed, state machine <b>106</b> may halt.

0022As illustrated, application(s) <b>108</b> may be any sort of application(s) known in the art having a plurality of modules <b>110</b>. Application(s) <b>108</b> may be comprised of any number of source files, object files, libraries, and executables capable of being installed on a computing system of a computing environment <b>102</b>. Exemplary application(s) <b>108</b> may include platforms, core operating system (OS) applications, application suites, custom groups of applications, and hot-fixes. In one embodiment, application(s) <b>108</b> may already be installed, and state machine <b>106</b> may simply maintain the application(s) as a single image build by installing a new module <b>110</b> of the application(s) <b>108</b> or by installing an updated version of an already-installed module <b>110</b>, thus maintaining application(s) <b>108</b> without requiring the recompiling of the entire application(s) <b>108</b>.

0023As is shown, the plurality of modules <b>110</b> of application(s) <b>108</b> may be installed in a chained fashion in a manner based at least in part on installation relationships between ones of the modules, the relationships described by data structure <b>104</b>. Each of the modules <b>110</b> may correspond to an installer executable invokable by a user input, such as the entry of a command line providing the path of the executable or a click on an indicator icon. Also, as described above, the plurality of modules <b>110</b> may correspond to one of a plurality of applications <b>108</b>. For example, module <b>110</b> may be the only module for an application <b>108</b>, may be shared between multiple applications <b>108</b>, or may be one of a plurality of modules <b>110</b> of one application <b>108</b>. Further, each module <b>110</b> may be associated with one or more success criteria, such as one or more of a success code returned upon execution of an installation, a registry key, and a file version. As described above, these criteria may be included in data structure <b>104</b>, and upon execution of the installer associated with each module <b>110</b>, a success code may be returned, or a registry key/file version may be checked for by the state machine <b>106</b>, as described above. Registry keys that may be checked for may be keys associated with a successful installation of a module <b>110</b>, and file versions that may be checked for may be, for example, a most recent version of a particular file of a module <b>110</b>. Success codes returned subsequent to an execution may indicate either a success or a failure of the execution.

0024In various embodiments, the registry <b>112</b> of computing environment <b>102</b> may be a database or similar file capable of storing settings, options, and installation results for at least one of the plurality of modules <b>110</b>. For example, registry <b>112</b> may be a Windows OS registry for a 32-bit, a 64-bit, or a mobile version of a Windows OS, and may store information and settings for hardware, software, users, and preferences for a computing system, including installation results for modules <b>110</b> of application(s) <b>108</b>. Registry <b>112</b> may be organized into a plurality of “keys”, which may in turn have a plurality of sub keys, which may in turn include further sub keys, and so on. Each key or sub key may store one of more of a string value, a binary value, a DWORD value, a multi-string value, and an expandable string value. In some embodiments, registry <b>112</b> may be dynamically created by state machine <b>106</b> to store values related to the installations of modules <b>110</b>, while in other embodiments, registry <b>112</b> may simply be provided to computing environment <b>102</b> and utilized by state machine <b>106</b>. As mentioned above, state machine <b>106</b> may store values indicating the success or failure of an installation of a module <b>110</b>, a criticality level of that module, a number of times installation has been attempted (or an indicator of whether installation has been attempted), a file version, etc., in a key/sub key of registry <b>112</b>.

0025In some embodiments, log file <b>114</b> may be any sort of file capable of storing at least a representation of each module <b>110</b> and an indicator of whether an installation of that module <b>110</b> was successful. In one embodiment, log file <b>114</b> may store one or more of a criticality level of the module, as described above, a number of times installation has been attempted, a registry <b>112</b> key having installation information, and a file version. Such information may be stored in any fashion known in the art within log file <b>114</b>. In various embodiments, log file <b>114</b> may be created in advance, and may be written to be state machine <b>106</b>, while, in other embodiments, log file <b>114</b> may be dynamically created by state machine <b>106</b> prior to performing any module <b>110</b> installations. In one embodiment, log file <b>114</b> may be stored on any computing system of computing environment <b>102</b>, in any folder of a file system of the computing system. As mentioned above, state machine <b>106</b> may store values indicating the success or failure of an installation of a module <b>110</b>, a number of times installation has been attempted (or an indicator of whether installation has been attempted), a criticality level of that module, etc., in log file <b>114</b>.

0026<figref idref="DRAWINGS">FIG. 2</figref> illustrates a flow chart view of selected operations of the methods of various embodiments of the present invention. As illustrated, in some embodiments, a state machine of a computing environment may identify a module installation of one of a plurality of modules of one or more applications, and may execute that installation, blocks <b>202</b>-<b>204</b>. The one or more applications to be installed by the state machine may include a platform, an application suite, a custom group of applications, a single application, and/or a hot-fix, in various embodiments. As described in greater detail above, the state machine may identify the module based on installation relationships between at least some of the plurality of modules described by a data structure, block <b>202</b>. The data structure, in one embodiment, may be a tree structure implemented by an XML file. The data structure may further describe parent-child installation relationships between installers of some of the modules, and may include success criteria for at least some of the module installations, such as return values expected, registry keys, and file versions. Upon identifying the appropriate module installation, the state machine may execute the module installation, block <b>204</b>. In one embodiment, a module installation may be invoked to be executed through a command line.

0027In various embodiments, the state machine may receive a return value from each installer upon execution of each module installation, block <b>206</b>. The return value may indicate success or failure of a given module installation. Upon receiving the value, the state machine may compare the return value, or another metric, to the above described success criteria to determine whether a given module installation was successful, block <b>208</b>. If the success criteria include an expected return value, the state machine may compare the received return value to the expected. If on the other hand the success criteria include only a registry key or file version, the state machine may verify the file version and/or presence of the registry key. In one embodiment, once the comparison has been performed, the state machine may write the results of the comparison to a registry key or keys and/or a log file, block <b>210</b>.

0028If, at decision block <b>212</b>, the state machine has determined that a module installation was not successful, the state machine may determine the criticality level of the installation, which may also have been stored in the above-described data structure, block <b>214</b>. The criticality level, in some embodiments, may be one of “warning” and “critical.” If the criticality level is determined to be “critical”, the state machine may halt installation of further modules of the plurality of modules, block <b>216</b>.

0029As is shown, however, if the installation is successful, or is unsuccessful but has a criticality level of “warning”, the state machine may next determined whether there are any additional modules needing to be installed, decision block <b>218</b>. The state machine may make the decision by reference to a tree structure created by the state machine based on the data structure input. After each module installation, a node of the tree associated with that module may be removed from the tree. If there are additional modules remaining, the state machine may repeat the above described operations, blocks <b>202</b>-<b>218</b>. If, on the other hand, the state machine determines that installations of each module of the plurality of modules have been executed, the state machine may iterate through the log file and/or registry keys, block <b>220</b>, to determine if any of the module installations have failed. If any of the installations have failed, decision block <b>222</b>, the state machine may repeat the above described operations, blocks <b>202</b>-<b>222</b>, for the unsuccessfully installed modules.

0030<figref idref="DRAWINGS">FIG. 3</figref> illustrates an example computer system suitable for use to practice various embodiments of the present invention. As shown, computing system <b>300</b> includes a number of processors or processor cores <b>302</b>, and system memory <b>304</b>. For the purpose of this application, including the claims, the terms “processor” and “processor cores” may be considered synonymous, unless the context clearly requires otherwise. Additionally, computing system <b>300</b> includes mass storage devices <b>306</b> (such as diskette, hard drive, compact disc read only memory (CDROM) and so forth), input/output devices <b>308</b> (such as keyboard, cursor control and so forth) and communication interfaces <b>310</b> (such as network interface cards, modems and so forth). The elements are coupled to each other via system bus <b>312</b>, which represents one or more buses. In the case of multiple buses, they are bridged by one or more bus bridges (not shown).

0031Each of these elements performs its conventional functions known in the art. In particular, system memory <b>304</b> and mass storage <b>306</b> may be employed to store a working copy and a permanent copy of the programming instructions implementing the various components, such as the state machine, the data structure, and so forth, herein collectively denoted as <b>322</b>. The various components may be implemented by assembler instructions supported by processor(s) <b>302</b> or high-level languages, such as C, that can be compiled into such instructions.

0032The permanent copy of the programming instructions may be placed into permanent storage <b>306</b> in the factory, or in the field, through, for example, a distribution medium (not shown), such as a compact disc (CD), or through communication interface <b>310</b> (from a distribution server (not shown)). That is, one or more distribution media having an implementation of the agent program may be employed to distribute the agent and program various computing devices.

0033The constitution of these elements <b>302</b>-<b>312</b> are known, and accordingly will not be further described.

0034Although specific embodiments have been illustrated and described herein, it will be appreciated by those of ordinary skill in the art that a wide variety of alternate and/or equivalent implementations may be substituted for the specific embodiments shown and described, without departing from the scope of the embodiments of the present invention. This application is intended to cover any adaptations or variations of the embodiments discussed herein. Therefore, it is manifestly intended that the embodiments of the present invention be limited only by the claims and the equivalents thereof.