A new version is available!

How to update your running web-app

So you’re doing continuous deployment right? If not, why not? The benefits are demonstrably huge.

In my previous article I spoke about the three laws to ensuring successful continuous delivery. Here we’ll be looking at what happens after you’ve deployed, and how to create a pleasant experience for your users. The focus is mainly on web-apps, but could apply to other things too.

Getting users to update

When a new version of your code is deployed, you may still have clients with the app already running. These will unfortunately go on using the old version of your code.

When releasing small bug-fixes, perhaps this is not too much of a problem, they’ll get the new version when they next start up the app or reload the webpage right?

But what if that doesn’t happen very often?

For example, let’s imagine a popular email client. Users often have a tab in their browser almost permanently open and flick back to it periodically to check their mail. If you are like me, this tab is only ever closed by accident (why is the Close Tab button right above the Close Other Tabs button, dammit Chrome?!). With a long-life web-app such as this, how do we deliver new updates to each client?

As well as this, sometimes we release new features, or backwards-incompatible changes, and we need any running clients to switch over to the new version or they will be unable to continue to use the app.

Backwards compatibility is not always easy (source)

To get users to update a web-app, the process is as simple as reloading the page. Once refreshed, the new version of the code will be available and the client will fetch and execute it. So all we need to do is let the client know when this is required, and automate the refresh.

How Google deal with updates to Inbox (lets not get started on the design inconsistencies here)

Our solution

After we have deployed our application using our automated processes, we also manually tag and create a release on GitHub. This is a formal expression to whomever may be watching that there is a new version of the software available.

Now we have made our release official we can make use of this information in our web-app using the GitHub API.

GET /repos/:owner/:repo/releases/latest
{
  "tag_name": "v1.0.0",
  ...
}

Using the releases endpoint we can fetch the latest release of a particular repository. By periodically checking this value we will be able to see when there is a new release and notify our users.

To help with this, we have created a simple JavaScript library to do just that. reload.js will monitor a GitHub repository for new releases, and using semver will check what kind of release it is and display an appropriate message. Or you can set your own message;

reload.options({
  major: {
    content: 'A new version is available!'
  },
  minor: {
    content: 'Take a look at our new features'
  },
  patch: {
    content: 'Some bugs are fixed'
  }
});

reload.js showing a popup when a new major version is available

If you ever deploy very breaking changes, then you can also tell reload.js to refresh to page automatically after a specified timeout. Though I recommend using this sparingly as it can create a rather jarring user experience.

We’re still working on striking the right balance between releasing as often as possible and not bombarding our users with notifications.

That said, this is now as important a step in our release process as actually deploying the code, and we will continue to work on it.

If you have a similar process then I’d love to hear about it, let me know in the comments below 😊

Want to see more articles like this? Click the 💙