Hacker News Reader

Hacker News

Comment by ford | Hacker News Reader

Full thread

ford

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-scale

2) Ensuring integrations/environment-related issues don't happen when you deploy

3) Alpha/Beta groups of users

4) Quick reversions when something does not work as expected

Similar to other commenters I can't imagine not using feature flags. Some of these might have work-arounds like an artificial load tester, but nothing beats true production traffic & patterns.

View on HN

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.

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.

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.

4) Rollback plans - every change needs a rollback plan

Reply on news.ycombinator.com