Ship Checklist
The last pass before a change goes out — what to verify, in the order that catches the most for the least time.
When to reach for it
In the minutes between “it works on my machine” and merging or deploying, especially when you are tired, late, or shipping something you only half remember writing.
What changes
- You read your own diff end to end before anyone else does, which is where debug output, a hardcoded local URL, a stray key and a half-finished rename get caught.
- The change is exercised through the door a user comes in by — the button, the endpoint, the command — not only through the test written for it.
- Everything the change needs in the target environment is checked to exist there: env vars, migrations, flag states, lockfile entries.
- You name the signal you will watch after deploy and the one that means back it out, so “keep an eye on it” becomes a specific thing to look at.
- The change leaves with a three-line note: what changed, what to watch, how to undo it.
Pairs with
- Migration SafetyChange a schema or move data without ever creating a minute where the running code and the database disagree.
- Own the Generated CodeTakes responsibility for code you did not type, before other things start depending on it.
- Rollback PlanWork out how you would undo the change before you make it — and find out early when the honest answer is that you cannot.
Ship Checklist
The pass between "it works" and "it is out". This order, because this order finds the most for the least time.
1. Read your own diff, all of it
Top to bottom, as a reviewer would, before anyone else sees it. You are hunting for what you did not mean to send: debug output, commented-out attempts, a local URL, a credential, a rename that stopped halfway, a file that has no business in this change.
2. Check that it is one change
Anything in the diff that does not serve the stated purpose comes out and goes in its own change. A change you cannot describe in one sentence is one you cannot undo in one step.
3. Exercise it the way a user reaches it
Not through the test. Through the real entry point: the screen, the endpoint, the command. Walk the happy path once, then the failure you already know about — bad input, no permission, no network — and watch what the user actually sees when it happens.
4. Diff the environment, not only the code
For each thing the change depends on, confirm it exists where this is going:
- New environment variables and secrets, set in the target
- Migrations, and the order they will run in
- Feature flags, in the state you expect at launch
- New dependencies present in the lockfile and in the built artifact
- Anything that must ship first so the version already running does not break the moment this lands
5. Decide what you will watch
Name the signal that says this worked and the one that says it did not: an error rate, a queue depth, a specific log line, a support message. If nothing in the system would tell you either way, add the log line before you ship, not after.
6. Say how it comes back out
One sentence: revert and redeploy, turn the flag off, or the specific steps if data was touched. If that sentence is hard to write, the change is not ready to go.
7. Write the note
Three lines that travel with the change: what changed, what to watch, how to undo it.
Rules
- Do not skip the diff read because you wrote it. You are reading for what you forgot, and forgetting is invisible from memory.
- Do not ship a change whose only evidence is a passing test.
- Do not fold an unrelated cleanup into a risky change.
- Do not ship into a window you will not be around for. Ten minutes late is cheaper than eight hours absent.
- Do not treat a green pipeline as the end of the list. It is one item on it, and it only knows what someone thought to check.