Redeploying after Rollback
A Rollback isn't the end of a feature's lifecycle—it's a safety event that provides critical data for a better second attempt.
Investigating the Cause
Before redeploying, it's essential to understand why the rollback or halt occurred.
- Check the Timeline: Look at the rollout's timeline to see the exact moment the trigger fired.
- Review Metrics: Analyze the linked dashboard to see which metric breached its threshold (e.g., a spike in 5xx errors).
- AI Root Cause Analysis: Flagship's AI correlates the rollback event with your system metrics to help you pinpoint the problematic commit or service.
Fixing the Issue
Once the root cause is identified:
- Apply the Fix: Update your code to address the regression.
- Verify: Ensure the fix is deployed to your environment.
- Flagship Updates: The feature flag remains in its "rolled back" or "halted" state in Flagship until you take action.
Restarting a Rollout
After you've fixed the underlying issue, you can return the feature to your users.
Resuming a Halted Rollout
If a Warning Trigger halted your rollout, you can simply click Resume Rollout once you've verified the fix. The AI will continue the previous plan from where it left off.
Starting a New Plan
If a full Automatic Rollback occurred, the previous plan is terminated. To redeploy:
- Create New Rollout: Set up a new rollout plan for the feature.
- Adjust Strategy: Consider a more conservative Rollout Strategy (e.g., lower starting percentage) to be extra cautious.
- Reset Triggers: Ensure your triggers are still relevant for the new version.
TIP
Use the "Draft" feature to prepare your second rollout attempt while you're still debugging, ensuring everything is ready to go as soon as the fix is live.