Sacred Ground

Narrated

It’s Wednesday afternoon. You’re adding a new field to the trip database. A column for trip ratings, so users can rate their trips after they get back. Simple change. You write a database migration, the script that modifies the database structure. You run it.

Something feels off. The migration ran faster than expected. You check the database.

You’re looking at production data. Real users. Real trips. Real payment records. You just ran an untested migration against your production database from your laptop.

In this case, you got lucky. The migration was additive, it just added a column, so nothing was destroyed. But what if the migration had renamed a column? What if it had dropped a table? What if, instead of adding a ratings column, you were testing a script that deletes all trips older than a year, and it ran against five hundred real users’ vacation plans?

This happens to professional developers. It happens at large companies. It happens because the connection string in the environment file on someone’s laptop was still pointed at the production database from the last time they debugged an issue. One command, wrong database, catastrophe.

The root cause isn’t carelessness. The root cause is that development, staging, and production aren’t properly separated. When environments share resources, or when it’s even possible to accidentally reach production from a development machine, disaster is just one wrong command away.

Production is sacred ground. You don’t run experiments on it. You don’t test on it. You don’t connect to it from your laptop unless something is on fire. It has its own database, its own file storage, its own secret keys, and its own walls. And those walls need to be real, not just a promise that you’ll be careful.

Let’s build the walls.