The Secret Life of Azure: Feature Flags and Controlled Releases
Releasing features safely with Azure App Configuration and Feature Flags.
Resilience & Release
The library was quiet, but Timothy was staring at a specific block of code on the chalkboard. He had a look of frustration that every developer knows well.
"Margaret," he said, "the deployment slot swap worked perfectly. The new code is in Production. But I have a problem. There’s a new 'v2' of the search algorithm in this deployment, and I’m not ready for every user to hit it yet. I wanted to let our internal team test it in Prod first, but the moment I swapped the slots, it went live for everyone. Do I have to redeploy the whole app just to hide a block of code?"
Margaret walked over, picked up a piece of white chalk, and drew a simple if/else block on the board.
"Timothy, you're treating the code like it's permanent once it's deployed. In Azure, we use Feature Flags to decouple the shipping of code from the enabling of logic."
She drew a toggle switch next to the code block.
The Logic Gate: Feature Flags
"A Feature Flag," Margaret explained, "is a conditional gate in your code. Instead of hard-coding the logic, your application makes a call to Azure App Configuration. It asks: 'Is the new search algorithm turned on right now?'"
Timothy traced the line on the board. "So, the code for the v2 algorithm is physically sitting in the Production environment, but the application just skips over it if the flag is off?"
"Exactly," Margaret said. "The binary is deployed, but the feature is dormant. You can flip that switch in the Azure Portal at any time. No redeploy, no swap, and no downtime. The logic changes at runtime."
Targeting: The Selective Switch
"But how do I limit it to just our team?" Timothy asked.
Margaret drew a small table next to the switch. "We use Targeting Filters. Inside App Configuration, we define a rule: 'If the user belongs to the Internal group, set the flag to True. For everyone else, set it to False.' We can even set a Percentage Filter—starting at 5% of all users to see if the server load spikes, then slowly dialing it up to 100%."
The Kill Switch: Operational Safety
Timothy looked at the if/else block. "And if the v2 algorithm starts throwing errors or crashing the database? I don't want to have to rollback the entire deployment and lose all the other fixes we shipped."
"That’s the beauty of it," Margaret replied. "The flag is your Kill Switch. If the telemetry shows the new feature is failing, you flip the flag to 'Off' in the Portal. The application immediately reverts to the v1 logic. The rest of the app stays up, and your users never even knew there was a crisis. You fixed it in seconds without a deployment."
Putting It into Practice
Timothy erased the "hard-coded" logic and drew the connection to the App Configuration service. "I see. I’ve been thinking of 'Deployment' and 'Release' as the same thing. But Deployment is just moving the bits; Release is when I choose to turn the logic on."
Margaret nodded. "Precisely. When you separate those two acts, you stop being afraid of your own code. You can ship features safely, test them in the real world with real data, and turn them on only when you are certain they are ready."
Key Concepts
- Azure App Configuration: A central repository for application settings and feature flags.
- Feature Flags: A conditional branch in code that queries a remote service to decide which execution path to take.
- Targeting: Using filters to enable features for specific users, groups, or a percentage of traffic (Canary testing).
- Kill Switch: Using a feature flag to instantly disable a failing feature in production without a rollback.
- Decoupling: The practice of separating the technical deployment of code from the functional release of a feature.
Aaron Rose is a software engineer and technology writer at tech-reader.blog and the author of Think Like a Genius.
Comments
Post a Comment