Release integrity: a green build is not a trustworthy release

Successful unit tests demonstrate something about the code that ran in a particular environment; they do not prove the deployed artifact came from the approved source or that the deployment used the right credentials. Write a release invariant: a particular reviewed revision, built with an identified workflow and dependencies, produced the artifact deployed to a specific environment.

For mobile apps that includes signing material and distribution channels. For backend services it includes the container or Worker bundle, image digest, configuration and runtime identity. A release can be functionally correct and still be insecure if an unauthorized principal can replace its output.

Limit CI permissions to the jobs that need them. Avoid passing long-lived production secrets to untrusted pull-request builds. Prefer short-lived federated credentials where the deploy provider supports them, with conditions binding the requesting repository, branch and environment. Protect release environments with appropriate reviews and audit logs.

Treat dependencies, build scripts, third-party actions and signing keys as part of the attack surface. Dependency updates should be reviewed and pinned consistently with the ecosystem. An approved artifact should be immutable, with a digest that deployment can verify.

Test a release using the same URL structure, static asset handling, canonical redirects, route fallback and authentication boundaries that production uses. The Demonic Binary Cloudflare routing incident illustrates why successful compilation alone is not enough: a Worker can build successfully yet enter a live redirect loop when the asset layer normalizes paths differently.

Smoke checks should include the homepage, a critical service route, a health or robots endpoint, an intentionally missing route and any required www-to-apex redirect. Record the expected HTTP status and redirect count instead of treating all responses as healthy.

Before deploying, identify a known-good version and the conditions that trigger rollback. Following release, compare availability, error rates, auth failures and critical workflow success against a baseline. Keep the rollback path exercised rather than merely documented.

For mobile apps, app-store propagation limits rollback options; use server compatibility, staged rollout and feature gates to mitigate bad releases. For backend Workers or services, verify that a rollback restores both code and compatible configuration. A release process is trustworthy when its failures are observable and recoverable.