ci-cd-and-automation

CI/CD and Automation

CI/CD is the enforcement mechanism for every other engineering discipline in this catalog — it's what makes "tests pass," "lint is clean," and "the migration was reviewed" apply to every change, every time, instead of depending on a human remembering to check.

Shift left: catch problems as early in the pipeline as possible. A lint failure costs a minute; the same defect reaching production costs hours of incident response — order pipeline stages cheapest-and-fastest first so a change fails fast on a trivial problem instead of waiting 20 minutes for a full integration suite to discover it.

No gate can be skipped. If lint fails, fix the lint issue — don't disable the rule to unblock a merge. If a test is flaky, fix the flakiness — don't re-run until it passes.

The quality gate pipeline (Go)

PR opened
  → gofmt / golangci-lint
  → go vet
  → go build ./...
  → go test ./... -race -cover
  → govulncheck ./...
  → (main only) build & push image → deploy staging → smoke test → deploy production

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

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-go@v5
        with: { go-version: "1.23", cache: true }
      - uses: golangci/golangci-lint-action@v6

  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-go@v5
        with: { go-version: "1.23", cache: true }
      - run: go build ./...
      - run: go test ./... -race -cover
      - run: go run golang.org/x/vuln/cmd/govulncheck@latest ./...

Run lint and test as separate parallel jobs, not sequential steps in one job — a lint failure and a test failure are independent facts about the same change; running them in parallel means the PR author sees both results in the time of the slower one, not the sum of both.

Database-backed integration tests