CN106575227B

CN106575227B - Automatic software update framework

Info

Publication number: CN106575227B
Application number: CN201580039273.XA
Authority: CN
Inventors: J.本奇; R.弗兰克; D.谢菲尔德; D.巴龙
Original assignee: Rimini Street Inc
Current assignee: Rimini Street Inc
Priority date: 2014-06-04
Filing date: 2015-06-04
Publication date: 2021-01-05
Anticipated expiration: 2035-06-04
Also published as: US10509639B2; EP3152654A1; CA2953212C; CN106575227A; WO2015187907A1; US20150355896A1; EP3152654A4; EP3152654B1; CA2953212A1

Abstract

An automated framework for providing updates in a distributed environment includes various elements. The framework provides tasks, such as software updates, to the client environment. Updates can be developed and tested for a client environment. The update may be reduced to a set of data that can be used to create an update for other client environments that include the same version of the program. Further, a respective script may be generated for each client environment based on the particular client environment.

Description

Automatic software update framework

Technical Field

The present invention describes providing software updates in a network environment.

Background

Software programs are available for performing a wide variety of operations. Typically, a portion of the software program is altered to modify the operation, and these alterations may be implemented using software updates. For example, a software program may rely on information that may be altered, such as laws, tax proportions, and regulations, and updates may be provided to the software program to effect changes in these types of information.

Sometimes multiple different client environments include the same version of the software program so that a particular update should be created for each client environment.

Disclosure of Invention

Embodiments of the present invention are directed to a framework that provides tasks, such as software updates, to a client environment. Updates can be developed and tested for a client environment. The update may be reduced to a set of data that can be used to create an update for other client environments that include the same version of the program. Further, a respective script may be generated for each client environment based on the particular client environment.

One embodiment of the invention includes a computer-readable storage medium storing information that, when executed by one or more computing devices, performs operations for updating software in a distributed environment. The operations include receiving, by a server accessible over a secure network, a task tailored to a client environment and storing the task in a secure account dedicated to the client environment. The operations also include receiving a request for secure account authentication from an automation task manager running on a client device in the client environment to send a task. The task is transferred to the automated task manager and the status of the task is updated.

In one embodiment, the operations further comprise monitoring, by the task monitoring module, the security account to determine when the task is queued in the security account and when the task is transmitted to the task manager. Further, the operations may include presenting a task monitoring user interface in communication with the task monitoring database and presenting the status. In another embodiment, updating the state includes changing the state from a pending state to an active state by the task monitoring module when the task is communicated to the task manager. Additionally, the operations may further include receiving a message from the automation task manager that the task completed successfully, such that the update in the status includes picking up the message by the task monitoring module and transitioning the status from the active to the successfully completed status. In another embodiment, the task monitoring user interface provides a selectable link that, when selected, exposes the content of a message received from the automated task manager. In another embodiment, the operations further comprise receiving a message from the task manager indicating that the task was not successfully completed. Further, the task monitoring module may pull a message from the security account and update the status to include a failure status, the content of the message being visible in the task monitoring user interface.

Another embodiment of the invention includes a method or process for updating software in a distributed computing environment. The method or operations may include automatically determining whether the task is queued by sending a request to a secure account stored on a server accessible to a secure network in the server environment. The task is received from a secure network accessible server hosting (host) a secure account, and the task is received by a task manager running in a client environment. The operations also include routing the task to a handler (handler) program that runs in the client environment and executes the task. The handler program generates a message describing whether the task completed successfully, and passes the message from the handler program to the task manager. A message is sent to a secure network accessible server to provide a status of the task.

In one embodiment, a method or operation includes other elements. For example, the task may include updating a software program running in the client environment such that the handler program performs the task by converting the software program to include the update. In another embodiment, updating the software program running in the client environment includes creating a pre-update folder in the client environment and populating the pre-update folder with the first version of the software program to be updated. Additionally, the operations may further include calculating a hash value of the first version of the software program and transmitting the hash value to a server running in the server environment. In another embodiment, the operations further comprise creating a post-update folder in the client environment and populating the post-update folder with a second version of the software program to be updated and substantially similar to the first version of the software program. Thus, updating the software program running in the client environment may include converting the second version of the software program in the folder after the update to include the update, thereby converting the software program to an updated software program. In yet another embodiment, the operations further comprise generating a data set by comparing the first version of the software program in the pre-update folder to the updated software program in the post-update folder, and transmitting the data set to a secure network accessible server in the server environment. The data set may be encoded to create an encoded data set that is transmitted to a secure network accessible server of other client environments to be made available to run the same program modules as the first version of the software program. The other client environment may then utilize the encoded data to convert the first version of the software program into an updated software program.

