How Regression Guard works

Set up your projects. Analyse the release candidate. Review and fix unintentional changes before deployment.

In four steps:
  1. 1
    Set the production reference
    Connect source control, identify production and configure the relevant component relationships.
  2. 2
    Select the candidate
    Choose the release candidate you want to evaluate.
  3. 3
    Compare behaviour
    Map affected flows and isolate behaviour that differs from production.
  4. 4
    Review the result
    Review Early's Expected and Regression verdicts and inspect the evidence and source behind each one.
The result: A release decision grounded in the behaviour that changed.
Early release candidate view showing components being analyzed for release readiness
Inside the analysis

Evidence behind every result

Follow the affected path

Trace the candidate change through dependent components to the business flow that changed.

Early result tracing an upstream backend change to a regression in a dependent frontend flow
From source change to affected flow
Early Regression Guard results with one regression enlarged to show confidence, affected project and changed behaviour
Expected or Regression

Inspect the evidence behind each verdict

Review the evidence and source behind Early's Expected or Regression verdict.

Take the context into the fix

Connect the behaviour to its source change, commit and analysis run, then pass that context to the engineer or coding agent.

Trace linking a Regression result to its source change, commit and analysis run
Source and evidence together

Test Regression Guard against your own release

[pilot with Early]