Deployment

Why It Matters

Deployment is where most site outages are born. A half-copied upload can leave an HTML file referencing a stylesheet that has not arrived yet, so for thirty seconds the site renders as unstyled black text on white. Deployments that cannot be undone are worse: if version ten breaks the pricing page, the only cure is to build and publish version eleven, which may take the ten minutes you do not have. A host that keeps every publish as its own stored snapshot turns those ten minutes into an instant rollback. The habit worth forming is to treat a publish as a thing you can name, inspect and reverse, rather than an action that simply happens to the site.

How It Works

The mechanics vary by host, but the shape is constant. Files are transferred — over HTTPS to an API, over Git, or as a zip through a browser — and stored as a numbered release. The host then flips a pointer: the route for your address stops resolving to release nine and starts resolving to release ten. Caches are told about the change, either by purging the edge or by relying on content-hashed filenames, which make new assets into new URLs that no cache has seen. Only at that point does a visitor's request come back with the new markup. Because the flip is the last step rather than the first, a transfer that fails halfway leaves the previous release serving as though nothing had been attempted.

Real-World Example

Common Mistakes

• ✕Uploading only the files that changed — the site ends up with markup pointing at assets that were removed two publishes ago
• ✕Publishing straight to the live address with no way back — the fix for a bad release becomes another release, under pressure
• ✕Assuming a publish is finished the moment the upload bar fills — caches may still be serving the old files for minutes afterwards

Related Terms