CI/CD with GitHub Actions: From Commit to Production

Continuous Integration and Continuous Delivery (CI/CD) turn deployment from a stressful event into a routine. Every change is checked automatically, and releasing is as simple as merging a pull request. GitHub Actions has become one of the most widely used ways to build these pipelines because it lives right next to the code.

Every change is verified automatically; only verified builds reach production.

Continuous Integration: Fast, Reliable Feedback

CI runs on every push and pull request. Its job is to answer one question quickly: is this change safe to merge?

name: CI
on:
  pull_request:
  push:
    branches: [main]

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

Principles for good CI:

• Keep it fast. Cache dependencies and run independent jobs in parallel; a pipeline that takes 20 minutes gets ignored.
• Fail early. Linting and type checks catch most issues before slower tests run.
• Make it required. Protect the main branch so pull requests can't merge until checks pass.

Continuous Delivery: Preview Environments

Preview deployments give every pull request its own URL. Reviewers can click through the change instead of reading a diff, and bugs are caught before merge. Platforms like Vercel do this automatically; for container-based apps, a workflow can deploy each branch to a temporary environment.

Deploying to Production Safely

• Deploy on merge to main, not from a developer's laptop.
• Use environments with protection rules — required reviewers or wait timers for production.
• Run database migrations as a separate, explicit step, and make them backward-compatible so old and new code can run side by side during rollout.
• Keep rollbacks one click away by deploying immutable, versioned artifacts.

Security Settings Most Teams Miss

CI systems hold the keys to production, so they're a prime target.

• Use OIDC instead of long-lived cloud keys. GitHub Actions can request short-lived credentials from AWS, Azure or GCP — no secrets stored in the repository.
• Restrict GITHUB_TOKEN permissions to the minimum each workflow needs (permissions: contents: read).
• Pin third-party actions to a commit SHA rather than a moving tag.
• Don't expose secrets to pull requests from forks.
• Store secrets in environment-scoped secrets, not in workflow files.

Measuring Delivery Performance

The DORA metrics are the industry standard for delivery health: deployment frequency, lead time for changes, change failure rate and time to restore service. A good pipeline improves all four.

Key Takeaways

• CI should be fast, required and run lint, types, tests and a build on every change.
• Preview environments make reviews concrete and catch issues earlier.
• Deploy from main with protected environments, safe migrations and easy rollbacks.
• Secure the pipeline: OIDC credentials, minimal token permissions and pinned actions.

Sources

• GitHub Docs — GitHub Actions
• GitHub Docs — Security hardening for GitHub Actions
• DORA — Research program and metrics