The booking portal of Nordlicht Reisen GmbH, a fictional travel agency, gets a new feature, seat selection on bus trips. The team wants the code in production with the very next release, but wants to show the feature only when the business department is ready: first for the employees, then for ten percent of the customers, then for everyone. If a defect shows up, the feature should disappear in seconds without anyone releasing. That is the skill of this lesson: feature flags with the feature manager of Azure App Configuration.
Prior knowledge: Why the release can be separated from the deployment, you see in lesson 4.8 (progressive rollout) and 4.9 (feature flags as a guardrail of resilience). Signing in without a secret with a managed identity is taught in K3, lesson 3.3.1, Key Vault in K3, lesson 3.3.2. How the services of Azure are priced and how you keep track of cost is in K3, lesson 3.1.2. This lesson shows the feature flag tool in detail and asks how it fits into the chain of the release.
Not run against Azure; from the reference of Microsoft: All commands, configurations and menu paths of this lesson come from the documentation or are derived from it; they were not run in this course.
What a feature flag is
Feature management is, according to Microsoft, a development practice that decouples the release of a feature from the deployment of the code and changes availability on demand. The technique for it is the feature flag: It controls the life cycle of a feature dynamically, switches it on or off, directs it to certain users or rolls it out step by step, without redeploying the application. As benefits, Microsoft names: safe, targeted releases, faster experiments and less risk.
That fits what you have learned about safe deployments: Microsoft names feature flags as a means to deploy features but not show them right away, to activate them by environment, stage or deployment and to make them visible only to users who explicitly opt in (lesson 4.8). An addition from the recommendation on safe deployment: Changing a feature flag is also a change to production, with risk. It deserves the same care as every release.
The three kinds of use
When you create a flag, the feature manager in the portal asks what you need it for:
| Kind | Purpose | Means |
|---|---|---|
| Switch | simple, immediate toggle for all users; short-lived operational switches | Kill switch: switch off a faulty feature or dependency in seconds; switch maintenance mode on and off |
| Rollout | show a feature gradually to a percentage or to certain users and groups; canary or staged release | percentage, audiences, schedule, custom conditions |
| Experiment | compare versions (variants) and measure which does better; A/B test | variants, distribution of traffic, overrides |
An example from Microsoft for a rollout: A team starts at 5 percent, puts the internal testers at 100 percent through groups, excludes legacy accounts and raises the number over days to 25, 50 and 100 percent while it watches error metrics. That is lesson 4.8 with a configuration change instead of a release.