Already using LaunchDarkly or Flagsmith? Here's how to tr...

Thinking about trying FtrIO? The new CLI makes it easy to start with just one feature flag

If you've been curious about FtrIO (the .NET feature toggle library that replaces if (featureFlags.IsEnabled(...)) with a [Toggle] attribute woven directly into your compiled IL) but weren't sure where to start, the experimental release of FtrIO.onetwo just made that first step a lot smaller.

You don't need to commit to a full migration. You don't need to rip out your existing flag library. You just need one method and 20 minutes.

What FtrIO.onetwo does

FtrIO.onetwo is a .NET CLI audit tool. Its default mode scans your source tree, finds every FtrIO toggle reference, and tells you exactly what's live right now:

dotnet tool install --global FtrIO.onetwo --version 1.1.1-experimental
ftrio.onetwo --source C:\Projects\MyApp

But in this experimental release it does two new things:

ftrio.onetwo import: pulls your current flag state from LaunchDarkly, Flagsmith, flagd, environment variables, or an HTTP endpoint directly into appsettings.json. Your existing flag library keeps working unchanged.

ftrio.onetwo migrate: scans your .cs files for LaunchDarkly or Flagsmith SDK call patterns using Roslyn, cross-references them against your live flag state, and generates a report showing exactly what each flag would look like in FtrIO and how to migrate it.

The "try it on one flag" workflow

The migrate report categorises every flag it finds:

✅ Ready to migrate: boolean flag, no targeting rules, straightforward [Toggle] replacement
⚠️ Needs review: targeting rules, number flags, needs a decision
❌ Cannot migrate: JSON flags, recommend moving to IConfiguration

For every ready flag it shows the suggested refactor. Something like:

new-checkout-flow → NewCheckoutFlow
File: Services\OrderService.cs:42

Current code:
  if (client.BoolVariation("new-checkout-flow", user, false))
  {
      ValidateCart();
      ApplyDiscounts();
      ProcessPayment();
  }

Suggested action:
  Extract the if block into a parent method named NewCheckoutFlow,
  then decorate it with [Toggle]. The inner methods remain unchanged.

  [Toggle]
  public void NewCheckoutFlow()
  {
      ValidateCart();
      ApplyDiscounts();
      ProcessPayment();
  }

  Add to appsettings.json:
  "NewCheckoutFlow": false

Pick one of those ready flags. Do the refactor. Run the app. That's it: you've got FtrIO running in your codebase alongside your existing flag library, on exactly one feature, with everything else completely unchanged.

If you like how it feels, pick another. If you don't, remove the [Toggle] attribute and you're back to where you started.

Why the parent method suggestion matters

The report nudges toward a pattern that's worth calling out explicitly: one named parent method per toggled feature.

Instead of this:

if (client.BoolVariation("send-welcome-email", user, false))
{
    ValidateEmailAddress(user.Email);
    BuildEmailTemplate(user);
    SendViaSmtp(user.Email);
    LogEmailSent(user.Id);
}

FtrIO works best like this:

[Toggle]
public void SendWelcomeEmail()
{
    ValidateEmailAddress(_user.Email);
    BuildEmailTemplate(_user);
    SendViaSmtp(_user.Email);
    LogEmailSent(_user.Id);
}

The feature has a single, named, discoverable entry point. The toggle is a gate on the feature, not scattered through its implementation. The inner methods have no idea a toggle exists. This is better code regardless of FtrIO; the migration report teaches the pattern rather than just doing a mechanical find-and-replace.

Running the migration report

# With live flag state from LaunchDarkly
ftrio.onetwo migrate \
  --from launchdarkly \
  --api-key sdk-xxx \
  --project my-project \
  --env production \
  --source C:\Projects\MyApp \
  --markdown plan.md

# Code scan only, no API key needed
ftrio.onetwo migrate \
  --from launchdarkly \
  --source C:\Projects\MyApp

The --api-key is optional; without it the report still finds all your call sites and shows the suggested refactors, just with placeholder values in the appsettings.json snippets instead of live flag states.

This is experimental

Both import and migrate are in an experimental branch. To try it you need to explicitly request the experimental version — the default install will give you the stable release which doesn't include these commands yet:

dotnet tool install --global FtrIO.onetwo --version 1.1.1-experimental

Functional but not yet on a stable release. Feedback is genuinely welcome, especially on the migration report format and the flag mapping logic.

The full FtrIO ecosystem:

FtrIO: the core library: dotnet add package FtrIO
FtrIO.Toaster: self-hosted Docker UI for managing toggles live
FtrIO.onetwo: this CLI: dotnet tool install -g FtrIO.onetwo
Docs: ftronoff.github.io/FtrIO
GitHub: github.com/FtrOnOff

If you try it on a flag or two I'd love to hear how it goes; drop a comment or open an issue.

推荐订阅源

DEV Community