4

Sometimes I don't get "don't test on production".
And I'm definitely not a front-end guy, I only have debug and release in mobile development.
And I definitely often test on release, because it may be broken while debug build works fine.
You know what that means?
1. Test locally
2. Try to fix issues
3. Realize that this issues would ever appear ONLY locally
4. Move to staging and test
5. Fix issues
6. Realize that most of them are caused by workarounds for localhost
7. Move to production
8. Realize that everything is fucked up and you don't have any idea why, because `h5aqq2 was called on null"

Comments
  • 1
    It's misunderstood.

    It means your stack should be in a state where there's never any need for you to test on production, because everything can be reproduced in a dev environment.

    If it's not, or if it is but the bug is with a dependent service that can only be called from your live stack for compliance reasons, then as you say, you have no choice.
  • 0
    @AlmondSauce you are right, I guess. But I don't have time/knowledge/patience to setup all this shit. At least I were very carefull all the time and never dropped production database... yet
  • 0
    i guess a combination of eslint and e2e tests help a lot with this, but e2e tests a pain in the ass to write
  • 0
    @AlmondSauce ah, the good old days of having a budget for test servers.. ive been the victim of extreme budget cuts, I'm amazed I actually have a production system at this point
Add Comment