Bea Sørensen

I start with the step that is skipped and the one that cannot be: verifying the configuration before it is applied, on the server, with the same binary that will load it. Reload and restart are different operations. A reload asks the server to read its configuration again and keep serving, and a restart stops accepting connections first. A configuration file that parses but refers to a file that does not exist passes a syntax check and fails on load, which is the case the test has to catch. A single server cannot be both. There is a window during a restart where connections are refused, and a deploy that restarts a single instance has an availability cost that appears in the metrics as a blip on every deploy. Running two instances behind something that balances is the usual answer. A health check that returns success while the process is failing its dependencies makes a rollout appear healthy during an outage. The check should test what users need, which usually means a real query. Database changes sit outside this whole sequence and are the most common cause of a deploy that cannot be undone. A change that is incompatible with the previous version of the application cannot be deployed in the same step as the code that stops using it, and splitting it into two deploys is the reason that step exists. I finish on rollback, because a deploy you cannot reverse is a different activity from one you can.