Another embodiment of the invention includes a system for automatically updating a computing component of a computer software program in a distributed environment. The system includes a computing device storing a security account maintained in a server environment and storing tasks to be performed in a client environment. Further, the system includes a computing device running an automated task manager that runs in the client environment and automatically retrieves the task by sending a request to the secure account. A handler runs in the client environment, which receives tasks from the automation task manager and executes the tasks in the client environment. The handler provides a message indicating whether the task completed successfully and was provided to the secure account. The system also includes a task monitoring module running in the server environment that picks up messages from the secure account and stores the messages in a task monitoring database.

The system may also include other aspects, such as a task monitoring user interface that accesses a task monitoring database and presents status updates indicating whether a task completed successfully in the client environment. In one embodiment, the status update is presented with a client identifier that is unique to the client environment. The system may also include a client-side program file structure that maintains and stores one or more code files in the client environment that include program code that is executed to run the program. Further, the server-side program file structure may be maintained in file sharing of the server environment that is substantially mirrored in the organization of the client-side program file structure. In another embodiment, the server-side program file structure stores one or more hash files representing program code.

Embodiments of the invention are defined by the following claims, rather than by the foregoing summary. A high-level overview of various aspects of the invention is provided herein to introduce a selection of concepts that are further described below in the detailed-description section. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used as an aid in isolation to determine the scope of the claimed subject matter.

Drawings

Illustrative embodiments of the invention are described in detail below with reference to the attached drawing figures, which are incorporated herein by reference:

FIG. 1 depicts a diagram of an exemplary network, according to an embodiment of the invention;

FIG. 2 depicts a diagram of an exemplary network, according to an embodiment of the invention;

FIG. 3 depicts an exemplary client environment folder structure, according to an embodiment of the invention;

FIG. 4 depicts an exemplary file sharing folder structure, according to an embodiment of the invention;

FIGS. 5 and 6 each depict a respective flow diagram illustrating operations or steps according to embodiments of the invention; and

FIG. 7 depicts an exemplary computing environment, according to an embodiment of the invention.

Detailed Description

The subject matter of embodiments of the present invention is described with specificity herein to meet statutory requirements. The description itself is not intended to necessarily limit the scope of the claims. Rather, the claimed subject matter might be embodied in other ways to include different steps or combinations of steps similar to the ones described in this document, in conjunction with other present or future technologies. Unless and except where the order of individual steps is explicitly described, the terminology should not be interpreted as implying any particular order among or between various steps herein disclosed.

At a high level, embodiments of the present invention are directed to a framework that provides tasks, such as software updates, to a client environment. Tasks may be developed and tested for a client environment. This task can then be reduced to a set of data for creating updates for other client environments that include the same version of the program. To help illustrate these aspects, FIG. 1 provides a diagram illustrating a basic client-server architecture 10 in which a software program update service 12 interfaces with a plurality of

client environments

14, 16, 18, and 20. The client environment may be client-hosted or may be hosted by a third party and, in either case, authenticates the service 12 to the client environment. Although architecture 10 depicts four client environments A, B, C and D, the architecture may include any number of client environments.

Each client environment runs a software program and some clients run the same version of the software program. For example, both client environment A14 and client environment B16 run version 1 software programs (22 and 24, respectively), while client environment C18 runs version 2 software program 26. Software program 28 is identified as version "N" to indicate that "N" may be replaced by any integer to specify a particular version.

In an embodiment of the present invention, the software program update service 12 provides tasks to be performed in the respective client environment. As used in this description, a "task" includes a computing operation to be performed. Examples of tasks include applying updates to a software program, creating one or more folders in a folder structure, generating scripts, and packaging updates, and the like, and typically these tasks are performed in the context of maintaining or updating a software program. In fig. 1, service 12 hosts secure client accounts 30, 32, 34, and 36 for each client. When the task is ready for the client environment, the task is uploaded to a corresponding account of the client environment. For example, when a task is ready for the client environment A14, the task is uploaded to the secure client account A30.

In fig. 1, each client environment runs a client-side task manager configured to access a respective client account. For example, the client-side task manager 38 is configured to access the secure client account A30 in order to retrieve tasks of the software program 22. In embodiments of the present invention, the same task may be provided to both client environment A14 and client environment B16, since both client environments run the same version of the

software programs

22 and 24. Thus, the tasks of client environment A14 may be developed and tested for client environment A and then automatically pushed out to client environment B. The structure 10 depicted in fig. 1 is of a relatively high-level, and may include various other components for providing the above-described functionality as well as additional features, such as those depicted in fig. 2.

