4 ms·

> We only merge code that is ready to go live. In their perception, is the rest of tech industry gambling in every pull request that some untested code would w

> We only merge code that is ready to go live. In their perception, is the rest of tech industry gambling in every pull request that some untested code would work in production? I work at a large company. We extensively test code on local machines. Then dev test environments. Then small roll out to just a few data centers in prod bed. Run small scale online flight experiments. Then roll out to the rest of prod bed. And I've seen code fail in each of the stages, no matter how extensively we tested and robustly code ran in prior stages.

Sebguer 5y ago
Yeah, it seems like someone took RFC 9225 to heart. (https://www.rfc-editor.org/rfc/rfc9225.html https://www.rfc-editor.org/rfc/rfc9225.html)
- kafrofrite 5y ago
  I wouldn't be surprised. I've seen colleagues reference April's Fools RFCs, and the reference wasn't meant to be taken as a joke.
drewcoo 5y ago
> I've seen code fail in each of the stages How many of the failures caught in dev would have been legitimate problems in production? How about the ones in staging? If your environments are that different are you even testing the right things? And if yes, if you need all of those, then why not add a couple more environments? Because more pre-prod environments means more bugs caught in those, right? /s
- aniforprez 5y ago
  What? What even is this The whole point of a dev environment is so you can catch errors you wouldn't in production. Keeping it as close as possible to production is the point. If you're catching errors in dev, you'll see them in production More environments don't catch more bugs. What is this corollary? More testing catches more bugs. A dev environment allows free integration testing without act users of production being affected
  - aniforprez 5y ago
    I believe they edited the post to indicate sarcasm after I saw it which is a relief. I got pretty fired up
deleted 5y ago
[deleted]
joshuamorton 5y ago
Generally speaking yes, I think that if you aren't hiding stuff behind feature flags you're gambling.
- thefreeman 5y ago
  just because you have a staging environment doesn't mean you shouldn't use feature flags.

Sebguer 5y ago

Yeah, it seems like someone took RFC 9225 to heart. (https://www.rfc-editor.org/rfc/rfc9225.html https://www.rfc-editor.org/rfc/rfc9225.html)

kafrofrite 5y ago
I wouldn't be surprised. I've seen colleagues reference April's Fools RFCs, and the reference wasn't meant to be taken as a joke.

drewcoo 5y ago

> I've seen code fail in each of the stages How many of the failures caught in dev would have been legitimate problems in production? How about the ones in staging? If your environments are that different are you even testing the right things? And if yes, if you need all of those, then why not add a couple more environments? Because more pre-prod environments means more bugs caught in those, right? /s

aniforprez 5y ago
What? What even is this The whole point of a dev environment is so you can catch errors you wouldn't in production. Keeping it as close as possible to production is the point. If you're catching errors in dev, you'll see them in production More environments don't catch more bugs. What is this corollary? More testing catches more bugs. A dev environment allows free integration testing without act users of production being affected
- aniforprez 5y ago
  I believe they edited the post to indicate sarcasm after I saw it which is a relief. I got pretty fired up

deleted 5y ago

[deleted]

joshuamorton 5y ago

Generally speaking yes, I think that if you aren't hiding stuff behind feature flags you're gambling.

thefreeman 5y ago
just because you have a staging environment doesn't mean you shouldn't use feature flags.