CI/CD Explained: Automating Website Deployment with GitHub

CI/CD (continuous integration and continuous delivery or deployment) is a setup where every change to your website's code is checked automatically and then published by a repeatable process, instead of someone copying files to the server by hand. With GitHub, the code lives in a repository, GitHub Actions or a host like Vercel or Netlify runs the checks and the deployment, and a bad release can be rolled back in minutes. For a business, the payoff is fewer broken launches, a clear record of who changed what, and faster, calmer updates.

This guide explains CI/CD for business owners and managers who pay for a website or web app and want to know what a professional release process looks like. It is not a tutorial; it shows what to expect and what to ask for.

#What CI/CD means in business terms

CI/CD replaces "a developer uploads files and hopes" with a process that runs the same checks and the same steps every time. The two halves do different jobs.

Continuous integration (CI) means every change is merged into a shared codebase often, and each change is checked automatically. Checks can include building the site, running tests, checking code style and scanning for known security problems. If a check fails, the change is blocked before it reaches anyone.

Continuous delivery or deployment (CD) means an approved change is published by an automated process. "Delivery" usually means a person presses the final button; "deployment" means it goes live automatically once checks pass.

What this buys a business:

• Fewer broken releases, because the build and tests run before anything goes live.
• A full history of every change, who made it and when, which helps with audits and handovers.
• Faster fixes, because a small change does not need a manual, risky upload.
• Less dependence on one person, since the process is written down in the repository rather than in someone's head.

If you ever change developers, a site with CI/CD in place is much easier to hand over. My article on who owns your website code and domain explains why the repository should be in your name.

#GitHub and GitHub Actions

GitHub stores your code in a repository and keeps the full history of every change. GitHub Actions is the automation layer on top. GitHub's own documentation calls it "a continuous integration and continuous delivery (CI/CD) platform", with workflows defined by YAML files stored in the .github/workflows folder of the repository.

A few terms you will hear:

• Workflow: an automated process, such as "test and deploy".
• Event: what starts it, such as a push to the main branch or a new pull request.
• Job and steps: the work inside the workflow, such as installing, building and testing.
• Runner: the server that does the work. GitHub provides these, or you can use your own.

Here is a deliberately short example. It runs the build and tests whenever someone opens a pull request:

name: Check changes
on: pull_request
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test

What it costs. At the time of writing (November 2026), GitHub's Actions billing page (opens in a new tab) says standard GitHub-hosted runners are free for public repositories. For private repositories, each plan includes a monthly allowance expressed as a dollar amount, for example USD 12 on GitHub Free and USD 18 on GitHub Team, with usage beyond that billed. A typical small business website uses a small share of that. Check the page for current figures.

Environments and approvals. GitHub lets a workflow target a named environment such as staging or production. According to GitHub's documentation, you can require approval before a job that deploys to an environment runs, limit which branches can deploy, and keep that environment's secrets (passwords and API keys) separate. That is how you stop an untested branch from reaching the live site.

#Staging, production and preview deployments

Production is the live site your customers use. Staging is a private copy where changes are checked first. Preview deployments go one step further and give every proposed change its own temporary address.

Preview deployments on Vercel. Vercel's documentation says it creates a preview deployment by default when someone pushes to a branch other than the production branch, or opens a pull request. Each preview gets its own URL, and the link usually appears on the pull request. Vercel adds a noindex header to preview deployments so search engines leave them out, except when you put a preview on your own custom domain such as staging.example.com, which you then need to protect yourself.

Deploy Previews on Netlify. Netlify's documentation describes the same idea: opening a pull request in a connected repository builds a Deploy Preview at an address like deploy-preview-42--yoursite.netlify.app, and the status shows on the pull request.

Preview links change how reviews work. Instead of "the developer says it is done", the business owner opens a link, checks the new page on a phone, and approves or comments. That is the single most useful habit for avoiding surprises at launch.

#Deploying WordPress safely

WordPress can follow the same discipline, but with one important difference: a WordPress site is code plus a database, and the database changes every day as orders, comments and form entries arrive.

What belongs in Git and automated deployment:

• Your custom theme or child theme.
• Custom plugins written for your site.
• Configuration that is not secret.

What does not belong in Git:

• The database, including posts, orders and users.
• Uploaded media in wp-content/uploads.
• Passwords and keys in wp-config.php.

A safe WordPress release usually looks like this:

1. Take a fresh backup of files and database.
2. Copy live data to staging when you need realistic testing. When moving a database between domains, tools such as WP-CLI's search-replace command are used because, as its documentation says, it "intelligently handles PHP serialized data", which a plain find and replace would break.
3. Deploy the theme and plugin code to staging through the pipeline, then test key journeys: forms, checkout, login, emails.
4. Deploy the same code to production. Do not copy the staging database over live, or you will lose any orders placed in the meantime.
5. Check the live site and keep the backup until you are sure.

Plugin and core updates fit into the same flow: test on staging first, then update live. My guide to what to do when a WordPress update breaks your site shows what happens when that step is skipped.

#Rollbacks: the safety net that matters most

A rollback puts the previous working version back live. With a proper CI/CD setup, this takes seconds or minutes rather than an evening of panic.

On Vercel, Instant Rollback points your domains back to an earlier production deployment. Vercel's documentation says Hobby plans can roll back to the immediately previous deployment, while Pro and Enterprise teams can choose any deployment that was previously live. After a rollback, new pushes do not go live automatically until you promote a deployment again, which stops a broken change sneaking back.

On Netlify, you can publish any earlier successful deploy from the deploy list. Netlify's documentation says this "doesn't trigger a new deploy" and that rollbacks are instantaneous. You can also lock publishing so new builds wait for a manual go-ahead.

On WordPress or your own server, a rollback means redeploying the previous code version from Git, and restoring the database from backup only if a change damaged data. This is why database changes need extra care: code rolls back easily, data does not.

#What a good setup includes, and when to get help

A small brochure site on a website builder may not need CI/CD at all. Once you have custom code, a web app, a WooCommerce store with custom features or more than one person working on the site, it pays for itself quickly.

A good setup includes:

• The repository owned by your business account, with access for your developers.
• Automatic checks on every change: build, tests and basic security scanning.
• Preview or staging links for review before release.
• Approval required before production.
• Secrets stored in the platform's secret settings, never in the code.
• A tested rollback path and backups that are restored at least once to prove they work.
• Alerts when a deployment or the live site fails.

You can switch on preview deployments on Vercel or Netlify yourself in an afternoon. Get help when the site handles payments or customer data, when WordPress staging needs to sync safely with live, or when several developers are involved. The CI/CD and deployment setup service covers the pipeline, environments and rollback plan, and website testing and QA covers the checks that run inside it.