Referring now to FIG. 2, a diagram is provided that depicts a client-server environment 110 that includes a software program update service 112 networked with a client environment 114. The update service 112 is similar to the update service 12 described in FIG. 1, except that additional components of the service are depicted in FIG. 2. Further, client environment 114 is similar to the client environment described in FIG. 1, except that additional components are depicted in FIG. 2.

In FIG. 2, the update service 112 includes a workstation 116, such as a desktop, laptop, or other computing device. The workstations may be used to access and communicate with other components of the update service 112, including a secure web server 118 that hosts a secure web account 119, a task monitor 120, and a task development module 122. Although some components of update service 112 are depicted as single components, any component may include multiple devices, such as multiple workstations, multiple servers, or multiple databases. Further, one or more components depicted as part of the update service may be running on the virtual machine.

The task development module 122 provides access to a database 138, the database 138 storing information describing each client environment (e.g., client environments A-D depicted in FIG. 1). Database 138 stores information describing software program versions, client folder organization, code object lists, and various other information. At a high level, a developer at the workstation 116 creates and tests tasks using the task development module 122. Using the workstation 116, the tasks may be uploaded to a secure network account 118 and made available to the client environment 114.

The server-side task monitor 120 tracks the status of tasks, including whether tasks were retrieved by the client environment 114 and whether tasks were successfully installed. For example, the task monitor 120 picks up a message (e.g., a request) provided from the client-side task manager 126 to the secure network account 119 and passes the message to the appropriate one of the handlers 121. Messages or other information picked up by the task monitor 120 are stored in the task monitoring database 140, such as in a database row. The task monitoring database 140 may be accessed via the workstation 116 using the task monitoring user interface to view the status of the tasks and messages picked up from the secure network account 119. In one embodiment, the task monitor user interface accesses the database row directly.

After the task has been published to the secure account 119, the status of the task may be viewed by accessing a user interface of the task monitor 120. Examples of states include "pending", "active", "successful", and "failed". The "pending" status indicates that the task is currently issued to the secure account and queued for processing. The "active" state indicates that the task has been sent to the client-side task manager 126 and is being processed in the client environment. The "successful" state indicates that the task has completed normally. The "failed" state indicates that the task terminated with an error message. Messages related to a task may be filtered based on various criteria such as duration (e.g., showing all messages within the past N hours or N days). In the case where the same task is provided to two different client environments, messages related to the task may be grouped and may be based on client selection.

In another embodiment, file shares 123 are maintained by update server 112, and file shares 123 include a folder structure similar to the folder structure in each client environment (e.g., client environments A, B, C and D in FIG. 1). As will be explained in more detail in other portions of this detailed description, file share 123 may be used to help determine which clients are using which versions of a software program. That is, in one aspect of the present invention, the client folder structure retains and stores deliverables that may be referenced for less access by the update service 112. Thus, rather than analyzing actual client deliverables, file shares 123 are maintained to help track which updates have been made in the client environment. File share 123 may also be used to identify a group of clients running the same version of a software program. The folder structure in file share 123 may contain, among other information, an additional set of client-level folders to summarize all clients affected by the update. In one embodiment, the folders in file share 123 include only hashed representations of the program modules, rather than the actual program modules. In this embodiment, there is no need to maintain software or code from any client environment on the file share 123.

Having described some details of the update service 112, the client environment 114 will now be described in more detail. The client environment 114 includes a cloud-based environment hosted by the client or having one or more computing devices 124 running various applications. For example, the computing device 124 runs a client-side task manager 126,

client handler programs

128, 130, and 132, and a software program 134 that utilizes information stored in a software program database 136. At a high level, the task manager 126 automatically checks the secure network account 119 used by the updated service 112 to determine if any tasks are available to the client environment 114. If the task is available, the task manager 126 receives the task from the secure web server 118 and passes the task to the appropriate client handler program.

As previously described, a task may include various types of operations, and an appropriate client handler program is selected based on the operations. For example, the handler program 128 may be configured to apply updates to the software program 134. Each other handler program may be configured to perform other operations, such as creating or updating folders, creating update scripts, or packaging updates. The appropriate handler program performs the task and provides a message (e.g., a request) from the task manager 126 to the secure network account 119. Although only three

handler programs

128, 130, and 132 are depicted in fig. 2 for illustrative purposes, any number of handler programs may be included for performing various desired operations. The

handler programs

