These "feature flags" are simply acting as configuration, not as feature
flags (things that could conceivably be toggled on and off on a request
by request basis). Perhaps more importantly, the application cannot
function without the accounts system or API :)
By setting target_metadata correctly we can make migrations more quickly
by simply comparing the schema as defined in code to the schema in the
local database and create the migration with:
alembic -c conf/alembic.ini revision --autogenerate -m "Some migration"
The way we had implemented feature flags was pretty inflexible, and
wasn't effectively allowing us to do the one thing that feature flags
are really intended to do, namely:
> Decouple deployment (when you push code to production) from release
> (when users see new features).
A truly effective feature flag system is one which achieves the above,
and also enables more dynamic options for "releasing" such as:
- release to admin users/beta users only
- release to a randomly selected 10% of users
- release only to one specific user
This requires that the feature flag system have some knowledge of the
Furthermore, in order to make the feature flag system truly atomic and
reversible (i.e. shit has gone wrong, let's flip that back) we need to
be able to toggle feature flags instantly, without needing to wait for
an application redeploy.
Both of these requirements indicate a feature flag system fully
integrated with the request-response cycle of the application, and one
where flag status can be more complex than a simple boolean.
In order to make this possible, this commit puts feature flags into a
"feature" table of the main application database. This allows us to
extend the definition of flag state as and when we see fit to enable
some or all of the release options denoted above.
The initial state of all feature flags is off, but in order to
facilitate an easy migration path for us the data migration with this
commit will read the current state of the existing flags from the system
environment and write appropriate rows into the table.
In order to respond to feature flag changes on the frontend, we need a
way of knowing what the current feature flag values are on the backend.
This commit adds a basic feature flag client that retrieves current
feature flag values by making an ajax request to the server. The client
also includes a cache, and supports retrieving new value from the server
when the cache expires.
Our first attempt at integrating feature flags with the frontend
required a rebuild and redeploy of the extension, which somewhat
defeats the purpose of feature flags. This commit wires up the new
feature client introduced in the preceding commits, allowing feature
toggles to update behaviour of already-deployed clients.
All checks have passed
2 successful checks
— The Travis CI build passed