4 ms·
For schema/index changes I prefer migrations. These should be committed along side the code, tested, and promoted through environments. This largely prevents
by siliconc0w 11y ago
For schema/index changes I prefer migrations. These should be committed along side the code, tested, and promoted through environments. This largely prevents dependency issues because the migrations are ordered.
Devops is like 80% dependency management. It's painful initially but you have to crack down on manual changes to production - all production changes should be defined in code, committed to git, tested, and flow through non-prod environments first. (just had an outage yesterday that was essentially because I failed to do this)
- deleted 11y ago[deleted]
- rawnlq 11y agoDo people even test for perf issues in non-prod environments?
- toomuchtodo 11y agoI've found it to be extremely difficult to replicate production workloads in staging/development.
- egwor 11y agoIf it's a requirement to be within X performance then yes.
- siliconc0w 11y agoYes you can do scaled down testing in non-prod. An example test may try 100,000 or 1,000,000 operations when in production you might see 100,000,000. So you won't catch subtle performance problems but you'll catch order of magnitude problems (i.e something that is O(n) vs O(log(n)) Although in this case the test for this change may just EXPLAIN a known query and ensure the output matches what is expected.
- Alan01252 11y agoI try to at least have the slow query log on and monitored in staging. It's pretty easy to forget an index and not notice in a dev environment.
- kevan 11y agoWe do in a staging environment, but usually only with releases where we think something we changed will cause a major difference in how the app behaves under heavy load. It's not cheap to keep a full staging environment around, but when you're playing around with CDN optimizations it's a lifesaver.