Flaggrocrag

A git aware, environment-sensitive, human readable Feature Toggle system.

The Rent the Runway philosophy of feature flagging is:

• Feature Toggles (or Flags, I use both terms freely) are more than mere configuration. They should be treated as code unto itself, because
  • they should be subject to the same test and build cycles as other pieces of code.
  • they are in the critical path to application deployment.
  • they encapsulate data that is subject to business logic.
  • we want to see the history of changes to feature flags over time.
• Flags are time-sensitive. Flags should not live forever, they should expire, and flag expiry breaks builds.
• Flag authorship is important. It should be clear who flipped a flag, since that action exposes a new code path.
• The flag interface should be language and skill agnostic. Developers and their code are not the only end-users for feature flags. At RTR we:
  • have a web UI that's usable by non-programmers to flip flags and read current information.
  • have a CI job that is triggered by an action from the web UI to commit a JSON representation of the flags to a git repository.
  • have a web service responsible for serving the flag JSON to our applications.
  • cache in-memory representations of flags to a central store.

This philosophy is sound, but RTR's current Feature Flag implementation is untenable. The Flag JSON schema is overloaded with environment-specific configuration. Expiry is routinely ignored by way of just extending the flag lease-time to a date in the far future. Jenkins jobs should not be the sole mechanism to make updates to the system. Flaggrocrag is a rethinking of the RTR feature toggle philosphy from first principles, paying special attention to the benefits of the flags-as-code approach.

Git Aware

Flaggrocrag is git aware. That is to say, it leverages the features of Git (and GitHub) to specify toggle behavior. Any GitHub Flavored Markdown document (including this README) is a "valid" flag specification. Flaggocrag relies on GFM's Task list feature to denote toggles:

• disabled-feature-1
• coolest-feature
• cooler-than-being-cool-feature

This provides an implementation that's optimized for human readability, is machine-readable by any GFM library, and provides a nice UI in GitHub. By representing flags in this way, authorship information is encapsulated in the git commits. Instead of a notion of flag expiry, the git history provides us with last modified information. Creating and modifying flags are git commits, and reading flags becomes identifying task list markdown in a git blame. This also grants us the benefit of adding prose explaining context for a flag.

Building and Serving

Building and verifying the flags means parsing out the Task Lists from a particular markdown file, and looking at the git blame for these particular hunks.

• A flag expires 90 days after the last-modified date of a hunk.
• An expired flag represents a build failure.
• 2 weeks before a flag expires, the build process warns about the upcoming expiry.

Serving flags means parsing out a flag document as described above and serving it as a RESTful resource.

• Flag expirations prevent application boot.
• As flag expiry approaches, warnings are placed in the logs.
• The Last-Modified header is set to the time of the most recent flag commit for cache validation purposes.

Flags for different environments (eg. production, staging, etc.) are placed in different files in the flags directory. An environment variable on the server directs users accordingly. Diffing flags between environments is as simple as diffing between files.

Possible Future Features

Using GitHub Flavored Markdown as the encoding language for flags allows for additional semantic meaning in the application.

For instance, a Markdown strikethrough could denote flags that should be ignored:

• not-ready-for-primetime

Or we could embed key/value semantics in the flag contents. We are likely to restrict flag content to a certain set of characters or rules.

Hubot integration seems like the most natural next step to take.

Running

Fork/Clone this repository and run:

bundle install
bundle exec rackup

You can set the ENV variable RACK_ENV to direct which flag file to read.

bundle exec rake test

The above command will run the test suite, which is minimal right now, and just tests that flags have not expired.

Note: This is not in production at RTR. Flaggrocrag is in a proposal/RFC phase.