Best practices for Feature Gates

Statsig classifies the best practices for using feature gates into four categories: implementation, development, collaboration, and governance.

Implementation

1. Manage for ease and maintainability: Use simple if/else gate checks for short-lived gates that you can quickly clean up after the release. Use configuration parameters for longer-lived gates to avoid nesting multiple gates and growing complexity in your code over time.
2. Select the gating decision point: Implement client-side feature gates when most context is available at the client and when the feature is primarily developed in the presentation layer (for example, a user registration flow). Implement server-side feature gates when most context is available at the application server and when the feature is primarily related to backend system behavior (for example, a new cache layer). Localize gating decisions within the service whose behavior is being changed.
3. Focus on one feature: Using one feature gate to control multiple features at a time can be confusing and can make troubleshooting issues difficult. If multiple parts of a feature must work together, create a master feature gate to control child feature gates for those individual parts.

Development

1. Speed up development: Shipping new functionality behind a feature gate ensures the code path isn't activated until you're ready to integrate with your dependencies. This lets you ship service components faster without being blocked by dependencies.
2. Always be testing: Use feature gates to ensure that in-development features remain inactive in production while you continue to test new functionality in staging or pre-production environments.
3. Progressive delivery: Ship code for in-development features early and often. Shipping code as part of the main branch that can be deployed to production at any time avoids difficult merges of long-lived branches later.
4. Validate functionality with trusted users: Use feature gates to expose new functionality only to trusted users such as teammates, company employees, and beta customers before launching publicly. Verify that the new functionality works as expected.
5. Set up a phased canary release: Use feature gates to progressively expose new functionality to a small percentage of users, validate user experience, and monitor production system health before launching broadly. Recommended rollout strategy: 0% → 2% → 10% → 50% → 100%.
6. Validate user and system impact: Compare key user and system metrics against the default behavior. Common user metrics include daily and weekly active users, weekly retention, and conversion rates for key user actions. Common system metrics include error response rates, application crash rates, p50/p90/p99 request-response latency, and CPU utilization. Create a metric for any key behavior by logging the event that best represents it with Statsig.
7. Ramp up or roll back: Identify issues and negative user impact early. Use metric-based evidence to decide whether to release the feature more broadly. If you launch, ramp up progressively (for example, 10% → 50% → 100%).
8. Clean up after releases: After the release is complete, remove unnecessary gates from code. After gates are no longer checked, you can turn them off or delete them.

Collaboration

1. Scoped Access: Invite verified teammates to create, review, and approve feature gates for a specific project.
2. Role-based Access Control (RBAC): Ensure that only project members with the appropriate privileges can create and edit feature gate configurations.

Governance

1. Audit and record: Set up audit logs for any changes your team makes to feature gates.
2. Monitor and automate: Set up automated health monitoring and alerts to improve visibility of your feature gates, reduce response times for issues, and create automated workflows for common response patterns.