4 ms·

Best staging is live. I knew when I saw this title that Charity Majors would be mentioned somewhere. Practically, having no staging is such a hard concept for

Best staging is live. I knew when I saw this title that Charity Majors would be mentioned somewhere. Practically, having no staging is such a hard concept for people to get their heads around. It’s one more safety net gone, but it’s a good one. Maturity of the business, team and product play a big part in this decision.

placatedmayhem 4y ago
I agree. I find canary or blue/green deployments paired with good rollback plans to be more valuable than a staging environment, yet I see them utilized less. I'm not sure why, though.
- yamtaddle 4y ago
  Tougher to set up, maintain, and reason about.
LordHeini 4y ago
Not for everyone. We develop software for others and most of our customers have staging access. So they can see development happening, can check or approve changes or can see if the api change they made breaks anything. They are usually very happy about this and keeps away tons of problems in prod.
- deleted 4y ago
  [deleted]
thih9 4y ago
I like deploying proof of concept branches to a staging environment and giving non-tech product owners early access, so that we could confirm that we're on the right track, even before a PR is ready. What would be the best way of approaching that without staging?
- jdlshore 4y ago
  Feature flags tied to user accounts. Alternatively (since you said “prior to pull request”) local builds, screen sharing, and live conversations with stakeholders. Alternatively (if you don’t want to screen share) continuous deployment, feature flags, and a PR-free review technique such as pairing or mobbing. Alternatively (if you don’t want pairing or mobbing) continuous deployment, feature flags, robust automated tests, and post-deployment code review.
  - thih9 4y ago
    That would require deploying the code to production. But at this stage the code is not ready for a PR/merge yet; e.g. it introduces a problematic dependency, requires a complex schema change, or similar. Edit: Parent comment has been edited, originally it was just "Feature flags tied to user accounts." To address the rest: screen recording is sadly not always enough; screen sharing, pairing and mobbing are not ideal either, the stakeholders want to spend more time with the feature than I'm willing to spend on a call.
    - jdlshore 4y ago
      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.

placatedmayhem 4y ago

I agree. I find canary or blue/green deployments paired with good rollback plans to be more valuable than a staging environment, yet I see them utilized less. I'm not sure why, though.

yamtaddle 4y ago
Tougher to set up, maintain, and reason about.

LordHeini 4y ago

Not for everyone. We develop software for others and most of our customers have staging access. So they can see development happening, can check or approve changes or can see if the api change they made breaks anything. They are usually very happy about this and keeps away tons of problems in prod.

deleted 4y ago
[deleted]

thih9 4y ago

I like deploying proof of concept branches to a staging environment and giving non-tech product owners early access, so that we could confirm that we're on the right track, even before a PR is ready. What would be the best way of approaching that without staging?

jdlshore 4y ago
Feature flags tied to user accounts. Alternatively (since you said “prior to pull request”) local builds, screen sharing, and live conversations with stakeholders. Alternatively (if you don’t want to screen share) continuous deployment, feature flags, and a PR-free review technique such as pairing or mobbing. Alternatively (if you don’t want pairing or mobbing) continuous deployment, feature flags, robust automated tests, and post-deployment code review.
- thih9 4y ago
  That would require deploying the code to production. But at this stage the code is not ready for a PR/merge yet; e.g. it introduces a problematic dependency, requires a complex schema change, or similar. Edit: Parent comment has been edited, originally it was just "Feature flags tied to user accounts." To address the rest: screen recording is sadly not always enough; screen sharing, pairing and mobbing are not ideal either, the stakeholders want to spend more time with the feature than I'm willing to spend on a call.
  - jdlshore 4y ago
    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.