[jonathannorris]

We certainly see workflows where defining everything as code can be powerful. As we've been chatting about this internally today, we have ideas of how you could define all your features / audiences / variables as code and only deploy changes using a Terraform interface.

I feel like, ultimately, this overly limits the reach of feature flags within an organization; it makes it more difficult for most engineers who are not comfortable with Terraform to deploy their features; it limits the ability of product / marketing / project managers / QA from; scheduling releases, configuring experiments, testing features, modifying audiences, etc.

Modifying configurations certainly can cause production issues, which is why we have built tools like our variable schemas and strong typings for our variables to limit the value changes to only known values. With our CI / CLI / IDE integrations, we make it known what values variables can be set to, when variables are added and removed, and when variables enabled in production are modified by PRs. This is all in addition to existing permissions / change logs / rollback functionality we are improving on. One of our core responsibilities is to make changing Feature Flag values as safe as possible. We know that flags can quickly become tech debt, so we also preach that feature flags should be as easy to remove from your code as they are to add to your code.

A fully featured feature management platform should be with you from your IDE / CLI, Code Review / CI, Deployment Pipelines / Alerting and Monitoring, and integrated with your Project Management and Product Analytics. It should be visible to your team throughout their workflows what features are enabled across all your environments.