Skip to content

Release Gate Runbook

  • Status: CANONICAL CURRENT
  • Owns: bounded CTC deployment through qa -> master, Production DB compatibility preflight, mandatory migration confirmation, Wiki DB synchronization and Git readback
  • Does not own: Product/Task priority, current DB facts, migration implementation, restriction policy, provider/config effects or infrastructure repair
  • Durable decision: Current Context §19
  • Operations rule: PROJECT_OPERATIONS.md
  • Deployment continuity: DEPLOYMENT_DB_WIKI_CONTINUITY.md
  • Task overlay: DEPLOYMENT_DB_WIKI_REQUIREMENTS.md
  • Wiki policy: WIKI_DB_SYNC_POLICY.md

1. Purpose

CTC Git deployment is:

QA_COMMIT_PUSH
+ MASTER_MERGE
+ QA_MASTER_PARITY_READBACK

The Production server automatically pulls master every two minutes. Normal deployment does not include a service restart or manual server pull.

This runbook prevents source from reaching master while a required DB migration is absent or unknown, and keeps Production Wiki pages synchronized when user-facing behavior changes. If the exact existing slug is absent in Production, create one bounded stable slug in the same delivery.

2. Authorization

Unless the user explicitly requests qa-only review, the following phrases authorize the full Git deployment set for the exact bounded scope:

commit
push
commit and push
deploy
release
ship
finish and deliver
apply the task

They do not automatically authorize:

  • an unlisted restriction delta;
  • DB migration/backfill/config row changes;
  • provider/credential/config/account effects;
  • renamed/retired/deleted Wiki pages or visibility changes;
  • manual server changes, service restart, backup or restore.

The user has provided standing authorization for bounded same-delivery updates to exact existing mapped Wiki slugs and creation of bounded new stable slugs under WIKI_DB_SYNC_POLICY.md.

3. Release Candidate Inputs

Collect:

current qa/master heads
exact prepared candidate and final diff
changed source/documents
current normal user paths
restriction delta
DB dependency matrix
migration files/objects/required data
Production DB state evidence
migration user-confirmation state
Wiki impact and exact slugs
selected verification
rollback

Do not begin QA_COMMIT_PUSH until the DB dependency Gate is resolved.

4. DB Dependency Gate

Classify:

NOT_REQUIRED
APPLIED_AND_VERIFIED
REQUIRED_NOT_APPLIED
REQUIRED_STATUS_UNKNOWN
BACKWARD_COMPATIBLE_STAGED

Review both explicit migration files and implicit source dependencies on schema/data/config state.

Confirmation required

When state is REQUIRED_NOT_APPLIED or REQUIRED_STATUS_UNKNOWN, ask the user before QA_COMMIT_PUSH.

The question states:

candidate and target environment
migration IDs/files/objects
current evidence state
failure/outage risk
old-schema compatibility
safe options and rollback

Choices:

migration already applied
apply exact migration before master merge
use/revise proven backward-compatible staged candidate
postpone/cancel

A known incompatible candidate never moves to master while its required migration is absent.

When application is authorized:

QA_COMMIT_PUSH
-> apply exact migration
-> authoritative DB readback
-> MASTER_MERGE

5. Wiki Impact Gate

Classify:

NOT_APPLICABLE
UPDATE_EXISTING_REQUIRED
CREATE_NEW_REQUIRED
CREATE_OR_RETIRE_DECISION_REQUIRED
SYNC_BLOCKED
COMPLETE

UPDATE_EXISTING_REQUIRED and CREATE_NEW_REQUIRED are standing-authorized same-delivery effects when:

  • exact existing mapped slug is named;
  • content reflects verified released behavior;
  • prior row/content is captured, or absence is captured for a new slug;
  • a new page inherits current visibility and maps only to an already accessible application page when mapped;
  • no rename/retirement/deletion/visibility change occurs;
  • DB and available rendered readback are planned.

Rename/retirement/deletion, role visibility, navigation or bulk publication requires an explicit user decision.

Internal agent-governance and non-user-facing engineering releases normally use NOT_APPLICABLE.

6. Minimum Verification By Change Type

Change Minimum evidence
Documentation/agent rules only final diff, link/authority/precedence review, DB dependency = NOT_REQUIRED, Wiki classification
PHP/source logic syntax/focused contract plus DB dependency review
API/DB-backed behavior exact route/query/transaction, target DB dependency state, rollback
UI/workflow current role normal path, exact visible result, DB dependency and Wiki slug impact
DB migration exact target, before state, apply result, schema/data readback, rollback
Wiki existing/new-slug sync previous hash/content or confirmed absence, exact write, DB readback, rendered readback when available
Git deployment exact qa candidate, master merge, final parity
Runtime verification exact deployed source/behavior after normal auto-pull cycle

