Zero Down Time Deployment of a SPA

Web is trending towards single page applications, what if we have a strategy to handle the application deployments in zero down time. Lets step back and understand what is SPA, it’s a Single Page Application which is a solution to save time in downloading  html pages from the server just to show a small change in the UI, i.e in SPA we just download the root html (often index.html) once and change the DOM as needed by interacting with the backend with Ajax calls and executing some scripts etc.,

There is another hidden advantage of the SPA is that every file (js, css, images, fonts etc) is always referred by the root html. So, if we can reorganize the assets in such a way that they are all placed in a separate folder which is accessible by the root document.

Screen Shot 2016-03-20 at 3.38.23 PM
Fig: 1.0

For example: In Fig, the root document points to version-1

Deployment Strategy:
Here are the steps to achieve  zero-downtime.

  1. Upload the folder(version-2) first, during this upload process the users are being served by the version(version-1) which is referred by the root document and you are not disturbing any customer.
  2. Now, the root document needs to be replaced by the root document of the version-2 (new build). This will reference the new build. In the Fig 1.1 the root document points to the new version.

    Screen Shot 2016-03-20 at 3.34.31 PM
    Fig: 1.1

As long as the step 2 is done with zero down time we are good, to do that we need a technology that will always serve a file with zero-downtime while replacing it.

AWS S3 is a perfect fit for this requirement and where it will always serve either old or new version of the file. Any method that can swap and serve a single file without downtime would work.

RollBack strategy: (Instant RollBack)
Save the root document of the build inside the versioned folder and a meta data file (like a buildInfo.json) at the root level. In this file, save build related info like build versions – previous and current build versions.


  • Download buildInfo.json. (its just like any web resource which can be easily downloaded with a curl command.)
  • Parse the file to find the  folder names of the previous(version-1) and current(version-2) builds.
  • Swap the root document with the root document from with in the folder(version-1).
  • Delete the folder with the current(version-2) build name.
  • Now the root document points to version-1 and the roll back is successfully.

Server Clean Up Strategy:

  • Download buildInfo.json .
  • Parse the file to find the  folder names of the previous(version-1) and current(version-2) builds.
  • Delete all the files and folders except the current(version-2), previous(version-1) build folders, root document and buildInfo.json.
  • Should run the clean up process after a regular deployment.

In a Single Page Application, all you need to worry about is to swap a single file to achieve no down time deployment without worrying about the versioning of each and every file that your customer might use. This solution is best for deploying static UI components. Hope this helps and your feedback is much appreciated.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s