Software engineers don’t deploy code without version control. They review diffs, test in staging, and roll back when something breaks. AI workflows deserve the same discipline.
JieGou’s workflow version control system gives you immutable version history, structural diffing, one-click rollback, and canary deployments — all built into the workflow editor.
Every edit creates a version
When you modify a workflow’s structure — adding, removing, or reordering steps, changing input/output schemas — JieGou automatically creates a new version. History is append-only. Nothing is overwritten.
Each version is a complete snapshot: every step, every input mapping, every schema definition, frozen in time. You can browse the full timeline of a workflow’s evolution, see who made each change and when, and understand exactly how a workflow reached its current state.
This happens transparently. You edit workflows the same way you always have — the versioning layer works behind the scenes.
Structural diffing
Knowing that something changed isn’t enough. You need to know what changed.
The diff engine compares any two versions structurally. It identifies:
- Added steps — New steps that didn’t exist in the previous version
- Removed steps — Steps that were deleted
- Modified steps — Steps where configuration changed (recipe, input mappings, conditions, loop config, approval policy)
- Reordered steps — Steps that moved position in the execution order
- Schema changes — Added, removed, or modified fields in input/output schemas
For modified steps, the diff goes deeper. Nested structures like conditional branches (thenSteps / elseSteps), loop bodies, and parallel branches are compared recursively. You see exactly which field in which step changed.
The result is a human-readable summary — “2 step(s) modified, 1 step(s) added, input schema changed” — alongside the detailed diff view.
Rollback as a new version
Rolling back doesn’t rewrite history. When you roll back to version 3, JieGou copies that version’s steps and schemas into a brand-new version (say, version 8). The timeline shows the full story: versions 4 through 7 existed, something went wrong, and version 8 is a restoration of version 3.
This means rollbacks are safe. You can always roll forward again if the rollback itself was a mistake.
Canary rollouts
The riskiest moment for any workflow is right after a change. Canary rollouts let you test changes on a fraction of automated traffic before committing.
Here’s how it works:
- Start a canary. Select the new version and a traffic percentage — say, 10%.
- Automated routing. When a schedule or webhook triggers the workflow,
resolveWorkflowVersion()generates a random number. 10% of executions route to the canary version; 90% continue on the active version. - Metrics accumulate. Each execution records success/failure, duration, and token usage against its version. Redis counters aggregate these in real time.
- Promote or rollback. When you’re confident, promote the canary to active (retiring the old version). Or roll back if the metrics don’t look right.
For hands-off operation, configure auto-promote: set a minimum number of runs and a minimum success rate. Once the canary hits both thresholds, it’s promoted automatically. If the canary hasn’t met the threshold after a configurable time limit, it’s rolled back automatically.
Manual execution always uses the active version unless you explicitly select a different one.
Per-version metrics
Every version accumulates its own performance data:
- Total runs — How many times this version has executed
- Success rate — Percentage of runs that completed without error
- Average duration — How long execution takes on this version
- Error count — How many runs failed
These metrics power the canary promote/rollback decisions, but they’re also useful for spotting regressions. If version 5 had a 98% success rate and version 6 drops to 91%, you know something changed — and you can diff the two versions to find out what.
Why this matters
Without version control, workflow changes are irreversible. A bad edit means manually reconstructing what the workflow looked like before. With version control:
- Auditors can trace exactly what changed, when, and by whom
- Teams can review diffs before promoting changes to production
- Operators can canary-test changes on real traffic without risk
- Anyone can roll back instantly when something breaks
Version history and diffing are available on all plans. Canary rollouts and auto-promote are available on Enterprise. Learn more about workflows or start your free trial.