Verify production deploys actually shipped the right version

Pre-Ship Gate checks the difference between a deployment command succeeding and the intended version actually serving users. It wraps an existing release process with pre-flight checks and live verification. It does not run the production deployment itself.

The workflow has three phases in order: examine release prerequisites, let the human or existing tooling perform the deploy, and verify the running system before reporting success. Pre-flight reviews common silent failure modes that can survive a green pipeline. Each item must be confirmed or explicitly flagged rather than assumed.

The migration check asks whether the target schema will be ready before new code serves traffic. The feature-flag check verifies the setting in the actual target environment. Build and cache checks examine changed artifact fingerprints and the possibility of an old CDN bundle. Release-pointer checks distinguish uploading a build from activating its revision. Staged-rollout checks identify traffic left at zero or waiting for manual promotion. Configuration checks establish that required environment variables and secrets exist in the target.

Use before a production or staging push, before claiming a release is live, or when users still see old behavior after an apparently successful deploy. Migrations, flags, and canaries make the checks especially relevant.

A passing health status alone does not prove the right build is running. The probe may have reached a cached edge or an old instance. If the target environment, intended revision, or verification endpoint is unknown, clarify those details before relying on the gate. Environment-specific testing, load tests, and expert review still have their own roles.

Inputs include the intended immutable revision, the actual target environment, the service's real version endpoint, and release-specific migration, flag, cache, pointer, rollout, and configuration details. Outputs are an explicit SHIP or HOLD verdict with named failing items and a post-deploy revision comparison.

The comparison logic in the supplied example is:

if [ "$INTENDED" = "$LIVE" ]; then
  echo "Live revision $LIVE matches intended $INTENDED: verified shipped."
else
  echo "MISMATCH: intended $INTENDED but live is $LIVE. Do not report shipped."
fi

Those variables must hold full immutable identities in the same format, obtained from the intended build and the intended live environment. Placeholder hosts and response fields need replacement before use. Never include secrets in health-check URLs.

The gate works around existing deployment tooling and service-specific status endpoints. After cutover, fetch the running revision, compare it with the intended one, inspect initial production errors, and exercise the requested critical paths, including migration and flag behavior. A matching revision is necessary evidence but does not establish functional acceptance by itself.

If the revision differs, report the mismatch. If a canary has not promoted or a schema is unavailable, name that condition explicitly. Verification calls are read-oriented; production mutation remains the responsibility of the separately authorized deployment process.