Wednesday 18 July 2012

A brief look at some feature toggle tools


When using continuous integration branching is considered a no no. This being the case you need feature toggles. The concept is quite simple, but how do you actually use them in code? I've come across this tricky problem at work and with the help of some colleagues came up with a very simple approach. But what if you don't want to roll out your own? What's available? Here is a brief overview of three tools available based on a quick Google search. 

NFeature


Features
  • Custom feature states. E.g. Previewable will only be seen by users who meet certain criteria. Established means the feature toggle cannot be removed 
  • Custom feature availability functions. E.g. Make feature available on site load or presence of a cookie
  • Feature dependencies
  • Feature availability dates
  • Feature specific settings can be defined using JSON

Configuration
  • Toggles defined in enum and web.config
  • Availability checking methods set up
  • Manifest set up. The manifest service is used to check the state of existing toggles. This service must be injected into any class where toggles are required

Advantages
  • Large amount of control over when and how to flip toggles
  • Available via NuGet

Disadvantages
  • More configuration required that other feature toggling tools I looked at
  • No view examples provided. I'm unsure how NFeature would be used to add a toggle to a view
  • Potentially tricky to implement. This is probably just my fault, but I found it difficult to see how NFeature could be easily integrated with our existing code base
  • Manifest service must be injected into any class where toggles are required. On a big project this could affect a large number of classes


FeatureToggle


Features
  • Custom feature toggle types including always on, always off, enabled and after date
  • Supports XAML
  • Toggles can be loaded from the database
  • WPF and Windows phone 7 support
  • Custom feature toggle implementations can be created by implementing IFeatureToggle

Configuration
  • Toggles defined in appSettings
  • Each toggle must also be created as a new class which extends an existing feature toggle class. E.g. EnabledOnDatesFeatureToggle

Advantages
  • Supports multiple platforms
  • Multiple toggle types
  • No service class required so no IoC set up required
  • Incredibly simple to set up and use 
  • Toggle type and provider are extensible
  • Available on NuGet

Disadvantages
  • You have to create a class for each toggle
  • Toggles can't be used statically and must be instantiated as far as I could tell. This isn't a major issue to be fair, I'm just not a fan
  • Difficult to use across large solution. E.g. I would like to be able to define my toggles in a common project and use them in several web projects
  • Breaks existing unit tests. I'm unsure how to mock toggles when using FeatureToggle


FeatureSwitcher


Features
  • Can check features statically or with instance
  • Fluent interface
  • Multi tenancy support
  • Custom behaviours (to be honest after reading the documentation I was unsure what custom behaviours were)

Configuration
  • Toggles defined in custom configSection
  • Create a class which implements IFeature

Advantages
  • Can check features statically or with instance
  • Fluent interface looks very flexible and powerful
  • Multi tenancy support

Disadvantages
  • Personally, I found the documentation quite confusing. After reading the readme I still had a lot of unanswered questions about how to use the toggles and wasn't sure about how to configure FeatureSwitcher in my own projects

4 comments:

  1. Hi Phil!

    I'm the author of FeatureSwitcher.
    On the wiki page [https://github.com/mexx/FeatureSwitcher/wiki] I've elaborated my thoughts about the API design.

    In short, what you've stated as disadvantage, the need of a class for each feature, was the reason to create the library. I wanted to have the possibility to use IDE's find usages to be able to easily find all the code affected by the feature or if I want to remove the toggle, I utilize the compiler to show me all the places to review, after the feature class is marked obsolete or deleted.

    With behaviours you can write your own logic which determines the state of the feature (on or off), for example by querying a database.

    About confusing documentation, I encourage you to elaborate on it as an issue or maybe a pull request.

    I'll appreciate any feedback.
    Best regards

    ReplyDelete
    Replies
    1. Hi Max!

      Thanks for your comments.

      I think I was initially concerned that creating a class for each toggle would result in adding more code that was necessary to a project, but in hindsight this was unfounded, so I'll remove that point.

      With regards to the documentation the main difficulty I had was that after reading the "how to use it" and following sections I still felt I had unanswered questions. For example how do I set the status of a toggle? Can it be read from a database? If so how do I do that? What is a behaviour? How to I configure one? How do I configure a naming strategy? Are there any examples?

      A bit more information would be really helpful. In particular a tutorial which takes people through a pretend scenario would be really useful, so people can see how to implement a toggle end to end. Or perhaps include a few sample projects where the toggles are used in different ways. Also having a link to any example code in the readme would be handy.

      Hope that helps.

      Delete
    2. Hi Phil!

      Thanks for the feedback, I'll try to incorporate it.

      I included some information about what naming convention and behavior are for. Hope this brings more light into this dark hole of feature switcher configuration :)

      Delete
  2. Adding: https://github.com/timscott/flipit

    ReplyDelete