A checklist before shipping

once per project and once per release

What it is

Two lists. The first is worked through once, at the start of a project, and costs dearly if forgotten. The second runs before every release, and is worth keeping right in the repository, next to the code.

Once per project

1. The application identifier. Not com.example. It can't be changed after release (article 12.2).

2. The signing key and its backup. In two places, neither of them your working computer.

3. The .gitignore — checked by hand, not taken on trust. Here is a real .gitignore from a fresh template of a popular bundler:

node_modules
dist
dist-ssr
*.local

There is no line for .env in it. The check: create a .env file with a key and do an ordinary git add -A:

$ git ls-files | grep -c "\.env"
1

The secret has gone into the repository. Not because somebody made a mistake, but because that is how the template is built: *.local covers .env.local, not .env. Hence the rule: after the first commit, look with your own eyes at what exactly landed in the repository:

git ls-files

Once, at the start, while the history is short. Removing a file from the history afterwards is far harder than not adding it.

4. The exact-versions file is committed — package-lock.json, pubspec.lock, poetry.lock (article 12.1).

5. The build is tested from a clean clone. Not from your own folder where everything already works, but like this:

git clone <your repository> /tmp/trial
cd /tmp/trial && npm ci && npm run build

That is the only way to find out that the project builds somewhere other than your machine. Everything that was only on your disk and never committed shows up here.

6. The version is visible in the application itself. A line on the "about" screen or in the site's footer. Without it a conversation with a user about a breakage is impossible.

7. The hosting's caching settings. Hashed files for a long time, index.html never (article 12.3).

8. Logs and errors are collected somewhere. Otherwise you learn about breakages from users.

Before every release

1. The checks aren't switched off. Whatever checks the build is still in the build command: tsc -b, mypy, flutter analyze. Whether they were switched off since last time is something to look up in the change history, not to remember.

2. The tests have been run. At least the ones that exist (chapter 4).

3. A build from scratch. Delete dist, build and the dependency folder and build again. Old artifacts are good at hiding breakage.

4. A search for secrets in the artifact. Literally:

grep -r "sk-\|secret\|password\|api_key" dist/

If something is found, that is a leak, not a nitpick (article 12.1).

5. The assets are there. Images, fonts and data files are declared in the build settings and present in the artifact.

6. The version is raised. For a store, the number has to grow.

7. You ran the artifact, not the sources. Open the built folder, install the built package, put the built .apk on a phone. Checking the sources checks something other than what the user will get.

8. API and database changes worked through per article 12.3. What was added, what was renamed, what can't be rolled back.

9. The rollback is written down. One line: the command or the number of the previous release. It has to be written before shipping, because afterwards there won't be time.

What to tell the AI

Draw up a shipping checklist for my project.
Stack: <list it>. Shipped to: <where>.
Split it into "once per project" and "before every release".
Only what applies to my stack, no general advice.
Format it as a list I'll put in the repository.

The resulting file is worth keeping in the project and adding to every time something breaks. A checklist grown out of your own mistakes works better than any ready-made one.

Here is my .gitignore: <contents>.
What that's usual for this stack isn't covered?
Separately: which of the already-committed files look like
secrets.

I've built the project. Write the commands to check the
artifact before shipping: searching for secrets, checking
the assets are there, running the built version. For my OS:
<which>.

What to look for

The checklist is in your head. Until it is written down, it is different every time.

"I'll check later". Shipping is the one step after which "later" means "at the users".

An edit made straight in the artifact. A file patched in dist/ or on the server for a quick fix. The next build wipes it and the breakage comes back — now with no explanation.

Shipping with no way back. You don't know how to restore the previous version until you have tried.

Cheat sheet