HomeEE · Deployment › Deployment runbook

Deployment runbook

Purpose: The standard sequence for a production release, with verification at every step — copy and adapt.

Who this page is for

AudienceWhy it matters to you
Platform engineersExecutors
All engineersKnow what happens to your code

Pre-flight (T-1 day)

Execution

1. AUTHOR  deploy artefact → wait bundles Active → /system/health green
           → author smoke: login, edit+publish a canary page
2. PUBLISH rolling, per instance:
           drain from LB → deploy → bundles Active + health green
           → direct smoke (render canary pages, .model.json, error.log scan)
           → rejoin LB → watch dashboards 5 min → next instance
3. DISPATCHER (only if config changed): apply via config pipeline → validate → reload
           → selective flush only for changed render output
4. VERIFY  end-to-end through CDN: canary pages, new feature checks, synthetic probes green
5. CLOSE   tag deployed, dashboards annotated, release channel notified

Verification is not optional decoration

Each arrow above has a concrete check with a pass condition. "Deployed fine" means: all bundles Active, health checks green, canary renders match expectation, error.log clean of new ERRORs for N minutes, dashboards flat. Anything else triggers the rollback decision tree, while the blast radius is still one instance.

Common deviations

SituationAdjustment
DB-like content migration in releaseRun migration step between author and publish phases, per its own plan
Dispatcher filter change for new endpointDispatcher step becomes mandatory, BEFORE publish smoke of that endpoint
Index definition changeDeploy, then monitor reindexing before calling it done (index management)

Quick navigation