Report PASS, FAIL, BLOCKED, NOT_RUN and NOT_APPLICABLE honestly.

7. Pre-Deployment Sequence

  1. Fetch/re-read remote qa and master.
  2. Confirm current checkout remains qa.
  3. Confirm exact bounded candidate and concurrent changes.
  4. Review final committed/working range and allowed paths.
  5. Resolve restriction Gate.
  6. Build DB dependency matrix.
  7. Resolve mandatory migration confirmation when triggered.
  8. Classify Wiki impact and exact slugs.
  9. Run selected checks.
  10. Confirm rollback for source, DB and Wiki effects.
  11. Re-read remote refs immediately before the write.

If either ref or the candidate changes, repeat affected DB/Wiki/restriction analysis.

8. Authorized Deployment Path

Step 1 — QA_COMMIT_PUSH

one final writer integrates current qa checkout
-> one bounded commit/squash result
-> push qa
-> read back exact qa SHA/content

Step 2 — DB migration, only when selected and authorized

apply exact migration to named target
-> authoritative schema/data readback
-> stop on failure/unknown result

Step 3 — MASTER_MERGE

re-read current master
-> merge exact approved qa candidate
-> fast-forward when valid, otherwise explicit merge commit
-> no independent master-only source commit
-> read back master

If master moved, integrate current master into qa, revalidate the candidate and DB dependencies, then create a new final candidate.

Step 4 — Parity

if merge commit created -> synchronize qa to same merge commit
verify qa HEAD == master HEAD
verify expected bounded content

Step 5 — Wiki synchronization, when required

capture/confirm prior exact Production slug row or its absence
-> write the exact existing or bounded new Production slug once
-> DB row/hash readback
-> rendered readback when available

Step 6 — Auto-pull expectation

master auto-pull interval = 2 minutes
service restart = NOT_APPLICABLE
manual server pull = NOT PERFORMED

Runtime verification, when authorized, occurs after a normal pull cycle or through exact deployed-source evidence.

9. Failure Handling

Migration confirmation unresolved

Stop before QA_COMMIT_PUSH; report DB_MIGRATION_CONFIRMATION_REQUIRED.

Migration apply/readback failed

Stop before MASTER_MERGE. Preserve exact qa SHA, DB evidence and rollback state. Do not call deployment complete.

Master moved

Integrate safely into qa, revalidate and continue the same deployment set. Do not force-push.

Wiki write unknown

Stop replay, reread exact slug/row/hash and classify APPLIED, MISSING, PARTIAL or UNKNOWN.

Wiki temporarily unavailable during urgent fix

Allow the safe source deployment to finish, report DEPLOYED / WIKI_SYNC_BLOCKED, preserve the exact continuation package and do not call the total user-facing delivery complete.

Auto-pull problem

Treat as a separate infrastructure incident. Do not restart services or manually edit/pull the server without explicit recovery authorization.

10. Rollback

Source rollback uses the same Git set:

bounded revert/fix on qa
-> QA_COMMIT_PUSH
-> required DB rollback/forward-fix decision
-> MASTER_MERGE
-> parity
-> affected Wiki rollback/update

Do not force refs backward or broadly restore unrelated DB/Wiki state.

11. Completion Evidence

Git deployment complete
= exact qa commit + exact master merge + final parity

DB dependency safe
= NOT_REQUIRED / APPLIED_AND_VERIFIED / proven BACKWARD_COMPATIBLE_STAGED
  or exact user-confirmed path completed

Wiki delivery complete
= NOT_APPLICABLE or required existing slugs written/read back

service restart
= NOT_APPLICABLE / NOT PERFORMED

Runtime verified
= separately collected after auto-pull

Final report:

pre-deployment qa/master
qa commit SHA
master merge SHA/method
final parity
DB dependency state
migration confirmation/effect/readback
Wiki impact/slugs/write/readback
master auto-pull: 2 minutes
service restart: NOT_APPLICABLE
Runtime verification
rollback/residue

---

Source: docs/runbooks/RELEASE_GATE_RUNBOOK.md — ctc repository · This page is an English translation of the source document. Identifiers, file paths and code symbols are unchanged.