4 ms·

If your question is, "I really like the status quo and don't want to change anything, how could eliminating staging environments help me," the answer is obvious

If your question is, "I really like the status quo and don't want to change anything, how could eliminating staging environments help me," the answer is obviously, "it can't."

thih9 4y ago
This comment feels needlessly defensive. I never said "I don't want to change anything", I gave reasons for rejecting changes.
- jdlshore 4y ago
  I overreacted. Let me try again. Your original question was, paraphrased, "how do we give non-tech product owners early access without a staging environment?" The canonical answer, from organizations that do this, is to use feature flags that are tied to user accounts. But this requires a certain level of engineering maturity—specifically, something that looks a lot like continuous deployment. There's a bunch of things that go along with continuous deployment, but one of them is continuous integration (the practice, not the poorly-named build servers), which is a combination of trunk-based development and frequent merges to the trunk. This requires programmers to hide incomplete work behind feature flags (or keystones¹). There's an associated set of practices for dealing with schema changes that I'd be happy to describe. People who are using feature flags (and associated practices) don't have "code that's not ready to merge." That's the whole point of the feature flags—to allow them to merge and deploy unfinished code. So when you put the constraint of "our code isn't ready to merge" on my "use feature flags" answer, I thought you weren't engaging in good faith, because it's kind of nonsensical—like saying risk of sunburn prevents you from using sunscreen lotion. I apologize for misconstruing. I assume what you really meant was, "We aren't able to use feature flags to merge and deploy incomplete code." That's a perfectly fine answer! But you asked how people share incomplete work when they don't have a staging environment, and the answer is, "feature flags."² Specifically, they deploy incomplete work to production and use feature flags to selectively hide and show it. If you can't do that, then it's probably best to keep your staging environment. ¹Keystones: https://martinfowler.com/bliki/KeystoneInterface.html https://martinfowler.com/bliki/KeystoneInterface.html ²For teams that use keystones, but not feature flags, pairing with stakeholders (screen sharing) is another approach I've seen used. It has the advantage of being simpler. But I agree that it's more constraining.

If your question is, "I really like the status quo and don't want to change anything, how could eliminating staging environments help me," the answer is obviously, "it can't."

thih9 4y ago

This comment feels needlessly defensive. I never said "I don't want to change anything", I gave reasons for rejecting changes.

jdlshore 4y ago
I overreacted. Let me try again. Your original question was, paraphrased, "how do we give non-tech product owners early access without a staging environment?" The canonical answer, from organizations that do this, is to use feature flags that are tied to user accounts. But this requires a certain level of engineering maturity—specifically, something that looks a lot like continuous deployment. There's a bunch of things that go along with continuous deployment, but one of them is continuous integration (the practice, not the poorly-named build servers), which is a combination of trunk-based development and frequent merges to the trunk. This requires programmers to hide incomplete work behind feature flags (or keystones¹). There's an associated set of practices for dealing with schema changes that I'd be happy to describe. People who are using feature flags (and associated practices) don't have "code that's not ready to merge." That's the whole point of the feature flags—to allow them to merge and deploy unfinished code. So when you put the constraint of "our code isn't ready to merge" on my "use feature flags" answer, I thought you weren't engaging in good faith, because it's kind of nonsensical—like saying risk of sunburn prevents you from using sunscreen lotion. I apologize for misconstruing. I assume what you really meant was, "We aren't able to use feature flags to merge and deploy incomplete code." That's a perfectly fine answer! But you asked how people share incomplete work when they don't have a staging environment, and the answer is, "feature flags."² Specifically, they deploy incomplete work to production and use feature flags to selectively hide and show it. If you can't do that, then it's probably best to keep your staging environment. ¹Keystones: https://martinfowler.com/bliki/KeystoneInterface.html https://martinfowler.com/bliki/KeystoneInterface.html ²For teams that use keystones, but not feature flags, pairing with stakeholders (screen sharing) is another approach I've seen used. It has the advantage of being simpler. But I agree that it's more constraining.