3 ms·
....but then when you run it in production, your app fails, because it was designed against assumptions around the fake cluster and pod, or a different config f
by 0xbadcafebee 5y ago
....but then when you run it in production, your app fails, because it was designed against assumptions around the fake cluster and pod, or a different config file. I'm not saying there's a solution to this, but we should remind people that "we can pretend X is Y" is a reproducibility red flag.
- znpy 5y agoThere are step between development laptop and production you know, smarty pants? Like, a staging cluster? A pre-prod cluster?
- 0xbadcafebee 5y agoWhich then creates its own special snowflake environment which isn't either dev or prod, and duplicates resources, and can only test one change at a time (unless you have real ephemeral environments, and most people don't). It's better to have blue/green, or something like blue green, and use that as staging, than have an actual dedicated "staging cluster". But like I say, dev still is far from close to that. So you end up doing a lot of development in dev, and then fixing a ton of things in staging because you weren't developing against staging. And your tests aren't fantastic, so some bugs make it through both staging and prod, and it turns out they're because your design was making assumptions based on dev. Hence, make dev and prod as close as possible, and then you don't need to have "staging", because you have confidence that what worked in dev will also work in prod.