Release to production
Approve and publish one immutable managed-repository commit, then prove it is serving.
Approve and publish one immutable managed-repository commit, then prove it is serving.
One reviewed immutable commit is published by GitHub Release and both contract and frontend convergence are proven for that exact release.
main and its checks are green.git switch main
git pull --ff-only origin main
farthershore build --format json
farthershore apply-timeline inspect acme "$(git rev-parse HEAD)" \
--env production \
--format json
farthershore business status acme --format json
Review the exact SHA, semantic diff, customer impact, and intended semantic
version. Stop if the branch moved after review or if a release prerequisite is
unmet. For an economic change, add
farthershore commercial-release diff previous-release.json candidate-release.json --format json
to the evidence.
If status is DRAFT, preview and explicitly approve the first activation, then
run farthershore business publish acme --format json. That is the only
repo-managed state where this command publishes.
If status is ACTIVE, business publish (including dry-run) returns
MANAGED_BY_CODE. After explicit approval, publish the reviewed version from
the managed repository instead:
approved_sha="$(git rev-parse HEAD)"
git tag -a v1.2.3 "$approved_sha" -m "v1.2.3"
git push origin v1.2.3
gh release create v1.2.3 --verify-tag --target "$approved_sha" --title "v1.2.3" --generate-notes
Replace the example version with the approved semantic version. The GitHub Release webhook queues production. Release creation is a handoff, not proof of convergence.
farthershore apply-timeline inspect acme <release-tag> \
--env production \
--format json
farthershore business status acme --format json
farthershore frontend status acme --ref "$(git rev-parse HEAD)" --wait --format json
Require the expected tag and commit, an applied publish phase, and live:true.
Check frontend status only when a customized frontend artifact is part of the
release.
The durable recovery is a reviewed repository fix and a new release. For urgent compensation, use the bad publish's workflow execution id:
farthershore business rollback acme <workflowExecutionId> \
--reason "urgent production compensation" \
--idempotency-key rollback-<workflowExecutionId> \
--format json
Treat status: enqueued as pending work. Record the returned rollback workflow
id, inspect it when workflow-inspector access is available, and read every
affected serving and billing surface back. The source release's Apply Timeline
entry does not become the rollback workflow's status. This command does not
revert Git. See Production releases.
Prepare release evidence for the exact current main commit, including local
build, Apply Timeline, intended semantic version, semantic diff, and customer
impact. Distinguish first DRAFT activation from later ACTIVE GitHub Releases.
Stop for approval, publish once, and prove the release and optional frontend
converged. Do not treat enqueue as completion.