128, 130 and 132 are described in additional detail in other parts of this description. Once the message has been provided from the task manager 126 to the secured web account 110, the update service task monitor 120 may pick up the message from the secured web account 119 and pass it to the appropriate one of the server-side handlers 121.

Having described an overview of some operations performed in the environment 110, some additional aspects, such as how tasks are created in the update service 112 and how tasks are performed in the client environment, will now be described with reference to fig. 1 and 2. In some embodiments, the updates to be made to the software program 134 will include modifications to the batch program or code objects. Thus, using the workstation 116, each affected client environment is identified in the task development module 122. That is, the task development module 122 provides a graphical user interface that allows the workstation 116 to select clients, identify objects, and retrieve other information from the database 138. For example, if the

software programs

22 and 24 that affect version 1 are updated, the client environment A14 and the client environment B16 are affected clients. Thus, client environment A14 and client environment B16 are selected to be within the scope of the update. In addition, code objects that reside and are to be affected in the client environment are also identified by accessing the database 138. For example, database 138 stores a list of objects in the client environment, such as SQR/SQC and COBOL. Those objects listed may be selected as part of the update.

Once the affected clients and code have been identified in the task development module 122, the create update folder tool 150 is used to generate tasks (e.g., request files) that are placed in the appropriate secure network client account 119. The task instructs each affected client to create and update folders in the client environment for updating software program 134. For example, if the client environments A14 and B16 are affected, the task is uploaded to the secure client account A30 and the task is uploaded to the secure client account B32. In one embodiment, the create update folder tool 150 allows all or a subset of the affected clients to be selected. In addition, the create update folder tool 150 allows selection of all or some of the affected program modules listed in the code object.

Each task is then retrieved by the corresponding client-side task manager 126, and the client-side task manager 126 passes the task to the

appropriate handler program

128, 130 or 132 running in the client environment (e.g., create update folder handler). Tasks may be routed through the task manager 126 based on various criteria, such as the format or header information of the task file. The

handler program

128, 130 or 132 then creates and updates folders in the corresponding client environment, such as on a development machine running in the client environment. In one embodiment, the create update folder handler creates a "before" folder and a "after" folder.

In another embodiment, the folder structure created by the

handler program

128, 130, or 132 is based on the type of program module affected by the update (e.g., the program module identified in the request file). The first type of program modules include COBOL programs, DMS scripts associated with COBOL-stored SQL statements, and SQR/SQC program modules. These may all be categorized as batch program modules. Another type of program module involves a DMS script that is used to update a data table that controls the operation of the software program. These are typically not permanent parts of the software program, but are used when installing updates on the client system. Other types of modules exist, such as object-oriented code that is online or batch processed.

These different types of program code may be stored in different locations within a folder structure in client environment 114. An exemplary folder structure 310 involving elements from all three levels is shown in FIG. 3; however, some updates may only contain a subset of these elements. In one embodiment, a similar folder structure is located on each client environment affected by a particular update, and most of the program code stored in the folder structure is associated with the specified client and update.

In FIG. 3, the SQR/SQC program, COBOL program, and DMS script associated with COBOL stored SQL statements are stored under the "CODE" folder. In addition, there will be "Before" and "After" versions of program source Code stored in the "Code _ Before" and "Code _ After" folders. If the update involves a new program that was not previously included with the software program, there will be no "previous" version of that program.

The DMS script used to update the DATA table will be stored in the "DATA" folder. The online Code to be modified by the update will be stored in the "Code _ Before" and "Code _ After" folders under the "PROJECT" folder. The "PRJHCNNnnnn" folder will contain the item export file.

Once the appropriate "before" and "after" folders have been created in the client environment, the client-side handler program (e.g., 128, 130, or 132) populates these development folders with the version of the program object selected prior to implementing the update. In some embodiments, program objects are copied from different folders on the client to the development folder. In other embodiments, the code objects may be extracted, such as from the software program database 136, and placed in an appropriate folder in the client environment.

After all the previous code is collected, the create update folder handler calculates the hash value of the collected program files and generates a return request that is loaded back to secure account 119 to be picked up by update service task monitor 120. The return request includes the hash value and file name, which are used to establish a substantially similar folder structure and client folder on file share 123 (as previously described). Each return request from each client environment will allow its own respective client-level folder to be built on file share 123 and populated with the hash file.

An example of a folder structure that may be established in file share 123 is depicted in FIG. 4. The folder structure reflects the combination of associated folders on all client environments and describes a complete list of clients affected by the update. The folder contents include the same file name as stored in the corresponding folder in the client environment, except that the files in the file share 123 have an additional file extension ". hsh" indicating that they are "hash files".

