4 ms·

>FWIW, I do like feature flags, but as a solution for a different problem: long-lived feature branches (forks) of the master But isn't this case what staging o

by mnsc 6y ago

>FWIW, I do like feature flags, but as a solution for a different problem: long-lived feature branches (forks) of the master But isn't this case what staging originally tried to solve? "this big feature isn't ready for production but we need to regression test in a setup as similar to production as possible" ?

necovek 6y ago
Not that I know: if you needed a "staging" for each of the feature branches, the complexity and cost grew, but problems remained (i.e. merging trunk and a branch back and forth). For the last 15 years I've been at teams using a "staging", it was simply a single production-like environment (well, my first project was exactly like production on slightly less beefy hardware with sanitized production DB import nightly) that gets the "trunk" (or "main") deployed to automatically (on my current team, it can be used to run non-production code as part of the deployment process which you bail out of). I am pretty sure there is no one true definition of staging, so it's a spectrum rather than an exact way to do things.
- mnsc 6y ago
  I'm talking about the prehistoric time before git and feature branches. Where all the developers hacked away for months on That New Feature and all code just went into trunk, cause that's where the development is. Back then staging was invaluable to get the confidence to do that (bi?)annual major release.
  - necovek 6y ago
    Sure, that's the time we learned why feature branches and not releasing often sucks :) And yes, you sometimes had "staging" track your trunk, when you would be missing a staging environment for production where you'd want to test critical fixes, so ultimately, you needed both then.
loopz 6y ago
Staging has always been about QA before deployment in production. For tools you buy, one might just end up forgoing staging where you know it must work. Though, what to do if an update bricks the system? For any non-trivial and complex software, you still end up with having at least one test-environment though. Feature flags is about multiple branching. Staging doesn't really give you that in full, just by hacking the environment. It's then that you end up with environments that don't properly reflect future production and start missing stuff. The author sounds like someone familiar with testing, that needs to learn about CI/CD. Sure, for trivial front end stuff, you can often get away with doing it in production. But without synchronization between environments, you end up in trouble and take on more risk, just for the luxury of treating your paying customers as beta-testers. It's a valid opinion depending on what one is working on, but I bet it doesn't apply for most outside unimportant side-projects.

by mnsc 6y ago

necovek 6y ago

Not that I know: if you needed a "staging" for each of the feature branches, the complexity and cost grew, but problems remained (i.e. merging trunk and a branch back and forth). For the last 15 years I've been at teams using a "staging", it was simply a single production-like environment (well, my first project was exactly like production on slightly less beefy hardware with sanitized production DB import nightly) that gets the "trunk" (or "main") deployed to automatically (on my current team, it can be used to run non-production code as part of the deployment process which you bail out of). I am pretty sure there is no one true definition of staging, so it's a spectrum rather than an exact way to do things.

mnsc 6y ago
I'm talking about the prehistoric time before git and feature branches. Where all the developers hacked away for months on That New Feature and all code just went into trunk, cause that's where the development is. Back then staging was invaluable to get the confidence to do that (bi?)annual major release.
- necovek 6y ago
  Sure, that's the time we learned why feature branches and not releasing often sucks :) And yes, you sometimes had "staging" track your trunk, when you would be missing a staging environment for production where you'd want to test critical fixes, so ultimately, you needed both then.

loopz 6y ago

Staging has always been about QA before deployment in production. For tools you buy, one might just end up forgoing staging where you know it must work. Though, what to do if an update bricks the system? For any non-trivial and complex software, you still end up with having at least one test-environment though. Feature flags is about multiple branching. Staging doesn't really give you that in full, just by hacking the environment. It's then that you end up with environments that don't properly reflect future production and start missing stuff. The author sounds like someone familiar with testing, that needs to learn about CI/CD. Sure, for trivial front end stuff, you can often get away with doing it in production. But without synchronization between environments, you end up in trouble and take on more risk, just for the luxury of treating your paying customers as beta-testers. It's a valid opinion depending on what one is working on, but I bet it doesn't apply for most outside unimportant side-projects.