A deploy is an outward-facing, hard-to-undo action. The goal is to ship often AND make a bad release boring to recover from. Confirm before deploying unless the user has clearly authorized it.

Ship the tested artifact. Deploy the exact build CI verified — don't rebuild or hand-tweak on the way out.
Roll out gradually. Prefer canary / staged / blue-green over flipping 100% at once. Watch the new version's health (errors, latency) before widening.
Have a rollback ready BEFORE you ship. Know the one command/step to revert, and that the previous version still works. Rollback should be faster than forward-fix.
Decouple deploy from release. Use feature flags so you can deploy code dark and turn behaviour on/off without a redeploy — and kill it instantly if it misbehaves.
Backwards-compatible steps. Don't ship a code change that requires a not-yet-run migration, or drop something the old version still uses (see database-migrations' expand/contract).
Verify after. Check health/metrics post-deploy; don't declare success on "it deployed" — declare it on "it's serving correctly" (see verify-before-done).
If anything looks wrong, roll back first, diagnose second (see incident-response).

Más de este repositorio

mismo repositorio

react-doctor

New1Direction/korgex

Catch bad React in your changes — run react-doctor's deterministic scan and fix what it flags

2026-06-055

security-scan

New1Direction/korgex

Run a verifiable security scan (vulns, secrets, misconfig) over code you wrote or deps you added, before calling the work done

2026-06-035

browser-automation

New1Direction/korgex

Drive a real browser verifiably — navigate, snapshot, act BY INDEX, extract; every step provable

2026-06-025

verifiable-orchestration

New1Direction/korgex

Run multi-agent work as ONE provable causal DAG — parallel subagents, an Orchestrate graph, an immutable spec-seed

2026-06-025

building-an-mcp-server

New1Direction/korgex

Author or connect a Model Context Protocol server so an agent gains new tools

2026-06-015

ci-cd-pipelines

New1Direction/korgex

Build automated pipelines that gate merges and ship reliably

2026-06-015

name	deploying-safely
description	Ship to production with staged rollout, health checks, and a fast rollback
version	1
trust	built-in

A deploy is an outward-facing, hard-to-undo action. The goal is to ship often AND make a bad release boring to recover from. Confirm before deploying unless the user has clearly authorized it.

Ship the tested artifact. Deploy the exact build CI verified — don't rebuild or hand-tweak on the way out.
Roll out gradually. Prefer canary / staged / blue-green over flipping 100% at once. Watch the new version's health (errors, latency) before widening.
Have a rollback ready BEFORE you ship. Know the one command/step to revert, and that the previous version still works. Rollback should be faster than forward-fix.
Decouple deploy from release. Use feature flags so you can deploy code dark and turn behaviour on/off without a redeploy — and kill it instantly if it misbehaves.
Backwards-compatible steps. Don't ship a code change that requires a not-yet-run migration, or drop something the old version still uses (see database-migrations' expand/contract).
Verify after. Check health/metrics post-deploy; don't declare success on "it deployed" — declare it on "it's serving correctly" (see verify-before-done).
If anything looks wrong, roll back first, diagnose second (see incident-response).