Strategies to Edit Production Data
summary
Five concrete strategies for making SQL writes safer: keep a shared spreadsheet for audit trail and peer review; run Python migration scripts locally with a dry‑run flag; run long jobs on an existing server (eg. Jenkins) but watch CPU so it doesn’t take down deploys; use a task runner to enforce code review and capture logs; or build an internal Script Runner service that provides centralized credentials, environment separation and parallelism. Real failures include accidental UPDATE over all rows and slow runs across 50 million products.
AI-written summary · about
chapters (11)
- 0:00Intro
- 0:50Why We Edit Production Data
- 3:49Let's talk about strategies for safer editing
- 4:19Strategies for editing Raw SQL Local scripts Existing server Task runner
- 4:47How the strategy works What's great What's not great
- 5:08Develop a Review Process for Manual Edits
- 9:49Run Scripts Locally
- 12:55Run Scripts on an Existing Server
- 17:29Use a Task Runner
- 18:52Code review and automated tests
- 21:36Build a Script Runner Service
related talks
30mStrategies to Edit Production Data
27mStrategies to Edit Production Data
29mStrategies To Edit Production Data
29mStrategies to Edit Production Data
01h 01mKeep your nose out of it. Denying yourself access to production
24mDatabases beyond the tutorials
31mHelp! My Database Is The Bottleneck
21mPractical Deployment Strategies for Production Python Apps