3 ms·

A different question - how do teams that don't use feature flags accomplish the things feature flags enable? Namely: 1) Validating you can handle production-sc

• jdavis703 5y ago
  It’s managed through Git workflow. At one place we had three branches: master, alpha and release. Master was in-progress features. By the time alpha was cut you were expected to be code complete because that was also the end of the sprint. Alpha then went to staging servers. Bug fixes would land in master and be cherry-picked in to alpha. Eventually alpha gets promoted to release. Emergency fixes are cherry picked directly to release. It’s clunky and stressful, but that’s we did it at one startup I worked about 10 years ago. Everywhere uses flags.
  • mkdirp 5y ago
    This is mad. So much overhead for little to nothing. Even if you don't use feature flags, you should always be merging complete code. Master should be your release, and you should be deploying often. The small your release, the quicker you catch issues, and the easier it is to understand where those issues lie.
• willcipriano 5y ago
  I like the idea of feature flags and implement that pattern into my code from time to time, however I've never worked on a team that uses them. This is how they do it instead: > 1) Validating you can handle production-scale I've never seen anyone actually do this. Lots of people expect AWS to handle the heavy lifting here. > 2) Ensuring integrations/environment-related issues don't happen when you deploy Deployment to the test or staging env. > 3) Alpha/Beta groups of users Most often some sort of user permission system. Sometimes they run two nodes and have both run different versions of the software. > 4) Quick reversions when something does not work as expected A deployment. How long that takes depends on how the software is architected, but 5 - 10 minutes isn't uncommon.
• Graffur 5y ago
  4) Rollback plans - every change needs a rollback plan