The hash file does not contain any actual source code. Instead, each contains only the "hash value" computed over the client environment by computing the standard MD5 hash value using the actual file content. The MD5 hash value is a unique 32-byte value calculated by industry standard routines that produces a value unique to the contents of that particular file. Since the MD5 hash values calculated for the same file will also be the same, the hash values can be used to identify which clients have the same program version by comparing their respective hash values. If the hash values on file share 123 are the same, then the program modules in the client environment are the same.

In another embodiment, to implement the update, it may be appropriate for the client environment to generate a script that may be used to update the tabular data (e.g., tax table data). Accordingly, the generated data modification tool 152 is used by the workstation 116 to create tasks. When the generate data change tool 152 is used, an update is selected and the retrieved change data is included as part of the task instructions loaded into the account(s) of the affected client environment(s). A task is then run in each of these client environments, with the task manager 126 passing the task to a production data change handler program (e.g., one of the

handler programs

128, 130, or 132) running in the client environment 114. The generate data change handler program then generates an SQL script to update the table. As previously described, the requested file is provided back to the secure account 119 and pulled by the update service task monitor 120 with the appropriate folder structure information and hash value.

As previously described, the status of the create update folder task or the generate data change task may be monitored. Once the corresponding folder structure has been created in each client environment affected by the update, the task development module 122 may create a summary report to verify that the affected client environment has not reported any missing program modules and successfully received the hashes for each program module.

Code modifications from one client environment may be applied to the same program modules in another client environment using a folder structure in place in the affected client environment. For example, application differencing tasks may be created and loaded to selected secure accounts 119 to identify code modifications that have been made in one client environment and that may be federated to (syncdicate) other client environments. The task manager 126 of the selected client environment requests the application of the differentiated task and passes the task to the appropriate handler program (i.e., one of the

handler programs

128, 130 or 132). In one embodiment, the handler program modifies the program modules already stored in the "after" folder to include the update. Further, the handler may generate a set of data representing the difference between the original code and the updated code. The data set may be created by determining which characters in the code have been changed on a character-by-character basis using a software tool that compares program modules in the "before" folder to modified program modules in the "after" folder. The data set may then be provided back to the update service for use as a record of changes associated with a given update. In one embodiment, the data set may then be used to update other client environments with the same version of the program.

In another embodiment, the data set of the difference between before and after recording is encoded in a manner that avoids directly indicating changed characters. An exemplary encoding method encodes a data set by applying an encryption key that relies on the unchanged characters in the code. Because the encoding method is based on the code itself, other client environments with the same version of the program may decrypt the encoded data set and apply the changes indicated by the data. Decoding the encoded data set may include various strategies. In one embodiment, the encoded data set may include instructions for replacing the characters affected by the update ("dynamic characters") with characters at other locations in the code ("static characters"). For example, the encoded data set may reflect the location of the dynamic character. For each such dynamic character, the data set may also identify the location of the static character that matches the updated value of the dynamic character. The code may be updated using the encoded data set by replacing the values of the dynamic characters with the values of their associated static characters.

As previously described, the client-side program handlers "create update folder", "generate data changes", and "apply differences" work on code and/or data modifications for a single update. In other embodiments, individual updates for a client may be delivered in an update package, which may contain one or more individual updates. In one embodiment, the workstation 116 utilizes the create update tool 154 to create tasks. When the create update tool 154 is used, an update package is selected, and then the affected client environment is selected. A list of individual updates to be packaged together based on the attributes of each particular client environment (e.g., what updates they assume are to receive based on their tax jurisdiction, release, etc.) is included as part of the task instructions loaded into the accounts of the affected client environments by the create update tool. Tasks are then run in each of these client environments, with the task manager 126 passing the tasks to the appropriate client-side create update handler. The create update handler then retrieves the code, project, and data change scripts to be delivered, combines them into an update package, and places the update package in a staging area (staging area) of the client environment, ready for automatic installation and manual testing by a quality assurance tester.

Code and/or data modifications may be tested in one of the client environments with separate updates and/or update packages at appropriate locations in the client environment. In another embodiment, the workstation 116 utilizes the application update tool 156 to create tasks. When using the application update tool 156, an update (individual or package) is selected, and then the affected client environment is selected. The task instructions are loaded into the account of the affected client environment. Tasks are then run in each of these client environments, with the task manager passing the tasks to the client-side application update handler. The handler then retrieves the update code, items, and data modification scripts, copies these objects to the test area of the client environment, and automatically installs the code and/or data modifications. When the update includes a data change script, a report is created by comparing data before the update is installed with data after the update is installed. When the update includes a program code modification, a report is created by comparing the code in the "before" folder with the code in the "after" folder after the update is installed. Quality assurance testers may use these reports to help verify the correctness of the updates.

