Publish and roll back

Prepare and commit first

Prepare changes is the low-risk boundary. It freezes source, draft, referenced resource, Site configuration, and Git revisions into an immutable ChangeSet. It does not build, upload, invalidate cache, push Git, or change the public Site.

After review, apply the ChangeSet and create a local commit with an editable message and exact file selection. Unrelated staged or working-tree changes are preserved. Remote release requires that committed ChangeSet plus a separate confirmation phrase.

Remote release stages

The release builds from a detached worktree at the recorded commit, never the current live files. Its timeline moves through preflight, build, plan, asset upload, page upload, cache invalidation, and public verification. Release and event records are persisted before execution so a restart has deterministic recovery data.

Manifest planning

Each generated file is represented by a portable path, content hash, byte size, content type, and release phase. The publisher compares the new manifest with the last verified one:

• unchanged hashes are skipped;
• new or changed immutable assets are uploaded first;
• HTML, indexes, feeds, sitemap, and the release marker follow;
• deletion is limited to the explicitly managed target; and
• protected legacy prefixes are outside application ownership.

A remote-object provider should use the retained manifest rather than issuing a HEAD request for every output file.

First release to an existing target

Do not run an ordinary first release against a populated bucket or bucket root. When the provider supports baseline adoption, Studio requires an explicit administrator confirmation, inventories and hashes the existing public bytes, and stores only its marker and release state. It does not rewrite the site during adoption.

The next release then produces a real diff from that verified baseline. If a marker already exists, adoption stops and the retained release state must be recovered instead of overwriting history.

Verification

Publishing is successful only after provider operations resolve and the public verifier observes the expected release marker. Cache acceptance alone is not proof that a visitor can retrieve the new version.

Cancellation and rollback

Cancellation is cooperative and checked between safe mutation boundaries. If a release fails after target mutation begins, automatic rollback restores the prior verified bytes and marker. Manual rollback is an online release operation: it restores production but does not erase the author’s current source edits.

Always retain the previous deployment mechanism until the new production vertical passes its staging and rollback gates.