Survey about Feature Flags
What’s this issue all about?
This issue's purpose is to get insight regarding User needs and behaviours for feature flags and an invitation for our users to participate in the survey on https://about.gitlab.com/community/gitlab-first-look/ \
Who is the target user of the feature?
- Users who are using feature flags (of any forma)
- Users who are using competitors (To name some: launchdarkly, rollout.io (clouudbees), split.io)
- User who want to use feature flags but haven't yet
What questions are you trying to answer?
Similar to #466 (comment 273600207)
- What should be the flow of creating/editing/archiving feature flags?
- What are the strategies that we need to support?
- Will users manage feature flags via the UI or only via API and markdown?
- What info do we need in a feature flag dashboard?
- Are users interested in an automatic disablement of feature flags (such as once it hits a certain percent)
- A/B testing - how popular is the demand for this?
- Who should gain permissions for toggling the feature flag?
- Connection between environments and feature flags
Core questions
As mentioned in gitlab#197708 (closed) (which is a public issue inviting users to participate)
- Are you currently using feature flags?
- yes
- no
- planning to
- Hoe long has your company be using feature flags?
- Under a year
- 1-5 years
- Over five years
- How are you currently using Feature Flags?
- Config file
- Database
- Database with context
- Feature management service
- What tools do you use them with?
- Closed source custom system maintained by the company
- Open source custom system maintained by the company
- GitLab
- Launch Darkly
- split.io
- rollout.io (cloudbees)
- VWO
- Optimizely
- Apptimize
- Firebase Remote Config
- Taplytics
- Bullet Train
- Other
- For what purpose(s) does your team use feature toggles? (Select All that apply)
- Support CI of partially-completed features
- Dark launches
- A/B testing
- Gradual rollout
- Other *Does your team make decision about using feature toggles for each feature?
- Yes. The team makes a decision if using a feature toggle is necessary for a new feature.
- No. The feature toggle is added for every new feature.
- Other.
- How often does your team do the following management practices?
- Using a maintenance tool (spreadsheet, etc) to manage data about feature toggles. (i.e. the owner of the toggle, the current value (on, off), the current status (to remove, keep) and the time of its creation).
- Logging changes to toggle values/configurations (e.g. who changes which toggle and when, etc.).
- Grouping toggles together in any way to simplify management or giving permissions (i.e. related toggles, other).
- Allowing all team members (i.e. Q&A team) to have access to feature toggles and can make changes.
- Always
- Mostly
- About half of the time
- Rarely
- Never
- How often does your team do the following initialization practices?
- Determining the type (permission toggle, ops toggle, release toggle, experiment toggle, short-lived toggle, long-lived toggle) of the toggle at design step.
- Using naming conventions for toggles (similar to variable and function naming conventions).
- Setting up a default value for toggle if toggle value is not found (i.e. toggle is off if its value is not found in the code).
- Always
- Mostly
- About half of the time
- Rarely
- Never
- How are the values of the toggles stored? (Check all that apply)
- Configuration files
- Databases
- Other.
- How are the values are assigned to the toggles in the system? (Check all that apply)
- Assigned boolean values (True, False)
- Assigned multivariate values (e.g. Red, Yellow, Blue)
- Assigned string values (e.g. ”disable_featue”, ”enabled_feature”)
- Other.
- How does a developer access the toggle value in the code? (Check all that apply)
- Value is accessed by checking a primitive data type (e.g.enableMyFeature == true)
- Value is accessed through an object representing a toggle (e.g. MyFeature.isActive())
- Value is accessed through a toggle manager/mapping from key to value (e.g. Dictionary)
- Other.
- How often does your team do the following clean-up practices?
- Limiting the number of existing toggles in the code.
- Build or test failing if a toggle is not deleted by a specified date (Time bomb).
- Automatic reminders near date to delete the toggle.
- Using tasks/stories/cards for removing toggles.
- Creating a clean-up branch for removing toggle points at the time of creation of the toggle.
- Tracking unused toggles for removal.
- Changing feature toggle to configuration setting to keep it in the code.
- Always,
- Mostly
- About half of the time
- Rarely
- Never
- On average, how long does a feature flag "live" in the code?
- A few days
- A few weeks
- A few months
- Forever
- We are looking for people to speak with us more about Feature Flags. If you would like to be contacted in the future, please provide your name and email.
Additional questions
- What’s your current role?
- How long have you been in that role?
- What kind of work does your company do?
- What do you use Gitlab for?
What hypotheses and/or assumptions do you have?
- Our new UX that we designed is the correct and easy way to work with feature flags.
- The basic features that we have currently scheduled are good enough to onboard users to use our Feature flags solution
- What features are needed as an MVC for A/B testing?
What decisions will you make based on the research findings?
- Feature Flag roadmap and allocation of development effort
What's the latest milestone that the research will still be useful to you?
Edited by Mike Nichols