daily-email: add 2023-06-12
Feature flags in a multi-tenancy application
This commit is contained in:
		
							parent
							
								
									c070e69f05
								
							
						
					
					
						commit
						a28123b6f2
					
				
					 1 changed files with 17 additions and 0 deletions
				
			
		
							
								
								
									
										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…
	
	Add table
		Add a link
		
	
		Reference in a new issue