Atomic deployment

Why it matters

It removes the window where a visitor could be served a broken mix of old and new files mid-deploy, a half-updated page referencing a script that has not been uploaded yet. A deploy either completes and switches over entirely, or it does not happen at all, with no in-between state a visitor can land in. It also makes rollback trivial: if a new release turns out to have a serious problem, switching the symlink back to the previous, known-good release folder is close to instant, rather than trying to manually undo a partial in-place update. It also makes every deploy independently testable before it goes live: a new release can be built and verified in its own isolated folder while the current live version keeps serving traffic completely undisturbed.

What goes wrong when it's handled badly

A deploy that overwrites files in place, rather than building a new release and switching to it atomically, can leave a site serving a broken combination of old and new code for the seconds or minutes the upload takes, and a visitor loading the page during that window sees the breakage directly. Releases here are built as timestamped, isolated folders with a symlink flipped to the new one only once the build is verified, specifically to avoid that. A concrete example is a WordPress auto-update that runs directly against the live site's files, and is interrupted partway by a server timeout, leaving the site in a broken, half-updated state that requires manual recovery rather than a clean, instant rollback. A concrete example is a WordPress auto-update that runs directly against the live site's files and is interrupted partway by a server timeout, leaving the site in a broken, half-updated state that requires manual recovery rather than a clean, instant rollback. Naming each release by its exact build timestamp, rather than overwriting a single 'current' folder in place, is what makes both the verification step and the rollback step possible at all.