Adopting Feature Flag-Driven Releases

Re:Adopting Feature Flag-Driven Releases by jovanni on Wednesday August 03, 2016 @04:10PM (#12221093)

I work at a company that uses feature flags heavily for releases. Even most refactors are done behind a flag.

It works surprisingly well, especially when you have 20 developers all trying to release different features at the same time, you then have a controlled way to isolate enabling and monitoring each new feature one at a time.

It's generally expected that you clean up your flag conditions after things have been tested. And that you write code so removing the flag flow is trivial.

[ Parent | on HN ]

Re:Adopting Feature Flag-Driven Releases by avita1 on Wednesday August 03, 2016 @05:08PM (#12221531)

> Even most refactors are done behind a flag

How does this work without cloning vast swaths of code and saying:

    if (feature)
       loadModuleA();
    else:
       loadModuleB();

[ Parent | on HN ]

Re:Adopting Feature Flag-Driven Releases by jovanni on Wednesday August 03, 2016 @05:34PM (#12221714)

On occasion you do that. But usually it's just a couple if statements in a couple places with very little code duplicated.

Also, again, it's expected that after it's tested you delete the old path. It's a short lived transitional situation.

Sometimes it's annoying. Overall it's safer when you're on a massive scale.

[ Parent | on HN ]

Re:Adopting Feature Flag-Driven Releases by flukus on Wednesday August 03, 2016 @07:30PM (#12222313)

That would tie in cleanly with an IOC container.

[ Parent | on HN ]