In another embodiment, the document generation tool 158 produces a document that is customized for each delivered update for each client environment. The document generation tool 158 takes the master document template as input and then outputs a separate set of documents for each selected client. The document template contains various tags such as update id, client code, application release, module release, tax jurisdictions, and the like. Based on the attributes of each particular client (e.g., based on their tax jurisdiction, release, etc., what updates they assume to receive), the utility generates the appropriate documents.

In another embodiment, the software package validation tool 160 checks the consistency between the generated document and the actual updates to be delivered to the client. The software package validation tool 160 performs various checks such as validating documents, validating updates, and validating items. Validating the file includes checking to ensure that all files contained in the package are also in the document, and vice versa. Verifying the update includes checking to ensure that the code contains an enhanced signature of the update listed in the document. Validating the item includes checking to ensure that all online objects in the package are also in the document, and vice versa. The software package validation tool will indicate that there are any inconsistencies to correct for before delivery.

Document generation tool 158 and software package verification tool 160 automatically generate documents customized to each client and verify that the documents are synchronized with deliverables (deliverables). That is, there are no deliveries that are not documented, and no deliveries are not documented.

Referring now to FIG. 5, a flowchart is depicted that includes a series of steps or operations performed in accordance with an embodiment of the present invention. The series of steps in FIG. 5 includes a method or process 510 of updating software in a distributed computing environment. The present invention may be embodied as a computer-implemented method including the steps summarized in FIG. 5. The invention may also be embodied as a computing device programmed to perform the operations outlined in FIG. 5. In another embodiment, the invention includes a computer storage device storing computer-executable instructions that, when executed by a computing device, perform method 510. When describing the method 510, reference is also made to fig. 1 and 2.

In method 510, step 512 includes receiving, by a secure network-accessible server, a task customized for a client environment. For example, the server 118 receives tasks that have been created using the workstations 116, which utilize the task development module 122. At step 514, the task is stored in a secure account dedicated to the client environment. For example, the task is stored in a secure account 119 dedicated to the client environment 114. In one embodiment, the secure network accessible server comprises an internet-accessible FTP server, and the secure account is an FTP account.

Step 516 includes receiving a request to send a task for secure account authentication from an automation task manager running on a client device in the client environment. For example, a request is received from the task manager 126 to send a task. In step 518, the task is transferred to the automated task manager. And step 520 includes updating the state of the task.

The steps of method 510 may include other steps or elements. For example, in one embodiment, the operations further comprise monitoring, by the task monitoring module, the security account to determine when the task is queued in the security account and when the task is transmitted to the task manager. Further, the operations may include presenting a task monitoring user interface in communication with the task monitoring database 140 and presenting the status. In another embodiment, the updating at step 520 includes changing the state from a pending state to an active state by the task monitoring module when the task is communicated to the task manager. In addition, operation 510 may also include receiving a message from the automation task manager that the task completed successfully, such that the updating in step 520 includes picking up the message by the task monitoring module and transitioning the status from the active to the successfully completed status. In another embodiment, the task monitor user interface provides a selectable link that, when selected, exposes the content of a message received from the automated task manager. In another embodiment, operation 510 further comprises receiving a message from the task manager indicating that the task was not completed successfully. In addition, the task monitoring module may pull a message from the secure account and update the status to include a failed status, the content of the message being visible in the task monitoring user interface.

Referring now to FIG. 6, a flowchart is depicted that includes a series of steps or operations performed in accordance with an embodiment of the present invention. The series of steps in FIG. 6 includes a method or process 610 of updating software in a distributed computing environment. The present invention may be embodied as a computer-implemented method including the steps summarized in FIG. 6. The invention may also be embodied as a computing device programmed to perform the operations outlined in FIG. 6. In another embodiment, the invention includes a computer storage device storing computer-executable instructions that, when executed by a computing device, perform method 610. When describing the method 610, reference is also made to fig. 1 and 2.

Step 612 includes automatically determining whether the task is queued by sending a request to a secure account stored on a server accessible to a secure network in the server environment. For example, the task manager 126 may send a request to the secure account 119 to determine whether a task is queued in the account. In step 614, the task is received from a secure network-accessible server hosting a secure account, and the task is received by a task manager running in the client environment.

Step 616 includes routing the task to a handler program running in the client environment and executing the task. For example, the task manager 126 may pass the task to the appropriate one of the

