feature-flagging

Feature Flagging

Feature flags let you ship code without enabling features for users. Use them for gradual rollouts, kill switches, and A/B tests. AI agents either (a) skip them entirely, or (b) flag every line of code — both wrong.

The opinion

Flipper for Rails feature flags. Flag launches (gradual rollouts, kill switches), not every line. Set a deprecation date when you add a flag — flags that live forever become technical debt. Read flags once per request via a wrapper that's mockable in tests. Admin UI for ops, but flag flips should ideally be in code (committed) for audit trail.

Counter-positions:

• LaunchDarkly / Statsig / GrowthBook — managed services with deeper analytics. Pay-per-flag-evaluation gets expensive. Flipper covers 80% for small/medium apps.
• rollout gem — older, less actively maintained. Flipper won.
• Conditional based on Rails.env.production? — anti-pattern. That's not a flag, that's a fork.

Core patterns

Pattern 1: Flipper setup

# Gemfile
gem "flipper"
gem "flipper-active_record"
gem "flipper-ui"  # admin UI (optional)

# bin/rails generate flipper:active_record
# bin/rails db:migrate

# config/initializers/flipper.rb
require "flipper/middleware/memoizer"

Rails.application.config.middleware.use Flipper::Middleware::Memoizer

# Optional: register groups
Flipper.register(:admins) { |actor| actor.respond_to?(:admin?) && actor.admin? }
Flipper.register(:beta_users) { |actor| actor.respond_to?(:beta?) && actor.beta? }

# config/routes.rb — mount admin UI
authenticate :user, ->(u) { u.admin? } do
  mount Flipper::UI.app(Flipper) => "/_flipper"
end

Pattern 2: Reading flags

# In a controller / view / model
if Flipper.enabled?(:new_dashboard, current_user)
  render :new_dashboard
else
  render :dashboard
end

current_user (or any actor with flipper_id) gets per-user flag state. Pass nil for global flags.

# Model needs flipper_id
class User < ApplicationRecord
  def flipper_id
    "User;#{id}"
  end
end