Deployment

A change that races to zero traffic but lands when nobody is watching trades one risk for another. The best window is one where the operators responsible can actually attend. Traffic is only part of the math Deploying at the absolute quietest hour minimizes how many users feel the change, but it collides with the people problem: the operator is most likely asleep, unreachable, or already covering another incident. If the rollout breaks at 3 a.m. and nobody is watching, a silent failure can run for hours before a human reads it. Least-traffic is a good starting estimate, but it is a traffic answer, not a risk answer. Balance reduced exposure against the ability to react, and prefer a window where you can actually observe the result. ...

Small batches are the whole trick: a wave stops an old pod only after the replacement is already healthy. Instead of flipping the entire fleet at once — the all-or-nothing gamble of a recreate deployment — the controller keeps most of the old version serving while it proves the new one, pod by pod. A bad image then stalls the rollout with the old version still up, rather than replacing a working fleet with a broken one in seconds. ...

A staging test establishes facts about the artifact and environment that actually ran. Building again before production creates another output whose identity must be checked or whose behavior must be revalidated. Promotion carries an already verified artifact to the next environment and records that decision. It removes one source of uncertainty, but it does not make staging and production equivalent or eliminate the need to verify the resulting deployment. ...

Deploying code and exposing it are different acts. A feature flag is a runtime switch that decides whether shipped code is active, letting you release continuously and switch behaviour without redeploying. Ship hollow, then turn on A feature flag splits the moment code ships from the moment users see it. The default value is off, the new code path is hidden behind the flag, and shipping changes nothing visible until the operator flips it. That decoupling is what lets a risky feature ride the normal release train: the deploy is reversible by turning a flag off, which is a faster rollback than replacing a build. Release and exposure become two separate verbs, so you can ship on a Tuesday and light the feature up when the room is actually watching. The empty shell also lets you validate deploy-time behavior — pod count, startup errors, metrics — with zero user-facing change. ...

Two full environments for the same service, both able to serve, with a router deciding which one receives traffic. The new version is deployed to the idle colour and runs the entire pipeline — provision, migrate, deploy, smoke test — while the live colour keeps serving. When the tests pass, the release happens as a routing change. ...

Deploys are where engineering risk meets production. A change flipped to 100% at once converts any mistake into an all-or-nothing incident. A rollout by phases turns the same change into a series of small, reversible measurements. Equal percentage is not real safety Reaching a 100% cutover in one step is not speed, it is a bet that you can read a log before the whole fleet dies. Percentage as a number is meaningless on its own, because 50% of traffic to a service you broke is still a full incident. What a progressive rollout actually buys is reversibility: the ability to stop and pull back while most users are still on the old version, so a bad change at 5% is discovered and reverted while 95% of users never felt it. That property, not the arithmetic of the percentage, is the point. ...

HSTS is cached browser policy, so a configuration mistake can outlive the server change that created it.

Prepare the TTL ahead of time, observe authoritative and recursive answers, and keep both endpoints valid through the cache window.