Feature Flags Lifecycles

Regular flag management prevents the accumulation of outdated, unused flags in your application. This guide shows a straightforward approach to determine when to archive and remove feature flags using Bucketeer.

When to archive a flag

In Bucketeer, flags display traffic status to help you identify which flags are actively being used:

• Never Used: Recently created flags that haven't received any request yet
• Receiving Traffic: Flags that have received requests within the last 7 days (shown with a green indicator)
• No Recent Traffic: Flags that haven't received requests for over 7 days (shown with a yellow warning indicator)

Both ON and OFF flags can show "No Recent Traffic" status.

Use the flag traffic status as a reference to archive flags and remove their code from your application. A flag showing "No Recent Traffic" signals it's no longer in use and can be safely archived.

Why archive flags?

Archiving flags with no recent traffic optimizes resource usage and improves user experience. Flags that continue being sent to clients increase:

• Server response size and client cache size
• Response latency

Flags with no recent traffic primarily affect the application startup process for new users or users without cached data.

Flag evaluation

Bucketeer does not reevaluate previously evaluated flags unless specific conditions are met:

• New user access
• Cache clearance by existing users
• Application with no activity for over 30 days

How to archive a flag

Follow these steps to archive flags showing "No Recent Traffic":

1. Remove the flag code from your application
2. Navigate to the Feature Flags list page
3. Archive the flag using one of these methods:

Option 1: From the flag list

• Click the flag's action menu (...) and select Archive Flag

Option 2: From the flag details page

• Open the flag details
• Navigate to the Settings tab
• Scroll to the Archive Flag section
• Click the Archive Flag button

For more details about the Settings tab, see Settings.

4. Provide a comment for the update, then click Submit

Archiving warning

Bucketeer will warn you if the flag has received at least one request in the last 7 days.

Remove flag code first

Archiving a flag that still exists in your code will make your application use the default value defined in your code:

• Server SDK: Returns a not-found error from the Bucketeer server, triggering default values in your application
• Client SDK: Variation not found in cache, triggering default values in your application

Always remove the flag code before archiving to avoid unintended behavior.

Flag lifecycle types

Feature flags are often used temporarily to reduce risks during feature releases. Once the rollout is complete, remove the flag from the code and archive it on the dashboard.

Flags fall into two main lifecycle categories:

Temporary Flags

Temporary flags are removed and archived after serving their purpose:

Feature rollouts

• Used to decouple feature deployment from release
• Once the feature is fully deployed and tested, remove the flag code and archive it

Experimentation

• Used for A/B testing and multivariate experiments
• After the experiment concludes and a winner is selected, remove the flag code and archive it

Permanent Flags

Permanent flags have longer lifecycles and serve ongoing needs throughout the application's lifetime:

Kill switches

• Enable or disable features or entire application sections
• Often used during deployments or service downtime
• Remain permanent for quick action in unexpected situations

Feature management flags

• Control feature availability based on user segments or attributes
• Manage platform features for specific user groups (e.g., premium vs free tier)
• Remain throughout the application's lifetime

Examples of permanent flag use cases

Mobile app version control

A common permanent flag scenario is prompting mobile users to update their app version. This is useful when releasing unfinished features or addressing frequent crashes.

By incorporating a permanent boolean flag in the app code, developers can control when the update prompt appears. Setting the flag to true triggers a pop-up requesting the app update.

Flag reuse for multiple tests

While not ideal, reusing flags for multiple tests can be practical for mobile apps. This approach:

• Avoids constantly asking users to update the app
• Bypasses slow app store review processes (Google Play, App Store)

Flag reuse is necessary because you can't control when users update their applications. Since you can't always rely on flags from the latest release, maintaining fixed flags enables common actions:

• Testing different algorithms
• Changing search algorithms
• Updating banner URLs in the application
• Toggling feature sets based on runtime conditions

Best practice

While permanent flags are sometimes necessary, aim to keep most flags temporary. Regularly audit permanent flags to ensure they're still needed and properly documented.