Yes, we wanna test something that is really in production. We implement it that it's behind very hidden url and regular path is blocked with feature flag then at launch date you just mark true to false and the working thing just also becomes available at main url
Ask HN: Does your team use feature flags?
141–143 of 143 posts
Re: Ask HN: Does your team use feature flags?
#142A different question - how do teams that don't use feature flags accomplish the things feature flags enable? Namely: 1) Validating you can handle production-scale 2) Ensuring integrations/environment-related issues don't happen when you deploy 3) Alpha/Beta groups of users 4) Quick reversions when something does not work as expected Similar to other commenters I can't imagine not using feature flags. Some of these mi…
It’s managed through Git workflow. At one place we had three branches: master, alpha and release. Master was in-progress features. By the time alpha was cut you were expected to be code complete because that was also the end of the sprint. Alpha then went to staging servers. Bug fixes would land in master and be cherry-picked in to alpha. Eventually alpha gets promoted to release. Emergency fixes are cherry picked di…
This is mad. So much overhead for little to nothing.
Even if you don't use feature flags, you should always be merging complete code. Master should be your release, and you should be deploying often. The small your release, the quicker you catch issues, and the easier it is to understand where those issues lie.
Re: Ask HN: Does your team use feature flags?
#143Earlier quoted context omitted.
I have found it can be good to 'remove' the flag at the same time you create it, but just don't merge the removal until later. I wrote up this idea in a blog post a while ago, if anyone finds it interesting: https://launchdarkly.com/blog/how-to-use-feature-flags-witho...
I've seen this used, but as PRs get added, these 'cleanup' PRs move to the bottom and are usually ignored by other team members. To me, it's about having enough time to do this in a sprint, and that means it really needs to be a post-launch Jira ticket. Which I've seen done maybe once.
yeah, this is definitely a risk. I agree that the PR needs to be tracked as a post-launch task.
The advantage to this approach is that you do the hard part of removing the flag (ie, thinking through all the parts of the code that need to be cleaned up) while everything is fresh in your mind. Otherwise, you end up spending more time regaining all of the context, and are more likely to leave some vestigial dead code because you aren't sure it isn't needed any more (this is probably less of a risk with languages that lend themselves well to static analysis that can identify dead code, but these tools are never perfect).