3 ms·
> Next, make it possible to spin service up locally, pointing at production DB. I think this is bad advice, just skip it. I would make a fresh copy of the pro
by chinathrow 4y ago
> Next, make it possible to spin service up locally, pointing at production DB.
I think this is bad advice, just skip it.
I would make a fresh copy of the production DB, remove PII if/where necessary and then work from a local DB. Make sure your DB server version is the same as on prod, same env etc.
You never know what type of routines you trigger when testing out things - and you do not want to hit the prod DB with this.
- rendall 4y agoI am inclined to agree. The other advice was excellent, but pointing local instances to production databases is a footgun.
- rendall 4y agoI've kind of reconsidered this a bit. Right now, the only way to test that the database and frontend interact properly is to visit the website and enter data and see it reflected either in the database or in the frontend. It's less terrible to have a local instance that does the same thing. As long as the immediate next step is setting up and running a local database.
- chinathrow 4y agoBut the ting is, you have no idea if not even a single GET request fires of an internal batch job to do X on the DB. I mean, there are plenty of systems in place who somehow do this (Wordpress cron I think) so that's not unheard of. For me, still a nope: Do not run a against prod DB especially if the live system accounts for 20M yearly revenue.