handlers

128, 130, and 132. At step 618, the handler generates a message describing whether the task completed successfully. A message is communicated 620 from the handler program to the task manager. Step 622 includes sending a message to a secure network accessible server to provide a status of the task.

The steps of method 610 may include other steps or elements. For example, the task may include updating a software program running in the client environment such that the handler program performs the task by converting the software program to include the update. In another embodiment, updating the software program running in the client environment includes creating a pre-update folder in the client environment and populating the pre-update folder with the first version of the software program to be updated. Operation 610 may also include calculating a hash value of the first version of the software program and transmitting the hash value to a server running in the server environment. In another embodiment, operation 610 further comprises creating a post-update folder in the client environment and populating the post-update folder with a second version of the software program that is to be updated and is substantially similar to the first version of the software program. Thus, updating the software program running in the client environment may include converting the second version of the software program in the folder after the update to include the update, thereby converting the software program to an updated software program. In yet another embodiment, the operations further comprise generating a data set by comparing the first version of the software program in the pre-update folder to the updated software program in the post-update folder, and transmitting the data set to a secure network accessible server in the server environment. The data set may be encoded to create an encoded data set that is transmitted to a server to be made accessible to a secure network available to other client environments running the same program modules as the first version of the software program. The other client environment may then utilize the encoded data to convert the first version of the software program into an updated software program.

Having generally described some embodiments of the invention, a general computing environment will now be described with respect to FIG. 7. That is, embodiments of the invention may include, for example, a computing device, a component of a computing device, a computer-readable medium or other device storing instructions for execution by a computing device, a method performed by a computing device, and so forth, among others. Accordingly, these various embodiments may include at least some of the elements described with respect to fig. 7.

FIG. 7 illustrates an exemplary computing environment for implementing embodiments of the present invention and is designated generally as computing device 700. Computing device 700 is but one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of embodiments of the invention. Neither should the computing environment 100 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated.

Embodiments of the invention may be described in the general context of computer code or machine-useable instructions, including computer-executable instructions such as program modules, being executed by a computer or other machine, such as a personal data assistant or other handheld device. Generally, program modules including routines, programs, objects, components, data structures, etc., refer to code that perform particular tasks or implement particular abstract data types. Embodiments of the invention may be practiced in a variety of system configurations, including hand-held devices, consumer electronics, general-purpose computers, more specialty computing devices, and the like. Embodiments of the invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network.

Referring to fig. 7, computing device 700 includes a bus 710 that directly or indirectly couples the following devices: memory 712, one or more processors 714, one or more presentation components 716, a radio 717, input/output ports 718, input/output components 720, and an illustrative power supply 722. Bus 710 represents what may be one or more busses (such as an address bus, data bus, or combination thereof).

Although the various blocks of FIG. 7 are shown with lines for the sake of clarity, in reality, delineating various components is not so clear, and metaphorically, the lines would more accurately be grey and fuzzy. For example, a presentation component such as a display device can be considered an I/O component. Further, the processor has a memory. We recognize that such is the nature of the art, and reiterate that the diagram of FIG. 7 is merely illustrative of an exemplary computing device that can be used in connection with one or more embodiments of the present invention. No distinction is made between categories such as "workstation," server, "" laptop, "" handheld device, "etc., as all are contemplated to be within the scope of fig. 7 and reference to" computing device.

Computing device 700 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computing device 700 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media.

Computer storage media includes volatile and nonvolatile, removable and non-removable, tangible and non-transitory media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes RAM; a ROM; an EEPROM; flash memory or other memory technologies; CD-ROM; digital Versatile Disks (DVDs) or other optical disk storage; magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices; or other computer storage devices that can be used to store the desired information and that can be accessed by computing device 700.

In contrast to storage media, communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.

The memory 712 includes computer storage media in the form of volatile and/or nonvolatile memory. The memory may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid state memory, hard disk drives, optical disk drives, and the like. Computing device 700 includes one or more processors 714 that read data from various entities such as memory 712 or I/O components 720. Presentation component(s) 716 present data indications to a user or other device. Exemplary presentation components include a display device, speakers, a printing component, a vibrating component, and the like.

Radio 717 is used to transmit and receive signals from networks such as telecommunications networks. I/O ports 718 allow computing device 700 to be logically coupled to other devices including I/O components 720, some of which may be internal.

