Comment by jonathannorris | Hacker News Reader

Comment by jonathannorris | Hacker News Reader

Parent Full thread

You can use a git-based workflow for feature flags, that's likely how most teams will start using flags in their code with environment variables and infrastructure state. However, most deployment pipelines in the wild are very slow and owned by engineering, limiting the value of doing git-based state for your Feature Flags.

I've seen that disconnecting the deployment of code from releasing of features can be transformative in various ways that fit better with an API-based model for Feature Flags:

- Many flags / remote config changes in production environments are made by non-developer members of a team.

- Coordinating releases across multiple platforms that have different deployment cycles. For example, deploying a new feature to Mobile + Web + APIs simultaneously.

- Enabling / disabling flags in real-time across your stack to respond to incidents.

- Support / Sales teams using Flags to gate features for customers.

- Remote config to populate data for UIs, to act as a CDN for content.

- Rolling out infrastructure changes, being able to roll back changes instantly without another deployment.

(And for context: our Feature Flag decisioning is done locally for our local bucketing server SDKs)

I put this in another comment, but disconnecting of code and feature release can still be achieved while storing feature flags as code. You need to build out a seperate pipeline and release process. With this you can still achieve all the advantages that you listed out.

I think the key difference is if you consider feature flags to be configuration and believe in configuration as code as a best practice.

I think this is the right approach in the long term. People having the ability to modify configuration in production in real time is an outage waiting to happen without having an obvious way to rollback to previously known working state.

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.

I don't think using source control is incompatible with this. You can persist state in source control, and have a separate deployment pipeline that is triggered only for updates to feature flag files. It is also deployed separately; e.g., to a key-value store.

Reply on news.ycombinator.com