Comment by alaithea | Hacker News Reader

Comment by alaithea | Hacker News Reader

It's funny that this is just becoming a thing. I heard about flag-driven releases from somebody in DevOps at Facebook last year, and how integral they were to their release process there.

I ran my own SaaS as a self-taught, solo developer from about 2002-2008, and I used to insert feature flags all the time to test stuff out. Later, when I joined the corporate world and learned more industry standard best practices, I assumed feature flags were just another bad practice I needed to leave behind with my old PHP project. But come to think of it, it was very convenient to:

- test things on a small scale live,

- preview features with the biz folks,

- and it was almost always very smooth to remove the flag and make a feature live, because it was already part of the program's overall control flow.

Funny the things you come upon out of ignorance, versus the drive to do things some way because that's the way everybody does them, and the good/innovative ideas that may fall through the cracks in the rush from the former to the latter.

Right. Feature flags are nothing new. Have them been using myself since forever.

The use of them in CD, in A/B, blue /green, or gradual rollout scenarios is very convenient though, that probably explains the popularity.

I work at a big EDA corporation, and we make good use of feature flags in our product. Typically, any new feature that needs extra testing than usual will be included behind a gate for one or two major releases before being enabled by default. Then, certain customers who work closely with our support staff will be given "access" to the flag (typically, a beta license is needed before the flag can be enabled -- in some cases, the presence of a valid beta license will even enable new features automatically sans flag). This makes it very easy to roll out beta code: since it's included in the release, every customer already has the code, and beta testers just need to be told about a flag and/or given a beta license. We don't ever need to prepare a special beta release or anything like that.

There are other cases where feature flags come in handy, too. For example, sometimes our default behavior does not match our competitor's. For many customers, that's totally fine, it either doesn't matter or they just deal with it. Some customers, however, demand that they get the same behavior as the competitor's product for certain functionality. We can implement a feature that toggles a compatibility mode and stick it behind a flag. These are flags that will typically never be enabled by default, but they make some of our customers very happy. For certain strategic reasons, we obviously prefer that customers just get used to our behavior. (Not to mention that, from a purely technical standpoint, our behavior often makes much more sense anyway. But it's sorta like C: Rust might be technically superior, but C is so entrenched that it's not going to get replaced overnight.)

I think I came from an opposite boat than you did, because this is the first company I've worked for that made extensive use of feature flags. Rather than assuming it was some bad practice, I was actually delighted by just how convenient they make certain things. And the best part is that they don't seem to really have any drawbacks.

I dabbled with feature flags once. We had... issues.. with our DBAs who, it seemed, couldn't make any changes to a database without taking it offline for a cold backup first. We floated the idea of feature flags as one way to perform certain live deployments. The ops guys refused outright for reasons which stank of protectionism at the time.

Time passed. I was tasked with rewriting a fairly complex piece of code and I put the new code behind a feature flag. At the time, there was no facility in place to support feature flags so I had to introduce one as part of the deployment. It all went into a test environment but the deployment scripts didn't set the config to enable it. This was deliberate because I wanted to verify that we wouldn't change existing behaviour (i.e. break anything) by deploying with the flag disabled. The testers, however, were looking for the new functional behaviour and raised a defect.

- when the project manager found out, he claimed that this was responsible for a timescale slippage (the delivery into test was massively late, naturally)

- when my line manager found out, he told me I'd be fired if I tried a "stunt" like that again

- when the DBAs found out, they decreed that, henceforth, all database updates which resulted in a "functional change" would be subject to the full release process (i.e. cold backups).

So the experiment was a total failure. Or a total success. It depends on how you look at it; one amusing moment was when the PM came out of a meeting and, with some gravitas, suggested that we might have to rip out half the new code in an effort to salvage the timescales. When I demonstrated that we could achieve that in, oh, about 5 seconds by flipping the flag, the notion went away. The guy was a contractor and I suspected he was just trying to create more work to keep himself around.

To me, the biggest question with feature flags is managing the removal of dead code. In this case, it was never removed because the task of deleting it would trigger a full project release cycle and the company didn't see the point of spending the money.

We used feature flags to update "live" code but using if conditions based on hard coded test user/client ids. I wrote everything necessary to respect a database flag instead but that never made it out of a test db whilst features kept being added behind "id" based flags.

So now to remove said flags you just hunt through code for the special id string and remove the "no" branches. Oh, and for Gods sake don't accidentally make the wrong thing live.

Flawless.

We used feature flags a lot a few years ago when I worked for ehow/demand media. I don;t really remember what exactly they controlled but there was quite a number of them.

Reply on news.ycombinator.com