Let’s face it. If you want to embrace the “Continuous Delivery” movement in software development while building your desktop application you have to put in place some sort of auto-updating mechanism.
You may have already put all the effort to setup a source control system, your build server, the necessary wix files, an automated versioning process, and all are configured so that you can deploy a new msi with the press of a button. So now how do your users get that new version? You don’t expect them to periodically search your website or the shared folder where you deployed that msi, download it and install it, do you? Do you!?
Unlike web applications which get that extra step for free, deployment is not the same as delivery in this case. Desktop developers have to consider at some point how they are going to implement that functionality in their software. Unfortunately, most of the times they don’t, until the moment they need to ship the first version. Or even worse, the first patch.
No wonder desktop users have been exposed to a plethora of last minute implementations of auto-updates that gave a bad name to that feature. It has become a necessary evil for most of us.
What you need to consider for your auto-update mechanism
There is no universal way to implement auto-updates because every application has different requirements. However there are a number of common considerations a developer has to take into account when faced with this problem. Here are a few of them:
Push or pull version notifications?
Most applications use a pull mechanism to get information for the latest available version. They either check a website or a shared network folder when they startup or periodically in predefined intervals. However if your application is always connected to a server you might want to push version notifications from the server to the running application instead.
How much control has the end user on the update process?
Do you let your user decide when to apply the update? Whether to apply it or not? Do you provide information about what the update is about, what changes and what new features are introduced? Can your user skip an update? How do you interact with your user in general during the update? Does he even need to know about it?
How do you deal with user access rights?
Do all the users of your application have sufficient rights to install and update your application? Maybe they should be able to authorise an update even if they don’t have elevated rights? How do you install an update for non super-users/administrators?
Do you support rollback?
What happens if your update doesn’t work/breaks something? Can you roll back to a previous version? Do you do that automatically or the user has to trigger the rollback process?
How do you treat user data?
Do you need to update configuration files? Databases? Application files? For example consider how visual studio updates the old solution and project files from earlier versions. Do you want to do that during the update or on demand?
It’s not a trivial thing
As you can see already auto-updates is not something you can add quickly just before you ship your application. You need to think about it carefully from the very beginning.
But don’t despair just yet! There are a few well established techniques that cover 90% of the applications out there and chances are that your case falls within those. We will talk about them at the next post, so stay tuned.