A reviewer approves a change after seeing a working preview. The publishing job then rebuilds the application and deploys the new output. The source revision may match, but the reviewed object and the deployed object are no longer automatically the same. The release process needs to account for that difference.
Identify the build being released
For a hypothetical static application, retain the source revision, build-run identifier, artifact identifier and digest. Record the configuration that can affect the output. The release job should be able to show which candidate it obtained and which evidence applies to that candidate.
A friendly artifact name is useful navigation. An immutable identifier or verified digest establishes which bytes the name refers to. This matters when a run is repeated, a branch moves or an operator chooses between several successful builds. “The latest green build” is an ambiguous release instruction.
Separate building from publishing
Build and test the candidate in a context that does not contain publishing authority. Then give the trusted publishing step the validated output and the narrowly scoped ability to publish it. Any transformation performed after validation belongs in the release design, because it can create a new candidate.
Google’s release-engineering chapter describes repeatability and controlled release processes. Applying that discipline here means making the transition from tested output to deployed output explicit. It does not mean that a source commit alone proves every environment will produce identical bytes.
Source: Google SRE · Release Engineering.
Understand what each check covers
A browser test against a local build can establish navigation and form behavior under its test conditions. It does not establish that a real domain has the right certificate, a redirect is configured at the edge or a submitted message reaches its recipient. Those checks occur against the destination after deployment.
- Before publishing: identify the candidate and inspect its build evidence.
- While publishing: verify the downloaded artifact and record the destination version.
- After publishing: check the actual hostname and important user journeys.
- Before a later release: retain the prior working version and compatible configuration.
Identify the version to restore
If a release is rejected, the team needs more than a remembered tag. It needs the earlier artifact and the configuration required to run it. A useful release record can answer two questions without searching chat history: what exactly went out, and what exactly can go back?
That is a small amount of bookkeeping with a clear purpose. It turns approval into a decision about a concrete candidate and makes the later incident investigation less dependent on memory.