Skip to main content
Production is broken. You need to rollback. Now.

Instant Rollback

The Problem

Production breaks at 2:47 PM on Tuesday. A customer reports a bug. Your AI system is giving wrong answers. Traditional approach:
Edgit approach:

How It Works

Edgit uses a 4-level tag format: components/prompts/extraction/production Environment tags (like production, staging) are mutable - they move to point at different versions. This is why you need --force when pushing: Git requires it to update remote tags that already exist.
Philosophy: Edgit creates/moves tags. GitHub Actions detects the tag push and deploys. Separation of concerns.

Why —force is Required

Environment tags are mutable pointers. When you rollback:
  1. production tag already exists pointing to v1.1.0
  2. You move it to point to v1.0.0
  3. Git sees this as “rewriting” the tag
  4. --force tells Git: “Yes, I want to move this tag”
This is safe - you’re not rewriting history, just moving an environment pointer.

Emergency Rollback Playbook

Step 1: Check Current Deployment

Step 2: Find Last Known Good Version

Step 3: Rollback

Step 4: Monitor

Step 5: Investigate

Total time: Under 2 minutes from “production is broken” to “production is fixed.”

Partial Rollback

You don’t have to rollback everything. Roll back only what’s broken.

Scenario

You deployed 3 components at once:
  • prompts/extraction v1.1.0 Works fine
  • prompts/analysis v2.0.0 BROKEN
  • configs/validation v1.5.0 Works fine
This is the power of independent versioning.

Time Travel: Recreate Any State

The Problem

Customer reports: “On Tuesday at 2:47 PM, the AI gave me a wrong answer.” You need to reproduce the exact environment that was running at that moment.

Solution: Time Travel

Now recreate that exact state:
Test in debug environment:

Find the Bug

Now fix and deploy:

Rollback Strategies

Strategy 1: Immediate Rollback

When: Production is on fire, customers are affected

Strategy 2: Gradual Rollback

When: Not sure if current version is the problem

Strategy 3: Targeted Rollback

When: Only affecting specific users/regions

Rollback Best Practices

1. Always Have a Rollback Plan

Before deploying:

2. Keep Multiple Versions Running

3. Automate Rollback

In CI/CD:

4. Test Rollback Regularly

Time Travel Use Cases

Use Case 1: Reproduce Customer Bug

Customer: “I got wrong results yesterday at 3 PM”

Use Case 2: Performance Regression Analysis

“Performance was better last week. What changed?”

Use Case 3: A/B Test Historical Versions

“Was v1.5.0 actually better than v1.8.0?”
Ensemble configuration:

Use Case 4: Audit Trail

“Who deployed what and when?”

Advanced: Time Travel with Git

Git tags retain the commit history. To see what was deployed at a specific time, use Git directly:

Rollback Safety Checks

Before rolling back:

Troubleshooting

Rollback Not Taking Effect

Can’t Find Version to Rollback To

Rolled Back But Issue Persists

Next Steps

Deployment Strategies

Canaries, blue-green, progressive rollouts

A/B Testing

Test multiple versions simultaneously

CI/CD Integration

Automate deployments and rollbacks

Versioning Guide

Master version management