tech: Implementing Stack-Specific Feature Flags for RDev Environments in Single-Cell Data Portal

[atarashansky]

In a Slack conversation, the eng team discussed challenges with our current setup for feature flags in development (rdev) environments. A shared rdev secret is causing feature flags to affect all rdevs, not just the intended one.

Several solutions were proposed:

1. Storing feature flags in a YAML file on the branch.
2. Using environment variables or a file feature of the SecretsManager class.
3. Creating a separate feature flag service for different apps.
4. Storing feature flags in S3.
5. Using a service like split.io for feature flag management.

Trent Smith suggested a final recommendation: using a YAML file for feature flags, which would be read by the secrets config only in rdev environments. This approach ensures that forgetting to remove the flag won't affect other deployment stages and provides a template for documenting the secrets. This solution aims to prevent unintended impacts on other rdevs while maintaining the flexibility and power of feature flags.

[Bento007]

Trent Smith suggested a final recommendation: using a YAML file for feature flags, which would be read by the secrets config only in rdev environments. This approach ensures that forgetting to remove the flag won't affect other deployment stages and provides a template for documenting the secrets. This solution aims to prevent unintended impacts on other rdevs while maintaining the flexibility and power of feature flags.

If going with my suggestion, a few other important details to keep in mind.

• Feature flags are currently stored in a corpora/config
• The SecretConfig will need to be modified to read values from the file and look in AWS if the value is not found. This could break some tests.
• SecretConfig expect data to be in json form no yaml.

[metakuni]

I'd propose writing up a mini tech spec for this and doing a cross team review. 🙏