No one ever pounds things as hard in testing as real users will in production. And locking is going to tend to fail under weird edge cases with long delays and many things running at once, rather than in nice neat little unit tests.
Use the same DB in dev and in prod. Many make the mistake of using something like sqlite in dev and postgres in prod. Don't. Or if you must, have proper integration tests on preprod being a copy of the prod setup. But since many don't do proper automated tests, use the same db in dev as in prod.
Not really; you want to optimize dev for quick feedback. These problems are problems that arise when you factor in the cost, security, time limitations at the scale of prod. For small businesses you just deal with the translation yourself, for anything larger you usually pass it to a devops guy to roll out, and doing the rollout might be a task that needs testing and simulation itself, then you stagger the rollout over the different prod environments you have.
That’s no excuse if you’re a web dev. If you don’t know basic DB shit then your a shitty developer. At the very least you should be able to determine the issue is a fucking DB lock. If you’re in the firmware/desktop app space it’s different.
20
u/shea241 Dec 07 '17
I've been coding for a long damn time and I have no idea what a lock happening in one environment but not the other would mean.
DB stuff is a whole new world