daily-email: add 2023-06-12
Feature flags in a multi-tenancy application
This commit is contained in:
parent
c070e69f05
commit
a28123b6f2
17
src/content/daily-email/2023-06-12.md
Normal file
17
src/content/daily-email/2023-06-12.md
Normal file
|
@ -0,0 +1,17 @@
|
|||
---
|
||||
title: >
|
||||
Feature flags in a multi-tenancy application
|
||||
pubDate: 2023-06-12
|
||||
permalink: >
|
||||
archive/2023/06/12/feature-flags-in-a-multi-tenancy-application
|
||||
tags:
|
||||
- feature-flags
|
||||
---
|
||||
|
||||
A scenario for having long-lived feature flags is in a multi-tenant application where the same codebase serves multiple projects - e.g. a multi-site Drupal application or a module reused on multiple websites.
|
||||
|
||||
This is the use case I have for a client project which uses a multi-site setup to serve multiple websites from the same Drupal codebase.
|
||||
|
||||
If I need to add a feature to sites 1 and 3 but not site 2 or test a change to only site 2, I can do this by enabling a per-site feature flag.
|
||||
|
||||
Instead of being removed, these flags will remain until the change can be made permanent on all websites, meaning it can be toggled on and off as needed - allowing each site to be configured separately whilst keeping it easy to maintain by having a single canonical codebase.
|
Loading…
Reference in a new issue