Deploying a static site is not trivial. There are two problems that can occur during deployment:
-
(type A) Dependency on not-yet-existing file. For example, a newly-uploaded HTML file refers to a CSS file that hasn’t been uploaded yet.
-
(type B) Dependency on already-deleted file. For example, a soon-to-be deleted HTML file refers to a CSS file that has already been deleted.
Here are four approaches, in increasing order of correctness:
-
Sync and deleting during transfer. This is straightforward, but can lead to type A and type B faults.
-
Sync and delete after transfer. This is an improvement over the previous approach, as it eliminates type B faults. Type A faults still exist.
-
Instantaneous deploy, by decoupling upload from deployment. This can be done by switching a symlink (very fast) or a
git checkout. This eliminates type A faults, but type B faults still exist. -
Split assets upload. This involves cache-busting assets by adding the content hash to the filename. Then, (1) upload the assets, (2) transfer the HTML files, and (3) delete stale assets. This third step needs to be done after a small delay, about the duration of the longest reasonable full request.
The last approach is the only one that eliminates type A and type B faults.
This also explains why deploying static sites as a (Docker) container is generally a bad idea, unless you explicitly enable session affinity/sticky sessions.
What this means for web apps
SPAs, which are web apps that typically don’t reload after being loaded for the first time, won’t be able to make use of the newly deployed code.
Perhaps a good approach would be to regularly poke a version file on the server to compare with, and show a notification when a new version has become available, with a button to suggest reloading (and perhaps a link to the release notes).
But hey, I don’t have much experience with this as I’ve not ever worked on update mechanisms for web apps.