Recently I’ve been dabbling with Azure App Configuration - a very nice technology if you ask me, which allows you to build your applications or services leveraging dynamic exposure control, canary releases, etc.
I liked it so much that I spoke about that at the London Microsoft DevOps Meetup this month, with lots of follow-up questions. One of them was pretty tough!
Do you consider feature toggles and flags part of configuration management?
The answer is a strong yes. Feature flags, rings, etc. all rely on configuration items being retrieved.
It doesn’t really matter what they are…it’s very much up to you what you use them for: static consumption, environment setup, exposure segmentation. We briefly talked about how to get started with adoption - rather than getting started with a massive refactoring exercise, you can slap a legacy flag on everything already in production, and start building new segmented areas of your application. Or you can start extracting key values used by your application (a configuration string perhaps?) and move them to Azure App Configuration so you can control their lifecycle in an easier fashion.
What really matters though is the concept of having a centralised database for configuration values. It gives you more control on a single source of truth for key information used by your services, and you can also update that as part of your CI/CD pipelines in a structured way, without relying on files.
Extensions (1, 2) for Azure DevOps and GitHub make this very easy, and azure appconfig is the cli tool to use.