Idempotent deployment
A deploy you can safely rerun: the same artifact and configuration converge on the same final state without duplicate side effects.
What it is
An idempotent deployment converges on a declared result: run it once or run it five times with the same artifact and configuration, and the environment ends in the same state. Declarative tools such as Terraform and Kubernetes are built around this idea. They compare current state with desired state and change only the difference. The word comes from mathematics and shows up in the HTTP spec for the same reason: PUT and DELETE are defined as idempotent, POST is not.
Reach for it anywhere a timeout, lost connection, or failed step may make you retry without knowing how far the first attempt got. A safe retry removes the worst deployment question: did that command fail before or after it created the resource?
Gotcha: repeatable scripts are not automatically idempotent. Appending the same config line, sending a welcome email, generating a fresh secret, or running an untracked SQL statement creates extra effects on every retry. Use stable identifiers, upserts, migration tracking, and explicit desired state, then test by running the deployment twice.
Ask AI for it
Make this Kubernetes deployment idempotent. Pin the container image by sha256 digest, express configuration in declarative manifests, and apply it with kubectl apply rather than imperative create commands. Replace append-only setup scripts with keyed upserts, run database changes through the existing migration table, and give every external resource a stable name. Add a CI smoke test that applies the same release twice, runs kubectl diff after the second apply, and fails if the second run changes resources or repeats a user-visible side effect.