Continuous Delivery and Auto Updating Applications

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

 

 

 

 

 

 

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).