Q: Your team practices trunk-based development. A long-running feature takes 3 weeks to build. How do you keep it out of production?
Use feature flags (feature toggles):
#CI/CD #GitOps & Deployment Strategies #L3 #DevOps #Automation #Pipelines
🎙️ Candidate Opening & Architectural Context
""In enterprise CI/CD, you cannot rely on manual interventions; every rollback and promotion must be declarative. When addressing this question, I walk the interviewer through our production incident runbook: isolating the blast radius, checking diagnostic logs and metrics, and applying a safe fix.""
Advertisement
🛠️ Production Runbook & Step-by-Step Resolution
1️⃣
Initial Diagnostics & Root Cause Analysis
Use feature flags (feature toggles):
- Wrap the new feature code in a flag:
if (featureFlags.isEnabled("new-checkout-flow")) { ... }. - The code is deployed to production but the feature is OFF by default.
- Enable it gradually: for internal users first → beta users → all users.
- Rollback is instant — just turn the flag off without redeployment.
- Continuous deployment without exposing incomplete features.
2️⃣
Remediation & Permanent Safeguards
Tools: LaunchDarkly, Unleash, AWS AppConfig, or a simple Redis/DynamoDB-backed flag store. Benefits: Downside: flag debt — flags must be cleaned up after feature fully rolls out. Accumulating old flags makes code messy.
- Separate deployment from release.
- Easy A/B testing.
- Instant kill switch in production.
💡 The Senior SRE Gold Nugget (Key Architectural Takeaway)
"Pro-Tip: Wrap the new feature code in a flag: if (featureFlags.isEnabled("new-checkout-flow")) { ... }.."
⚡ 60-Second Elevator Pitch Talking Points
- Wrap the new feature code in a flag: if (featureFlags.isEnabled("new-checkout-flow")) { ... }.
- The code is deployed to production but the feature is OFF by default.
- Enable it gradually: for internal users first → beta users → all users.
Advertisement