3 ms·
This makes sense, thanks for this set of ideas. Have you implemented this, or seen write-ups of this pattern described at length? Or perhaps commercial product
by bredren 5y ago
This makes sense, thanks for this set of ideas.
Have you implemented this, or seen write-ups of this pattern described at length? Or perhaps commercial products providing for this scenario?
Curious about prior art on this subject.
- dpark 5y agoMy team has basically implemented this twice, for two different products. One (product A) does individual integrations from the production feature flag system to the repo when the flag is at 100% in production. It’s quite successful. The other (product B) does bulk integration every few hours from production to the repo, bringing all flags at once. It enables flags that have been “approved” (as opposed to fully enabled in production). It’s less successful because of the bulk behavior, which makes it more difficult to isolate breaks. Both of these integrations go through the same validation gates as pull requests (they are actually implemented as pull requests). This ensures that flag changes through this system cannot break pull requests. The ideal system for protecting pull requests (or whatever other validation) is to require validation to pass before the flag can be enabled in production. I have not implemented this as a hard gate, but I do have an “fyi” validation run as post of the flag enabling for product A so engineers see if they’ve broken something before they start turning on the flag. Getting philosophical, I strongly believe that feature flags should not be enabled by default in the validation environment until they are fully enabled (or close to fully enabled) in production. This ensures that the base state (flag off) is validated. You always want it to be safe to turn off the flag, which means you want validation running with the flag off. Product B does not have this behavior for legacy reasons but I think it’s a poor technical decision.