Many different arrangements of the various components depicted, as well as components not shown, are possible without departing from the scope of the following claims. Embodiments of the technology have been described in an illustrative and non-limiting sense. Alternative embodiments will become apparent to the reader of this disclosure after and as a result of reading this disclosure. Alternative means of implementing the foregoing may be accomplished without departing from the scope of the following claims. Certain features and subcombinations are of utility and may be employed without reference to other features and subcombinations and are contemplated within the scope of the claims.

Claims

1. A computer-readable storage medium storing information which, when executed by one or more computing devices, performs operations for updating software in a distributed computing environment, comprising: receiving, by a secure network-accessible server, a task tailored to a client environment; storing the task in a secure account dedicated to a client environment; receiving a request for secure account authentication from an automated task manager running on a client device in a client environment to send the task; communicating the task to an automated task manager; and updating the status of the task;

wherein the operations further comprise monitoring, by a task monitoring module, the secure account to determine when the task is queued in the secure account and when the task is communicated to an automated task manager;

wherein the operations further comprise presenting a task monitoring user interface in communication with the task monitoring module and presenting the status;

wherein the task monitoring user interface provides a selectable link that, when selected, presents the content of a message received from the automated task manager.

2. The computer-readable storage medium of claim 1, wherein updating the state of the task comprises: the state is changed from a pending state to an active state by a task monitoring module when the task is communicated to an automated task manager.

3. The computer-readable storage medium of claim 1, wherein the operations further comprise receiving a message from an automation task manager that the task completed successfully, and wherein updating the status of the task comprises picking up the message by a task monitoring module and transitioning the status from an active state to a successfully completed state.

4. The computer-readable storage medium of claim 1, wherein the operations further comprise receiving a message from a task manager indicating that the task was not completed successfully, wherein a task monitoring module pulls the message from a secure account and updates the status to include a failed status, and wherein content of the message is visible in a task monitoring user interface.

5. A computer-readable storage medium storing information which, when executed by one or more computing devices, performs operations for updating software in a distributed computing environment, comprising: automatically determining whether the task is queued by sending a request to a secure account stored on a server accessible to a secure network in the server environment; receiving the task from a secure network-accessible server hosting a secure account, wherein the task is received by a task manager running in a client environment; routing the task to a handler program running in a client environment and executing the task; generating, by a processor program, a message describing whether the task was completed successfully; communicating the message from the handler program to a task manager; and sending the message to a secure network accessible server to provide a status of the task;

wherein the task comprises updating a software program running in the client environment, and wherein the handler program performs the task by converting the software program to comprise an update;

wherein updating the software program running in the client environment comprises: creating a pre-update folder in the client environment and populating the pre-update folder with a first version of the software program to be updated;

wherein the computer-readable medium further comprises: calculating a hash value of the first version of the software program and transmitting the hash value to a server operating in a server environment;

wherein the computer-readable medium further comprises: a post-update folder is created in the client environment and populated with a second version of the software program to be updated and substantially similar to the first version of the software program.

6. The computer-readable storage medium of claim 5, wherein updating the software program running in the client environment comprises converting the second version of the software program in the folder after the update to include the update, thereby converting the software program to an updated software program.

7. The computer-readable storage medium of claim 6, wherein the operations further comprise: a data set is generated by comparing a first version of a software program in a folder before an update with an updated software program in a folder after the update and by identifying one or more differences between the first version and a second version, the one or more differences being included in the data set, and transmitting the data set to a secure network-accessible server in a server environment.

8. The computer-readable storage medium of claim 7, wherein the operations further comprise encoding the data set to create an encoded data set, the encoded data set being transmitted to a secure network-accessible server.

9. A system for automatically updating a computing component of a computer software program in a distributed environment, comprising: a server-side computing device having a processor coupled to a computer-readable storage medium, the server-side computing device storing a secure account maintained in a server environment and storing tasks to be performed in a client environment; an automated task manager running on a client-side computing device in a client environment and automatically retrieving a task by sending a request to a secure account, wherein the automated task manager determines that a task is available and retrieves the task based on the determination; a handler running in the client environment, the handler receiving the task from the automated task manager and executing the task in the client environment, wherein the handler provides a message indicating whether the task completed successfully and was provided to the secure account; and a task monitoring module running in a server environment, the task monitoring module picking up the message from a secure account;

wherein the system further comprises a task monitoring user interface that presents a status update indicating whether the task completed successfully in the client environment, wherein the status update is presented with a client identifier unique to the client environment;

a client-side program file structure that maintains and stores one or more code files in a client environment that include program code that is executed to run a program;

a server-side program file structure maintained in a file share of the server environment and substantially mirrored with an organization of the client-side program file structure;

wherein the server-side program file structure stores one or more hash files representing the program code.