Hub and Spoke Application Update Deployment

Lab Description

In an application operating environment, it’s a common scenario to see many physical locations, each with many computers, all pulling application updates from a single update location. For many of these locations, the network connection to the update server is slow, compared to the speed of each of the local networks. With each local system retrieving updates over the slower wide-area connection, bandwidth is expended resulting in a slow updating user experience. Employing a Hub and Spoke update process, which maintains a local application update server at selected remote sites, improves bandwidth utilization as well as the end-user updating user experience.

Solution Lab

For applications that operate in an environment like this, maintaining a local update location at each location and utilizing the faster local network speed to distribute application updates to local systems represent a much more efficient update distribution configuration. Configured this way, application updates are downloaded only once per physical location over the slow wide-area connection, with local computers retrieving the update from a local update location.

To accomplish this with an application maintained by AppLife Update, we’ll use AppLife Update itself to replicate the public update folder to a local folder. Once we have the update folder replicating to a local server, the deployed application on local systems need only be configured to check the local update folder instead of the public update location during application updates.

Replicating the Public Update Location

An update location is simply a folder on a server that contains update packages, as well as a Director.Xml file which describes all of the update packages in the folder. Whenever an update package is created for your application, the publish process adds (or replaces) an update package (maj.min.bld.rev.zip) and a modified Director.Xml file to the designated publish location. To maintain a local application update folder at separate deployed sites, we will use a new AppLife Update project to create and publish updates that will maintain a local update folder. As new update packages are built for your application, a second update will also be published that will maintain update folders at deployed sites, and this second update will place this newly created application update package and modified Director.Xml into the local update folder.

Updating Local Application Update Folders

The update action list used to maintain the replicated update locations contain two Add & Replace files actions. The first action will include the newest update package built for the primary application. The second action includes the Director.Xml file.

We add the update package file first so that the package is present in the update folder being maintained when the Director.Xml file that includes the package is placed in the folder. The update folder is not taken off-line during the update, so it is likely that clients at the site will check for updates as the folder is being maintained. You’ll notice that the update package is explicitly listed in this action list, which would require a manual modification to the action list with each subsequent update version. Automation can be employed to remove this manual modification requirement. When this update action is built, the action will add the update package (2.0.0.0.zip) and the Director.Xml file to the Application Directory, which during update execution will be the application updates folder on the designated local site server.

The Local Update Process

With an update published that will replicate the latest update package, we need a process running at the local site that will discover and apply the update. This could be the primary application itself, however in this example we present a Windows Service that is to be installed on any local server that is designated to host the primary application updates. Use of the service is quite simple. Install the service on the hosting server and configure two paths in the service’s config file. The first path is the publically available update location where the replicated updates are published. The second path is the local physical path to the folder that will serve the application updates. This service will check for updates at the configured time interval and apply any updates that it finds automatically. As the service applies updates, the local update folder is maintained to include the latest primary application updates. The primary application can then be configured to check for application updates from the local server through UNC, http, or ftp protocols, whichever the local server supports. The download for this solution lab includes a ready-to-use service installer, as well as source code for this service which can be modified, or ported to a different host process, such as a stand-alone executable or as a function available through the host application itself.

Override Assembly Location
The update process implemented in the service is explained through source code comments. We call attention to the use of the OverrideAssemblyLocation method of the Update Controller. This call is used to set the Application Directory designated in the update actions to the designated local update folder.

Setting the Current Version
When checking for updates, the update process must know the current local version. For the replication process, the current version is identified through the highest available update in the local update folder. The service reads this from the Director.Xml file in the local update folder. Whenever a new update is applied, the Director.Xml file is replaced during the update process, which updates the local current version. After the update is executed, the next update check will use the higher version number as the current local version.

The service writes when an update is applied to the Windows Event Log. Errors that occur during the update process are also written to the Windows event log. The source code is provided and can be extended to communicate update information errors to support staff through channels available to you.

Using the Service

A ready-to-use service installer is available in the solution lab download. To utilize the service:

1. Run the Service installer, MyAppUpdateLocationSvcSetup.msi.
2. Change the MasterUpdateLocationUrl value in the config file located in the service install folder to the location that you will be publishing replication updates to.
3. Change the LocalUpdateLocationUrl value to the local server folder that will hold the primary application updates.
4. Use the ServerUpdates.aup AppLife Update project file to build and publish replication updates that contain your primary application updates.

For security reasons, we highly recommend creating your own AppLife Update project file (.aup) and changing the Application ID and the Public Key to match the new project.

Summary

Application Updates can be easily replicated to any number of remote sites using AppLife Update. By replicating your application updates to remote sites, client systems can check for and apply updates from a server local to the client and avoid using wide-area network connections for application maintenance.

Further Information

Using a pre-build script, the manual modification to the update action required to insert the correct application update package can be removed. Read the blog post discussing pre-build automation for more information.

Download AppLife Update Here