Fast Feedback from Deploy Previews

In March 2022 I wrote about deployment hooks: HTTP requests that trigger a build and deploy on your hosting platform. My point was that CI/CD lets teams ship often, but shipping often isn’t the same as shipping safely. Wire a deploy hook to pull requests, build every change on the same kind of infrastructure it’ll run on in production, and block the merge if the build fails. “It works on my machine” stops being an argument.

The best line in that post was about speed: if build checks take an hour, people stop respecting them. Fail fast, while the change is still in the developer’s head.

Previews became the default

What was a custom setup in 2022 is now standard. Most hosting platforms build a preview deployment for every pull request, with its own URL. That changes code review:

• Reviewers click a link instead of checking out a branch.
• Designers and product people can review the real thing, not a screenshot.
• End-to-end tests can run against the preview, in an environment much closer to production than a laptop.

Two tiers of checks

The idea in my post, “a minimal build for quick checks, then full verification later”, is now how I’d always structure a pipeline:

• Pull request tier: lint, type checks, unit tests and a few smoke tests. Minutes, not tens of minutes.
• Merge tier: the full end-to-end suite, visual regression, security scans and anything slow.

The quick tier keeps feedback inside a developer’s attention span. The slow tier still guards main. Speeding up a slow lint job and showing test coverage on every merge request made a real difference to how a team I worked with used its pipeline (A Testing Strategy Teams Actually Adopted). It’s Shift Left Testing applied to the pipeline itself.

Then make releases reversible

A preview catches problems before merge. Something will still get through. The other half of safe delivery is being able to undo a release quickly:

• Blue-green deployments: keep two production environments, release to the idle one, flip traffic, and flip back to roll back (Blue-Green Deployment).
• Feature flags, so deploying code and releasing a feature are separate decisions.
• Canaries, so a bad release reaches a small slice of users first.

Fast checks before merge and fast rollback after release are two halves of the same idea: make the cost of a mistake small, so you can afford to move quickly.

How I’d measure it

The useful numbers are the ones in DORA Metrics: lead time for changes, deployment frequency, change failure rate and time to restore. A deploy hook or a preview environment is only worthwhile if those move.

---

Originally written in 2022 → The power of CI/CD Deployment Hooks