Feature Flag Rollout | Progressive Release
Progressive feature rollouts: start internal, expand to beta, then 5% to 25% to 50% to 100%. GitScrum tracks flag status and coordinates phases.
5 min read
Feature flags transform deployment from all-or-nothing events into controlled rollouts you can tune in real-time. GitScrum helps track feature flag status across tasks, coordinate flag-gated releases, and manage the lifecycle of flags from creation to cleanup.
Feature Flag Fundamentals
Flag Types
FEATURE FLAG CATEGORIES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ RELEASE FLAGS (temporary): │
│ Purpose: Control feature rollout │
│ Lifespan: Days to weeks │
│ Example: NEW_CHECKOUT_FLOW │
│ Remove: After 100% rollout │
│ │
│ EXPERIMENT FLAGS (temporary): │
│ Purpose: A/B testing │
│ Lifespan: Duration of experiment │
│ Example: PRICING_PAGE_VARIANT_B │
│ Remove: When experiment concludes │
│ │
│ OPS FLAGS (long-lived): │
│ Purpose: Operational control │
│ Lifespan: Permanent │
│ Example: ENABLE_RATE_LIMITING │
│ Remove: Never (toggle on/off as needed) │
│ │
│ PERMISSION FLAGS (long-lived): │
│ Purpose: Feature access control │
│ Lifespan: Permanent │
│ Example: ENTERPRISE_ANALYTICS │
│ Remove: Never (controls entitlements) │
└─────────────────────────────────────────────────────────────┘
Flag Lifecycle
FLAG LIFECYCLE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CREATE → DEVELOP → ROLLOUT → STABILIZE → CLEANUP │
│ │
│ CREATE: │
│ • Define flag name and type │
│ • Document purpose and owner │
│ • Set initial state (off) │
│ │
│ DEVELOP: │
│ • Implement feature behind flag │
│ • Test with flag on/off │
│ • Ship to production (flag off) │
│ │
│ ROLLOUT: │
│ • Enable for internal → beta → gradual % │
│ • Monitor metrics at each stage │
│ • Pause/rollback if issues │
│ │
│ STABILIZE: │
│ • Reach 100% rollout │
│ • Monitor for 1-2 weeks │
│ • Confirm feature is stable │
│ │
│ CLEANUP: │
│ • Remove flag checks from code │
│ • Delete flag configuration │
│ • Update documentation │
└─────────────────────────────────────────────────────────────┘
Rollout Strategies
Progressive Rollout
GRADUAL ROLLOUT PLAN:
┌─────────────────────────────────────────────────────────────┐
│ Feature: NEW_PAYMENT_FLOW │
├─────────────────────────────────────────────────────────────┤
│ │
│ STAGE 1: Internal (Day 1) │
│ Target: Company employees only │
│ Duration: 2 days │
│ Success: No critical bugs │
│ │
│ STAGE 2: Beta (Day 3) │
│ Target: Opted-in beta users (~500) │
│ Duration: 3 days │
│ Success: <1% error rate, positive feedback │
│ │
│ STAGE 3: 5% (Day 6) │
│ Target: Random 5% of users │
│ Duration: 2 days │
│ Success: Metrics stable vs control │
│ │
│ STAGE 4: 25% (Day 8) │
│ Target: Random 25% │
│ Duration: 3 days │
│ Success: Conversion rate maintained │
│ │
│ STAGE 5: 50% (Day 11) │
│ Target: Random 50% │
│ Duration: 3 days │
│ Success: Performance metrics OK │
│ │
│ STAGE 6: 100% (Day 14) │
│ Target: All users │
│ Duration: 7 days monitoring │
│ Success: Ready for cleanup │
└─────────────────────────────────────────────────────────────┘
Risk-Based Rollout
ROLLOUT DECISION MATRIX:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FEATURE RISK │ STRATEGY │
│─────────────────┼──────────────────────────────────────────│
│ LOW │ Internal → 25% → 100% │
│ (UI tweaks) │ 3-day rollout │
│ │ │
│ MEDIUM │ Internal → Beta → 5% → 25% → 50% → 100% │
│ (new features) │ 2-week rollout │
│ │ │
│ HIGH │ Internal → Beta → 1% → 5% → 10% → │
│ (payments, │ 25% → 50% → 75% → 100% │
│ auth, data) │ 4-week rollout, extensive monitoring │
│ │ │
│ CRITICAL │ Manual approval at each stage │
│ (compliance) │ Stakeholder sign-off required │
└─────────────────────────────────────────────────────────────┘
Monitoring and Metrics
Rollout Dashboard
FLAG STATUS DASHBOARD:
┌─────────────────────────────────────────────────────────────┐
│ NEW_PAYMENT_FLOW - Stage 4 (25%) │
├─────────────────────────────────────────────────────────────┤
│ │
│ ROLLOUT PROGRESS: │
│ [████████████░░░░░░░░░░░░░] 25% │
│ │
│ METRICS (Flag ON vs OFF): │
│ ON OFF DIFF │
│ Conversion: 4.2% 4.1% +0.1% ✅ │
│ Errors: 0.3% 0.3% 0.0% ✅ │
│ Load time: 1.2s 1.1s +0.1s ⚠️ │
│ Completions: 89% 88% +1.0% ✅ │
│ │
│ ALERTS: │
│ ⚠️ Load time slightly elevated - monitoring │
│ │
│ ACTIONS: │
│ [Advance to 50%] [Pause] [Rollback] │
└─────────────────────────────────────────────────────────────┘
Incident Response
ROLLBACK PROCEDURE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TRIGGERS FOR ROLLBACK: │
│ • Error rate > 2x baseline │
│ • Conversion drop > 5% │
│ • P0/P1 bug discovered │
│ • Significant user complaints │
│ │
│ ROLLBACK STEPS: │
│ 1. Disable flag (instant effect) │
│ 2. Notify team in #incident channel │
│ 3. Document issue │
│ 4. Create task for fix │
│ 5. Plan re-rollout │
│ │
│ POST-ROLLBACK: │
│ • Review what went wrong │
│ • Update monitoring if needed │
│ • Consider smaller rollout steps │
└─────────────────────────────────────────────────────────────┘