CI/CD: shipping every change safely

CI and CD in plain words

Continuous integration (CI): every time someone pushes code, a fresh machine downloads it, installs the packages, runs the linter (a tool that finds mistakes and style problems), runs the tests and builds the app. If any step fails, you see a red cross within minutes, while the change is still fresh in your mind.

Continuous delivery means every change that passes CI is ready to release with one click. Continuous deployment goes one step further: it is released automatically. Both are called CD. The steps from push to live site together are called the pipeline.

A workflow with GitHub Actions

GitHub Actions runs pipelines for repositories on GitHub. A workflow is a YAML file in the folder .github/workflows. It says when to run (on), and lists jobs; each job runs its steps in order on a fresh virtual machine called a runner.

# .github/workflows/ci-deploy.yml
name: ci-and-deploy
on:
  push:
    branches: [main]
  pull_request:

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: lts/*
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm test
      - run: npm run build

  deploy:
    needs: check
    if: github.event_name == 'push' && github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment: production
    concurrency: production
    steps:
      - name: Ask the host to deploy this commit
        run: curl -fsS -X POST "$DEPLOY_HOOK_URL"
        env:
          DEPLOY_HOOK_URL: ${{ secrets.DEPLOY_HOOK_URL }}

• npm ci installs exactly the versions in package-lock.json, so CI uses the same packages as your laptop.
• needs: check makes deploy wait for the check job; if a test fails, nothing is deployed.
• if: ... limits deploy to pushes on main, so pull requests are checked but not shipped to production.
• environment: production lets you keep production secrets separate and even require an approval click.
• concurrency: production stops two deploys from running at the same time.
• The deploy hook is a secret URL many hosts give you; calling it starts a deploy. It is stored in GitHub secrets, never in the file.

Preview deployments

A preview deployment is a temporary copy of the app built from a pull request, with its own URL. Reviewers click through the real change on their phone before it is merged. Frontend hosts make one for every pull request automatically. Point previews at a preview database with test data, never at production.

Database migrations in a release

A migration is a script that changes the database structure, such as adding a column. Run migrations once per release, as a separate step before the new code starts (many hosts have a "pre-deploy" or "release" command for this). Do not run them inside every server at startup: with three API instances, three copies would try to change the table at the same moment.

Make every migration backward compatible: the old code must still work after it runs. During a deploy, old and new code run side by side for a short time, and after a rollback the old code runs against the new database. The safe pattern is expand, then contract: first add the new thing, later remove the old thing.

-- Release 1 (expand): add the new column, copy the data.
-- The new code writes to both body and content, and reads content.
ALTER TABLE notes ADD COLUMN content TEXT;
UPDATE notes SET content = body WHERE content IS NULL;

-- Release 2, days later (contract): no running code uses body any more.
ALTER TABLE notes DROP COLUMN body;

Rollback and branch protection

A rollback puts the previous working release back. Most platforms keep old deploys and can redeploy one with a click; you can also git revert the bad commit and push. When users are hurting, roll back first and investigate later.

Branch protection is a GitHub setting (in branch protection rules or rulesets) for main: changes only arrive through pull requests, the CI checks must pass, someone may have to approve, and force pushes are blocked. Then main is always in a state you could deploy.