Imagine you're running a busy bakery. You've come up with a daring new sourdough recipe that you're convinced is better than the original. Now, you could swap the recipe for every single loaf you sell starting tomorrow morning, but that's a huge gamble. If the new recipe doesn't set right or customers hate the taste, you've just ruined your entire morning's revenue and potentially your reputation.

Instead, you do a "soft launch." You bake five loaves of the new sourdough and give them to your five most loyal regulars. If they love it, you bake twenty the next day. Then fifty. By the time you roll it out to every customer, you've already caught the fact that the new recipe needs ten more minutes in the oven, and you've fixed it without the general public ever knowing there was a problem.

In Ruby, gradual rollouts—often implemented via feature flags or "canary releases"—work exactly the same way. Instead of a "Big Bang" release where you merge a massive feature and hope for the best, you wrap the new logic in a conditional gate. You control who sees the new code without redeploying the application.

The Risk of the Big Bang

I've seen too many engineers treat a deployment like a leap of faith. You merge the PR, run the migration, and hit "Deploy." If there's a memory leak in your new logic that only triggers under heavy load, you won't find it until your entire site is down and your Slack is exploding with alerts. Gradual rollouts turn that leap of faith into a controlled walk. By limiting the blast radius, you can monitor your error rates and performance metrics for a tiny subset of users before committing everyone to the new path.

Building a Simple Feature Gate

While there are heavy-duty gems like flipper that handle this, it's important to understand the pattern. At its core, a gradual rollout is just a conditional check that looks at the current user's identity.

class FeatureGate
  # In a real app, these would likely be stored in Redis or a DB
  @flags = {
    new_pricing_engine: { enabled: true, percentage: 10 }
  }

  def self.enabled?(feature, user)
    config = @flags[feature]
    return false unless config&.[](:enabled)

    # Use the user's ID to create a consistent experience.
    # We don't want the feature flickering on and off for the same user.
    (user.id % 100) < config[:percentage]
  end
end

Notice the user.id % 100 trick. I use this constantly. By modulo-ing the user ID, we ensure that a user who falls into the 10% bucket stays there. If you used rand(100), the user would see the new feature on one page refresh and the old one on the next, which is a great way to confuse your customers and make your debugging a nightmare.

Integrating the Rollout into Your Logic

Once the gate is built, you use it to bridge the gap between your legacy code and your new implementation. Let's say we're upgrading a pricing calculator for an e-commerce site.

class OrderProcessor
  def calculate_total(order, user)
    if FeatureGate.enabled?(:new_pricing_engine, user)
      # The fancy new logic we're testing
      NewPricingEngine.calculate(order)
    else
      # The battle-tested legacy logic
      LegacyPricingEngine.calculate(order)
    end
  end
end

Now, the rollout process looks like this:

• Internal Testing: Set the percentage to 0, but hardcode your own user ID to always return true.
• The Canary: Set the percentage to 1%. Watch your logs. Are there more 500 errors for those users? Is the database CPU spiking?
• The Ramp: Move to 10%, then 25%, then 50%.
• The Cleanup: Once you hit 100% and are confident, delete the if/else block and the FeatureGate entry. This is the part everyone forgets, and it's how "temporary" flags end up staying in codebases for five years.

📋 Practical Task

Implementing a Canary Rollout for a Tax Calculation Service

You are tasked with replacing a legacy SimpleTaxCalculator with a new GlobalTaxCalculator that handles international VAT. Because this affects payments, you cannot risk a full rollout.

Your Task: Implement a RolloutManager class and update the CheckoutService to gradually roll out the new calculator.

Requirements:

1. Create a RolloutManager that has a method enabled?(feature_name, user).
2. The RolloutManager should store a hash of features and their rollout percentages (e.g., { global_tax: 20 }).
3. Ensure that the rollout is deterministic—the same user must always get the same experience based on their user_id.
4. Update the CheckoutService#apply_tax method to use the RolloutManager to decide whether to use SimpleTaxCalculator.calculate(amount) or GlobalTaxCalculator.calculate(amount).

Starter Code:

class User
  attr_reader :id
  def initialize(id); @id = id; end
end

class SimpleTaxCalculator
  def self.calculate(amount); amount * 0.05; end
end

class GlobalTaxCalculator
  def self.calculate(amount); amount * 0.15; end
end

class CheckoutService
  def apply_tax(amount, user)
    # YOUR CODE HERE
  end
end