Use protected environments and rollback

Production requires review, exposes only production credentials, records the deployment URL, runs a smoke test, and retains the previous artifact. This is a small part of a GitHub repository whose workflow tests, builds, packages, and deploys a small site through a protected environment, but the boundary it creates affects everything that follows.

An environment is both a target and a policy boundary around who and what may deploy. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

Watch for one shortcut in particular: trying to treat a green deploy command as proof that users received a healthy release. It makes later failures harder to locate. Instead, gate the environment, deploy, verify from outside, record the release, and roll back automatically or manually from known artifacts. Prefer an implementation you can explain from the outside before optimizing it.

Keep the wider goal in view: Turn a verified build artifact into one controlled deployment with environment history and rollback. A short observation with concrete evidence is more useful than a confident sentence with no reproduction path.

Deploy a deliberately broken health response to staging and rehearse the production rollback without rebuilding. Hand the result to someone else and see whether the behavior is clear without an oral explanation.