This is part of the Patterns of Enterprise Deployment series.
This is a small application that sits on the running machine and gets launched instead of the real application. Its only action is to check if there is a later version of the application, and retrieve it if there is. It then seamlessly launches the real application. In the case of user applications on client machines, users may not even be aware that there is another application there.
Also known as the self-updating application, there are technologies available that mean you can make an application update without coding it yourself.
- The application updates on all machines as soon as there is a new version available and the application is used
- decentralised deployment: you don’t need to keep a central list of all instances, and you don’t need to deploy to all of them in one go
- if you deploy a broken version, all the clients will be updated to it. It is hard to prevent this from happening in an uncontrolled way except by saying “don’t start the application”. In some cases it will be simple to prevent the new version from being downloaded but you should have a simple rollback plan ready to implement
- can be annoyingly slow if there are many new versions to deploy
- if the application is client-server, then you won’t be able to update the server and client unless the client application are forced to update. If they aren’t forced to get the new version immediately then running client applications may fail when the server is updated. The fix is obviously to restart the client app, at which point the new version will be downloaded. However, if you force clients to update you will lose some of the “as needed” goodness of the pattern; this is not a big deal as this will only apply to running client apps. However, if the change in behaviour is a breaking change, but the contract between client and server is not altered (for instance, an integer field is changed to be only positive integers) this may lead to perplexing bugs or bad data being inserted to the database.
- pretty much any time you have a large number of users running your application and don’t want to push the version to each machine
Don’t use when
- precise control of when the update occurs is required by users
- for server-side applications
I’ve seen this implemented several times. Some as simple as a batch file that checks the date on the application binary that is in the deployment shared drive and then copy the whole thing down if the date is later. The most sophisticated is ClickOnce which uses a deployment URL or UNC path to be the source of the files. This was predated by the Microsoft application updater block, which is very similar to ClickOnce in many respect, but ClickOnce has more stuff “out of the box”.