Implementing an auto updater with Binfer

Problem

A client had their application deployed on multiple computers distributed across the world. The upgrade process of their application was tedious, infrequent, time-consuming, and expensive. Because of the lack of a good update mechanism, the upgrades had to be provisioned all at once across all the computers. This required lots of coordination and effort. Often, by the time the previous upgrades were made across all the computers, a new release was already available.

Business Objective

The client wished to release new features more frequently so that their business could stay ahead of the competition. To achieve this objective, they needed a better, faster, easier, and cheaper way to upgrade their software quickly, as and when new updates were available.

Requirements

The client had identified the following functional requirements

Ability to package all release assets in one logical bundle.
Ability to specify target computers that would be eligible for the updates.
Ability to reliably deliver all assets to the destination computers.
Ability to receive notification that all assets were delivered both at the sending and receiving sides.

Alternatives

The client evaluated building their own solution vs using Binfer. They decided to go with Binfer as it met all of the requirements out of the box.

Solution

The solution consisted of the following components

Update production system. This system created the updates as and when they were delivered.
Update delivery system. This system delivered the updates to the specified computers. Binfer enterprise sync product performed this function.
Update application system. This system resided on the computers and was responsible for the actual application of the update.

Implementation

This section focuses on Binfer’s enterprise sync implementation details. This example is prepared to demonstrate the solution and doe not the real client update data.

Payload preparation
A payload is prepared with update files inside a Payload directory along with a script file that will be executed after all files within the payload are delivered. The payload structure can be whatever the update production system decides it to be. In this example, the payload has a “runAfter.bat” script file that will be executed after all files have been delivered.
Rule creation
A new sync rule is created. The source folder is set to folder where the update folder is located. The target devices are selected. As there is a script job to be run, the script file name is specified in the “SCRIPT JOB > Script job command” option.
Rule execution
Files present in the update folder will be sent to all the target devices. The specified script file will be executed. Finally, the result of script execution will indicate the execution status of the script.

Script Job

Script job can contain any commands supported by the operating system of the target device.

Example:

In the example above, the scrip job is performing the following operations

Delete and create required directories.
Use xcopy command to recursively copy a directory with several directories and files to another location.
Execute a powershell command to extract a zip archive file.
Execute a powershell command to invoke a web request. This web request could have been used to notify the Update Application System, that the updated is completely downloaded and ready for next actions.