11–20 of 104 posts
Earlier quoted context omitted.
I think the idea is that it's a separate flags repo?
Can you say more? I think i'm missing the point, in my mind that would make it even worse because you have all the problems I mentioned + merge conflicts being a possibility
If it's something controlled by the PR why is it even a feature flag? Seems like you lose a huge chunk of the benefit and might as well just change the code at that point. This to me seems like the wrong place to be controlling them, i certainly don't want to have to make a PR and merge it when a site issue is happening. Open to missing something though, curious what others experience has been
Flag changes can be pushed directly to the main branch with the correct repo permissions. When using the GitHub UI this involves just a little bit of typing and a few clicks.
>might as well just change the code at that point
If changing the code, running tests, building, and deploying is quicker and less risky then yes that makes more sense.
If it's something controlled by the PR why is it even a feature flag? Seems like you lose a huge chunk of the benefit and might as well just change the code at that point. This to me seems like the wrong place to be controlling them, i certainly don't want to have to make a PR and merge it when a site issue is happening. Open to missing something though, curious what others experience has been
I think the idea is that it's a separate flags repo?
Earlier quoted context omitted.
I have mostly seen developers in charge of changing flags, but there is also great value in empowering other roles to change flags (One example: sales people can unlock features as they sell them). Thankfully GitHub has an easy web-based Pull Request process. It's not as simple as a custom UI, but could be used by non-engineers to change flags.
> sales people can unlock features as they sell them That's a licensing thing, not a feature flag.
If you’re looking for an open source feature flag option, also check out https://www.growthbook.io/
Earlier quoted context omitted.
I think the idea is that it's a separate flags repo?
Can you say more? I think i'm missing the point, in my mind that would make it even worse because you have all the problems I mentioned + merge conflicts being a possibility
So instead of controlling flags from a website, you get the benefits of git merge, PR's, reviews, documentation etc without having to rebuild it.
I like the concept since it brings accountability. But it's just a need that larger orgs have, but by that point have likely internally built a flag system and so transitioning is difficult.
Earlier quoted context omitted.
I have mostly seen developers in charge of changing flags, but there is also great value in empowering other roles to change flags (One example: sales people can unlock features as they sell them). Thankfully GitHub has an easy web-based Pull Request process. It's not as simple as a custom UI, but could be used by non-engineers to change flags.
> sales people can unlock features as they sell them That's a licensing thing, not a feature flag.
But there's also a surprisingly common situation with big customers who want to limit and control certain UI updates so they can ensure that employees are trained appropriately.
Earlier quoted context omitted.
Can you say more? I think i'm missing the point, in my mind that would make it even worse because you have all the problems I mentioned + merge conflicts being a possibility
One repo is actual flags control-like-database. So instead of controlling flags from a website, you get the benefits of git merge, PR's, reviews, documentation etc without having to rebuild it. I like the concept since it brings accountability. But it's just a need that larger orgs have, but by that point have likely internally built a flag system and so transitioning is difficult.
If it's something controlled by the PR why is it even a feature flag? Seems like you lose a huge chunk of the benefit and might as well just change the code at that point. This to me seems like the wrong place to be controlling them, i certainly don't want to have to make a PR and merge it when a site issue is happening. Open to missing something though, curious what others experience has been
> I'm about to do this thing to mitigate the issue, does it look like the right thing?
It doesn't need to be a code change, can just be a flags change, but if it's a change at all then why not pin it to a commit so that rolling it back is easy and so that the commit sha can be an indicator of which flags are where.
Earlier quoted context omitted.
I have mostly seen developers in charge of changing flags, but there is also great value in empowering other roles to change flags (One example: sales people can unlock features as they sell them). Thankfully GitHub has an easy web-based Pull Request process. It's not as simple as a custom UI, but could be used by non-engineers to change flags.
> sales people can unlock features as they sell them That's a licensing thing, not a feature flag.
But it's all the same code under the covers. The functionality of what is enabled encoded into a license key - that's the same type of functionality as "does this deployment allow people to sign up by email" or "has this deployment enabled the super secret power user test functionality?"
But that's all under "if dataSource.toggle then {something}"