Feature Flagging

Building new features and deploying them safely takes too long. When there is no gap between deploying code and displaying it to users, it raises the stakes of deployment. As a result, code tends to stay branched too long, especially for more complicated features. Merges have more conflicts and are harder to work through. When new code is displayed to all users, rather than just a small group, it raises the stakes even further. To cope, engineers spend time writing excessive test and simulation code, which is expensive and only an imperfect substitute for live load testing.

How feature flags work in Causal

All features defined using Causal can be switched off and on without deploying code. This decouples deploying features from displaying them to customers, allowing teams to ship faster. Rather than maintaining separate branches of code for long periods of time while the code is developed and tested, code can be merged more often. Engineers can avoid messy, complicated merge conflicts. And, engineers get better visibility into what’s being developed across the company.

Traffic to these features can also be scaled up and down. The same is true for specific attributes of a feature (e.g. the algorithm for a cross-sell). For example, a team could wait to turn on a feature to time it with a promotional event, slowly ramp traffic to a new feature to de-risk deploying it, or slowly shift traffic from one algorithm to another to allow for provisioning. This functionality allows devops to deploy new code with less risk. A team can release the feature to a small subset of customers to verify that a feature works in production without having to release it to every customer.

These features increase the overall velocity of the engineering team and lower the risk of every deployment because:

• Engineers can merge more often with less risk, tightening the loop between writing code and getting feedback on it.
• Engineering and devops can do true load testing, de-risking deployment and avoiding the need to write complicated simulation code that only sort of works.
• Data scientists can ramp traffic to new algorithms without having to rely on engineers, reducing friction and lowering the risk of introducing new algorithms.