Feature Management under CI/CD

Voluntarily is a system in continuous development. new features are added all the time and our automated continuous integration system moves changes through to online servers rapidly.

It is typical in a modern CI/CD environment for urgent bug fixes to be identified, corrected, committed, checked and deployed to a production system within 40 minutes.

We also run a trunk-based feature development model. This means that all changes branch directly from the master release branch and are merged back in after each small set of changes. This means that the production release may from time to time contain features that are only partially implemented, not fully debugged, not acceptance tested etc.

We don’t want to expose incomplete or untested features to the customers. So we need a way to turn off or on each feature according to which environment it is running in: dev, alpha, beta, live etc.

We may even want to expose new features only to certain groups of people. e.g if we designate some people early adopters.

Solution - Feature Flags

Feature flags are named values available to the system that wrap whether a component or feature should be available. They operate on both the server and client-side affecting API and UI elements.

Environment based Feature Flags

Use environment tests to completely restrict features to the development and test environment

const isNotProd = process.env.NODE_ENV !== 'production'

    {isNotProd && (
      <TabPane tab={opForumTab} key='question'>
        <OpQuestionPanel op={op} />
      </TabPane>
    )}

All the online environments - Alpha → Beta → Live etc are ‘production’. so this means a feature protected like this cannot be seen online, only in development.

Configuration based Feature Flags

The config file returns an object that contains various flags and values used to control behaviour.

import { config } from '../../config/config'

    config.features.showItems && <ItemContainer>
            <ItemLocation location={op.location} />

These are collected from both the source code and the environment. Where env vars are used a default is usually provided.

This mechanism allows features to be toggled by setting environment variables in the deployment container. This is not ideal as it requires an edit to the container service description on AWS and an update.

Session feature flags

Provide a database collection with an object describing a feature set. Add multiple documents - that can be selected based on some criteria. e.g. the role of the person. A selector in the environment, A/B testing etc.

When creating the session. find the appropriate entry and add to the user session. The session is added to redux store so the feature flags are available to all components and pages easily.

https://voluntarily.atlassian.net/browse/VP-1316