4 ms·

> When I test my code, I want to know that it works in production. Staging, you can’t give me that. This sounds like more of a problem with the author's stagin

> When I test my code, I want to know that it works in production. Staging, you can’t give me that. This sounds like more of a problem with the author's staging environment than a general issue with the concept of staging environments. The idea is staging and production should mirror eachother as closely as possible. If your staging environment is wildly different, of course it will be less useful. But it's also your responsibility to maintain a useful-enough staging environment. Why not just say, "it's too much effort for me to maintain a separate, identical environment" rather than dismiss the concept entirely?

hinkley 6y ago
It sounds like a problem with the author, one probably drilled into their head by management. The longer you are here, the more weird shit you see, and the definition of “know” gets a lot murkier. You aren’t going to “know” if it works in production, even if you put it into production. Which is something that only makes sense about the fourth time you encounter a piece of shipping code that is so fundamentally rotten that you are not sure how it ever came up with the right answer. You don’t know if the whole car is working. You only know it’s moving the direction you wanted it to move and it hasn’t exploded, made horrible sounds, or smells. So it’s mostly working. Every tool and process should be working to make you less afraid of trying things (like deploying to prod). Otherwise they’re just helping you build a bureaucracy instead of software.
- sjellis 6y ago
  Yes, it's about confidence levels. There will always be known differences between staging and production, e.g. service names, networking. The point about staging is that it lets you run risk-free tests on a set of things, in a way that give you confidence about the things that are the same as production. The fact that a set of things works in staging is never an absolute guarantee that it will work in production. If you are in the position of needing to ship releases rapidly, and you can't run meaningful tests in the available time, then no, it's not useful.

hinkley 6y ago

It sounds like a problem with the author, one probably drilled into their head by management. The longer you are here, the more weird shit you see, and the definition of “know” gets a lot murkier. You aren’t going to “know” if it works in production, even if you put it into production. Which is something that only makes sense about the fourth time you encounter a piece of shipping code that is so fundamentally rotten that you are not sure how it ever came up with the right answer. You don’t know if the whole car is working. You only know it’s moving the direction you wanted it to move and it hasn’t exploded, made horrible sounds, or smells. So it’s mostly working. Every tool and process should be working to make you less afraid of trying things (like deploying to prod). Otherwise they’re just helping you build a bureaucracy instead of software.

sjellis 6y ago
Yes, it's about confidence levels. There will always be known differences between staging and production, e.g. service names, networking. The point about staging is that it lets you run risk-free tests on a set of things, in a way that give you confidence about the things that are the same as production. The fact that a set of things works in staging is never an absolute guarantee that it will work in production. If you are in the position of needing to ship releases rapidly, and you can't run meaningful tests in the available time, then no, it's not useful.