CI asserts the deployment strategy and two-instance serving floor.
Delivery discipline
Blue/green is a proof sequence.
Routine application releases replace the complete stateless web fleet beside the serving version, require readiness before promotion, verify the deployed identity, and preserve an immutable recovery path.
BLUE / SERVINGPrior fleettraffic
readiness → promoteGREEN / CANDIDATEReplacement fleetprove first
Last verifiedAugust 10, 2026
ScopeCinch application and public-marketing repositories
PostureCurated public engineering snapshot
Release sequence
Promotion is the fifth step, not the first.
Each handoff narrows ambiguity between reviewed source, candidate artifact, serving revision, public behavior, and recovery target.
- 01Build
Create immutable candidates from the exact reviewed source revision.
- 02Prove
Run build, policy, security, migration, role, and compatibility gates before deployment.
- 03Stage green
Start the complete replacement web fleet beside the serving blue fleet.
- 04Verify
Require readiness from every candidate and exercise private plus public journeys.
- 05Promote
Move traffic once, confirm the public release identity, and keep routine sync untouched.
- 06Observe + recover
Retain the prior immutable image and recovery command through the rollback window.
What the discipline proves
Interruption-resistant, with limits stated.
Two production promotions exercised the complete replacement fleet, exact source identity, post-cutover public checks, and an unchanged serving synchronization process.
Every replacement instance passed health before the prior fleet was cordoned.
The public release endpoint matched the exact promoted source revision.
Routine web releases proved the serving stateful sync image did not change.
EVIDENCE GAP
“Zero interruption” remains intentionally unclaimed. Active authenticated-session and WebSocket continuity through promotion still needs an instrumented test, and the current synchronization singleton has its own maintenance and host-failure limits.
Recovery posture
Rollback is prepared before promotion.
The old fleet is not kept running indefinitely. Recovery uses the recorded immutable prior image and guarded command while monitoring distinguishes web, sync, data, and client-reconnect behavior.
01Record
Prior image, expected source, and recovery operation.
02Observe
Readiness, public journeys, private dependency proof, and release identity.
03Decide
Operator evaluates evidence inside a bounded rollback window.
04Recover
Promote the known immutable predecessor through the same guarded boundary.
Next chapter