Continuous Delivery and Auto Updating Applications

“You Have 2 Update(s) Available..”

Sounds Familiar !!

It is absolutely  essential to have such a provision inbuilt into our Desktop/Windows applications as it can prove to be a boon to any enterprise.

Personally, it brings a smile to my face every time I see an update for any one of my mobile apps. 🙂

We need to embrace what is know as Continuous Delivery Software Development model.

It’s a Software Development practice wherein we use techniques such as Automated Testing, Continuous Integration and Continuous Deployment to :

1.Achieve High standards
2.Easily Package and Deploy builds to Test Environments.
3.Ability to rapidly, reliably and repeatedly push out enhancements and bug fixes to customers at low risk and with minimal manual overhead
A Standard Continuous Delivery Model looks like the one below :
cd
AS can be seen from the above illustration, having an inbuilt mechanism to update Desktop Applications at user’s end is most Critical to achieve Continuous Delivery BUT often most neglected.

We may have already put all the effort to setup a source control system, a build server, an automated versioning process and all are configured so that we can release a new Build with the press of a button.

BUT how do we get the new build version to the end users?

This is where an automatically updating application comes into picture.

If we design an application, which is able to query a server periodically (or on user action) for available updates and is able to update itself to a newer version, we save a lot of time, effort and money invested by IT support to distribute application updates.

All of this might be irrelevant to a Web application, since it runs on a browser, BUT for a WinForms application, its indispensable in this Connected Age.
For a WinForms application running on a Desktop, a Developer has to sooner or later think about an approach to implement an auto-updating mechanism.
But, this is something which should ideally be a part of the very Design of a Windows Application. It should be an integral part of the application and not a separate patch later on in the development phase.
Designing a Custom Update Mechanism takes a lot of thought and effort, but there are certain  well established tools and libraries(Open source as well as licensed) available out there which can greatly help you out :
  1. ClickOnce
  2. BITS
  3. .NET App Updater Block
  4. NAppUpdate Framework (Strongly recommended; Highly extendible)
  5. NETSparkle

A feature comparison of the various options available is as under :

Features/Options

NAppUpdate

ClickOnce

BITS

.NETApp Updater Block
Installation of updates in the same folder as the application (i.e. the updated version should NOT create a new folder on the Client as in the case of ClickOnce)

Yes

Yes

Yes

Updates over HTTPS or better still, a WCF service (more secure).       Yes

Yes

Yes

HOT Swap of update files (Ability to update files without restarting the application.)

Yes

Backup and Rollback of updates (In the event of failure)

Yes

Yes

Yes

Download progress

Yes

Conditional Updates (based on file version, hash key, size etc.)

Yes

Inbuilt file integrity check based on File Hash (This is required in order to ensure that the file has been downloaded correctly/completely)

Yes

Yes

Update Download and Update Apply process distinction (This is required in order to ensure that all the updates are first completely downloaded before they are applied in order to maintain the integrity of the updates/application)

Yes

Inbuilt Error handling

Yes

Yes

Yes

Ability to perform Cold Updates (i.e. applying updates after the application shuts down)

Yes

Should provide a lot of option/points to configure the application.

Yes

It should be easily extendible to accommodate new features/interfaces (like new type of update sources)

Yes

Ability to resume an interrupted update download.

Yes

All the above solutions might not fit into your project directly and may have to modified, BUT there are a few basic points we need to consider before implementing an Auto Update strategy :

1. Pull or Push Notifications : Do you want the user to query the update server or you want to show notifications to the users as a result of automatic periodic query to the update server

2. How much control should the end user have on the Update process: Can the user skip an update?

3. User Access Rights : A User should have adequate access rights on the application as well as the File System in order to update it. This has be enforced by the developer.

4. Supporting Rollback : What happens if an update fails? What happens if the user is not happy with the new version. Can the user rollback an update? Will the rollback triggered from server or simply a user action on the client.

5. Monitoring version Fragmentation: We’ll need to maintain record of which all devices are running on what versions of a software. We’ll need to keep a tab on maximum number of different version of a software we can serve on different devices. The more the version fragmentation, greater the overhead for a developer.

So, if you’re designing a Desktop Application, its absolutely essential to have an Auto-Update mechanism. It’ll make life easy for Dev Team, Release team, IT support  as well as the end users (or the Enterprise).

Leave a Reply

Your email address will not be published. Required fields are marked *