4 ms·

Extensively. Nearly every single change to the codebase is flagged. Even switching copy is behind a flag sometimes if the copy is across multiple places. I find

Extensively. Nearly every single change to the codebase is flagged. Even switching copy is behind a flag sometimes if the copy is across multiple places. I find it excessive and irritating; it feels like cargo cult programming to me.

deminature 5y ago
It's risk mitigation. Feature flagging everything is a pointless waste of time until suddenly you have to roll something back in production and it's not feature flagged. The value of feature flags increases with the greater the cost of a mistake making it to production. For iOS builds particularly, that might have a 1-2 day review delay before you can get a new build approved, they're invaluable.
- symlinkk 5y ago
  For iOS maybe, but for websites couldn’t you just revert the commit?
  - pfarrell 5y ago
    There are other uses if your flagging system is not "all or nothing". They can be very useful if they support directing a subset of users, customers, or traffic to new code/infra. The bigger a team gets, the more value you get from this. In fact, FF like this can be used for A/B testing too.
  - aerovistae 5y ago
    Exactly.
  - kevindong 5y ago
    For websites, the value is that feature flags should be much faster than the revert/deploy cycle. At $PRIOR_JOB, a revert/deploy or rollback takes tens of minutes of the main application.
  - ubertaco 5y ago
    Depends on how long the time is between commit and live-in-production, and on how severe the impact is. And also on the number of developers committing changes to the same codebase/app. If it takes you >20 minutes from when you commit to when it's live in production, and an incident arises due to the change where data loss/corruption increases in "blast radius" more by having the breakage in production longer, then a feature flag might be a great way to give you an immediate "kill it" switch. One possible alternative that could give an immediate "kill it" switch is to deploy the last-known-good build, but that only works IF other non-revertable changes haven't shipped since your change (like non-reversible schema migrations), and also IF your time-to-deploy-existing-build is sufficiently fast (it's pretty rare that you actually have instant deploys in live production apps). If you're in the situation where you have multiple developers committing unrelated changes to the same codebase, and non-reversible changes are a possibility, and your CI/deployment time is sufficiently-long (>5minutes, maybe?), then yeah, feature flags are probably a better fit than "just revert the commit". For one-man projects with a slow rate of change and a fast CI/CD pipeline, sure, feature flags are overkill.
  - karpierz 5y ago
    Sure, though if your back-end has multiple services this becomes harder. If your back-end uses more than one server, then you can run into issues. Feature flags also let you do partial rollouts, where you release to 0.1% of users and see if stuff breaks. Or A/B test to see if your feature improves whatever its meant to improve. It also lets you roll out the feature selectively to certain users if it's a breaking changes and each user needs time to migrate.
  - xcambar 5y ago
    That is a simplistic answer. In a CD setup without feature flash, commit equals deploy equals launch. With feature flags, commit equals deploy. Launch is controlled by feature flags. For a more mundane analogy, would you rather have a stove that allows cold or burning only, or one with every possible nuance of warm in between?

deminature 5y ago

It's risk mitigation. Feature flagging everything is a pointless waste of time until suddenly you have to roll something back in production and it's not feature flagged. The value of feature flags increases with the greater the cost of a mistake making it to production. For iOS builds particularly, that might have a 1-2 day review delay before you can get a new build approved, they're invaluable.

symlinkk 5y ago
For iOS maybe, but for websites couldn’t you just revert the commit?
- pfarrell 5y ago
  There are other uses if your flagging system is not "all or nothing". They can be very useful if they support directing a subset of users, customers, or traffic to new code/infra. The bigger a team gets, the more value you get from this. In fact, FF like this can be used for A/B testing too.
- aerovistae 5y ago
  Exactly.
- kevindong 5y ago
  For websites, the value is that feature flags should be much faster than the revert/deploy cycle. At $PRIOR_JOB, a revert/deploy or rollback takes tens of minutes of the main application.
- ubertaco 5y ago
  Depends on how long the time is between commit and live-in-production, and on how severe the impact is. And also on the number of developers committing changes to the same codebase/app. If it takes you >20 minutes from when you commit to when it's live in production, and an incident arises due to the change where data loss/corruption increases in "blast radius" more by having the breakage in production longer, then a feature flag might be a great way to give you an immediate "kill it" switch. One possible alternative that could give an immediate "kill it" switch is to deploy the last-known-good build, but that only works IF other non-revertable changes haven't shipped since your change (like non-reversible schema migrations), and also IF your time-to-deploy-existing-build is sufficiently fast (it's pretty rare that you actually have instant deploys in live production apps). If you're in the situation where you have multiple developers committing unrelated changes to the same codebase, and non-reversible changes are a possibility, and your CI/deployment time is sufficiently-long (>5minutes, maybe?), then yeah, feature flags are probably a better fit than "just revert the commit". For one-man projects with a slow rate of change and a fast CI/CD pipeline, sure, feature flags are overkill.
- karpierz 5y ago
  Sure, though if your back-end has multiple services this becomes harder. If your back-end uses more than one server, then you can run into issues. Feature flags also let you do partial rollouts, where you release to 0.1% of users and see if stuff breaks. Or A/B test to see if your feature improves whatever its meant to improve. It also lets you roll out the feature selectively to certain users if it's a breaking changes and each user needs time to migrate.
- xcambar 5y ago
  That is a simplistic answer. In a CD setup without feature flash, commit equals deploy equals launch. With feature flags, commit equals deploy. Launch is controlled by feature flags. For a more mundane analogy, would you rather have a stove that allows cold or burning only, or one with every possible nuance of warm in between?