notes
Nap CLI: deploys, and knowing what is actually running
The problem
Every project had its own deploy incantation, remembered imperfectly and usually at the worst moment. I wanted one command per verb — deploy, health, sync, changelog — and a reliable answer to "is what is running the same as what is committed?"
The shape
nap <verb> <project> → per-project recipe drift: running build id vs committed HEAD → report mismatch
The hard part
Answering "what is deployed?" requires the running service to report it, which means it has to expose its own build identity. Inferring it from the outside — file timestamps, directory contents — produces answers that are right often enough to be trusted and wrong often enough to hurt. Having each service report a version it knows about itself turned a guess into a fact.
The other lesson came from a deploy that appeared to succeed. The build step was piped into another command, so its failure was masked by the exit status of the last command in the chain, and the restart proceeded happily onto a half-written directory. Piping a build discards the signal that matters most; capture the status and gate the restart on it explicitly.