Deployment

Deployment is the step between "it works on my computer" and "it works for customers". It covers copying the new code to the server, running any changes the database needs, clearing caches and checking the result. On a simple site it might take seconds; on a larger application it is a planned, often automated process.

Deployment is different from publishing content. When an editor publishes a blog post in a CMS, the content goes live, but the code stays the same. A deployment changes the code itself: templates, features, plugins or settings.

How it works

There are several common methods. The oldest is uploading changed files to the server by hand over SFTP. More reliable is deploying from Git: the server, or a service, pulls a specific version from the repository so what goes live is exactly what was reviewed. Most reliable is an automated pipeline, part of CI/CD, that runs checks, builds the site and deploys it whenever approved changes are merged.

A careful deployment has a sequence: back up the live database, deploy to a staging copy first, test the important paths such as forms and checkout, deploy to live, then check again. Good setups switch to the new version in one step, so visitors never see a half-updated site, and keep the previous version ready so it can be restored in a single action.

Some changes are harder to undo than code. If a deployment alters the structure of the database, rolling back the code may not reverse the data change, so those deployments need extra care and a fresh backup taken immediately before. After any deployment, the last step is to clear caches and check the live site as a visitor would, including on a phone, because a cached old page can hide whether the new version is really live.

Example

A small online shop deploys a new delivery-cost rule on a Friday evening by uploading files over SFTP. One file fails to upload, the checkout breaks and nobody notices until Saturday morning's complaints. Rebuilding the old version means guessing which files changed.

The shop then moves to deploying from Git through an automated pipeline. Changes are tested on staging, deployed on weekday mornings when the developer is around to watch, and the previous release stays on the server. The next time a problem slips through, the developer restores the previous release in a minute and fixes the issue calmly afterwards.

Why it matters for your business

Every deployment is a moment when a working site can break, and the damage depends on how quickly it can be noticed and undone. A repeatable, automated process with a rollback costs a little setup but saves lost orders and emergency fees. You do not need to run deployments yourself, but you can ask three questions: how are changes deployed, can the last release be restored quickly, and when are deployments scheduled. Deploying outside your busiest hours and not just before the developer goes offline is simple, free risk reduction. If your site takes orders or bookings, also ask who checks them after each release, because a broken checkout often shows up first as silence rather than as an error anyone sees.

Common mistakes

• Deploying on Friday evening or just before a holiday, when nobody is available to fix problems.
• Uploading files by hand and missing one, leaving the site in a broken in-between state.
• Deploying without a fresh database backup when the change alters stored data.
• Testing only the changed page and not the forms, checkout or login that matter most.

Questions people ask

How long does a website deployment take?

With an automated pipeline, a typical small site deploys in a few minutes, most of it running checks and building files. Manual deployments vary with the number of files and steps. Planning, testing and checking afterwards usually take longer than the deployment itself.

Will my website go down during a deployment?

It should not. Well-built deployment setups prepare the new version alongside the old one and switch over in one step, so visitors see no downtime. Manual file uploads can leave the site briefly broken while files are only partly copied.

What is a rollback?

A rollback is returning the live site to the previous working version after a deployment causes problems. Good deployment setups keep earlier releases available so a rollback takes moments. Database changes can complicate it, which is why backups are taken before risky deployments.