Skip to content
theakrista.dev
Engineering

CI/CD & Release Engineering

The staging-to-production release process I established as a sole engineer, Lighthouse CI as a quality gate, and why release safety is a design problem, not a tooling problem.

2 min read

I've done releases from both ends of the spectrum: on marketplace and insurance platforms with pipelines, review boards, and teams, and as a company's only engineer, where I was author, reviewer, deployer, and the person paged when it broke. The second situation is where you find out which parts of release engineering are theater and which parts actually stop incidents.

The pipeline I run

The process I established (and which the team adopted as it grew) is deliberately small:

Three decisions in that diagram do most of the work.

1. Staging is a mirror, not a museum. Same infrastructure providers, same env-var shape, same third-party integrations in test mode. Most "worked in staging" incidents are configuration drift, not code, so the process attacks drift, not code.

2. Quality gates are machines, not memories. Lighthouse CI runs on every deploy because "remember to check performance" is not a process. When I fixed the marketplace's SSR bottlenecks, the follow-up wasn't a wiki page. It was a budget in CI that fails the build if the regression comes back.

lighthouserc: the regression can't sneak back
ci:
  collect:
    url: ["https://staging.example.com/", "https://staging.example.com/listings"]
  assert:
    assertions:
      categories:performance: ["error", { "minScore": 0.9 }]
      largest-contentful-paint: ["error", { "maxNumericValue": 2500 }]

3. Promotion is boring on purpose. With revenue flowing through checkout, I chose a manual staging-to-production gate over continuous deployment. That's a trade-off, not a universal rule. With a bigger team and better automated coverage, I'd move the gate. Release process should match the blast radius and the team, and be re-decided when either changes.

AI-assisted review, honestly assessed

I introduced AI review into our PR workflow. What it's genuinely good at: catching the mechanical 60% (unhandled promise rejections, missing null checks, inconsistent naming) before a human looks, so human review spends its attention on design. What it can't do: know that the pricing service returns yen as integers, or that the CEO promised a partner this endpoint wouldn't change. The workflow is AI first-pass, human final. The order matters, and so does keeping a human's name on the merge.

Next topic

AI Integration