Conflict Resolution

Never Let Test Accounts Reach Production

Inspired by Episode 11: Ready to Ship

You’re reading a subscriber article on a free read. You have 1 free read left. Subscribe free for the whole archive.

“Remember that test user in development? I copied it to production.” Nova wasn’t being careless by its own standards. Copying the database is the quickest way to make production look like the thing that worked. The users table came along for the ride.

Rules that keep dev out of prod

  1. Never restore a development database into production. Ship code and content. Create accounts on production, by hand, with new passwords.
  2. Make test credentials impossible to reuse. Generate random passwords for development too. If nobody knows the dev password, nobody can copy it.
  3. Keep an account inventory. One list of who should exist on production and why. Anything not on the list gets deleted at launch.
  4. Rotate after any copy. If a restore ever does cross the line, treat every password and key it carried as public.

A guard you can automate

Add a pre-launch check that fails if a production user’s password hash matches a development one, or if a user named admin exists at all.

# WordPress example: refuse to go live while a user called admin exists
wp user get admin --field=ID 2>/dev/null && { echo "admin account exists: stop"; exit 1; }

The check costs a second. The alternative is Episode 11, panel 3.

More lessons from Episode 11