Rollbacks

Learn how to rollback your application to a previous release when issues occur.

Overview

Rollbacks allow you to instantly revert your application to a previously deployed release. This is essential for recovering from bad deployments, bugs, or breaking changes.

Why Rollback?

Common reasons to rollback:

• New release has critical bugs
• Performance degradation
• Breaking changes affect users
• Configuration errors
• Security vulnerabilities discovered

Zero-Downtime Rollbacks

All rollbacks in brdz are zero-downtime:

• Instant switch to previous release
• No service interruption
• Immediate traffic routing to old version

How to Rollback

Step 1: List Releases

View available releases for your app:

# Ensure correct app context
brdz ctx:get

# List all releases
brdz releases:list

Output example:

ID    Status     Created At
52    active     2025-01-18 16:00:00  <- Current (broken)
51    inactive   2025-01-18 14:30:00  <- Previous (working)
50    inactive   2025-01-17 10:15:00
49    inactive   2025-01-16 18:45:00

Step 2: Identify Target Release

Find the release ID you want to rollback to (usually the previous active release).

Step 3: Execute Rollback

brdz releases:rollback 51

The rollback happens instantly:

1. Release 51 becomes active
2. Release 52 becomes inactive
3. Traffic immediately routes to release 51
4. No downtime occurs

Step 4: Verify

# Verify the rollback
brdz releases:list

# Should show:
# ID    Status     Created At
# 52    inactive   2025-01-18 16:00:00
# 51    active     2025-01-18 14:30:00  <- Now active
# ...

Test your application to confirm it’s working correctly.

Common Scenarios

Scenario 1: Immediate Rollback

A new deployment has critical bugs:

# Deploy new version
brdz releases:create new-version.zip
# ID: 42 (now active)

# Bugs discovered immediately
# Rollback to previous release
brdz releases:list
brdz releases:rollback 41

# Users now see the stable version

Scenario 2: Partial Rollout Issue

Testing reveals issues after partial deployment:

# Initial deployment looks good
brdz releases:create v2.0.zip

# After monitoring, issues found
# Rollback to stable version
brdz releases:list
brdz releases:rollback 40

Scenario 3: Multiple Rollbacks

Need to go back several versions:

# Current release: 45 (broken)
# Previous: 44 (also broken)
# Target: 43 (stable)

brdz releases:list
brdz releases:rollback 43

Scenario 4: Rollback and Fix

Rollback, fix issues, then redeploy:

# Rollback to stable version
brdz releases:rollback 40

# Fix the issues locally
npm run fix-bugs

# Build and test
npm run build
npm run test

# Deploy fixed version
zip -r release.zip dist/
brdz releases:create release.zip

Best Practices

1. Monitor After Deployment

Always monitor new releases:

• Watch error logs
• Monitor performance metrics
• Check user reports
• Review analytics

2. Keep Release History

Don’t delete old releases immediately:

• Keep at least 5-10 recent releases
• Maintain stable versions for quick rollback
• Document known-good releases

3. Test Before Production

Use staging environments:

# Deploy to staging first
brdz ctx:use  # Select staging app
brdz releases:create release.zip

# Test thoroughly

# Deploy to production
brdz ctx:use  # Select production app
brdz releases:create release.zip

4. Document Releases

Keep notes about releases:

# Create release with version tag
git tag v1.2.3
npm run build
zip -r release-v1.2.3.zip dist/
brdz releases:create release-v1.2.3.zip

# Document in changelog
echo "Release 52: v1.2.3 - Added new feature" >> releases.log

5. Have a Rollback Plan

Before each deployment:

1. Note current release ID
2. Verify rollback command
3. Set up monitoring
4. Define rollback criteria

Example plan:

# Pre-deployment checklist
echo "Current release: $(brdz releases:list | grep active | awk '{print $1}')" > rollback-plan.txt
echo "Rollback command: brdz releases:rollback 51" >> rollback-plan.txt
echo "Monitor: https://monitoring.example.com" >> rollback-plan.txt

Rollback Strategy

Conservative Approach

Rollback at first sign of trouble:

• Any critical errors
• Performance degradation > 10%
• User complaints increase
• Monitoring alerts trigger

Measured Approach

Investigate before rolling back:

• Assess impact severity
• Check if fixable quickly
• Consider hotfix deployment
• Evaluate rollback timing

Decision Matrix

Issue Severity	User Impact	Action
Critical	High	Immediate rollback
High	Medium	Quick investigation, likely rollback
Medium	Low	Investigate, monitor, rollback if worsens
Low	None	Fix in next release

Advanced Rollback Patterns

Canary Rollback

Deploy to subset of users, rollback if issues:

# Deploy to canary app
brdz ctx:use  # Select canary app
brdz releases:create release.zip

# Monitor canary users
# If issues, rollback canary
brdz releases:rollback 40

# Don't deploy to production

Blue-Green Rollback

Maintain two environments:

# Green (current production)
brdz ctx:use  # Select green-app
# Currently serving traffic

# Blue (new version)
brdz ctx:use  # Select blue-app
brdz releases:create new-version.zip

# Test blue environment
# If good, switch traffic (DNS, load balancer)
# If bad, keep serving from green

Feature Flag Rollback

Use feature flags to disable problematic features:

# Instead of rollback, disable feature
# (Requires feature flags in your app)

# Or rollback to version without feature
brdz releases:rollback 40

Troubleshooting

Rollback Fails

If rollback command fails:

1. Check permissions:

   brdz auth:login

2. Verify release exists:

   brdz releases:list

3. Check context:

   brdz ctx:get

Application Still Broken

If application issues persist after rollback:

1. Verify correct release is active:

   brdz releases:list | grep active

2. Check browser cache:

   • Clear browser cache
   • Test in incognito mode
   • Try different browser

3. Check CDN/cache:

   • Purge CDN cache if using one
   • Wait for cache TTL

4. Database migrations:

   • Check if database changes are incompatible
   • May need to rollback database separately

Wrong Release Activated

If you rollback to wrong release:

# Immediately rollback to correct release
brdz releases:list
brdz releases:rollback <correct-release-id>

Post-Rollback Actions

After rolling back:

1. Investigate root cause

   • Review logs and errors
   • Identify what went wrong
   • Document findings

2. Fix the issue

   • Address bugs in code
   • Update tests
   • Review changes carefully

3. Test thoroughly

   • Unit tests
   • Integration tests
   • Manual testing
   • Staging environment

4. Plan redeployment

   • Choose deployment window
   • Notify team
   • Prepare monitoring

5. Deploy fix

   npm run build
   zip -r release-fixed.zip dist/
   brdz releases:create release-fixed.zip

6. Monitor closely

   • Watch for same issues
   • Compare metrics to pre-issue baseline
   • Get user feedback

Rollback Automation

Example rollback script:

#!/bin/bash
# rollback.sh - Emergency rollback script

set -e

# Configuration
APP_CONTEXT="production/web-app"

echo "=== Emergency Rollback Script ==="
echo "Current releases:"
brdz releases:list

echo ""
read -p "Enter release ID to rollback to: " RELEASE_ID

echo "Rolling back to release $RELEASE_ID..."
brdz releases:rollback $RELEASE_ID

echo ""
echo "Rollback complete!"
echo "New active release:"
brdz releases:list | grep active

echo ""
echo "Please verify the application is working correctly."

See Also

• Releases
• Deploy Your First App
• Concepts: Releases