Duvaxa

DevOps & Cloud · Change impact analysis

BlastRadar

Know what a change will touch.

Before a release, see every service a change can affect and the line of code that links it. After the release, confirm those services are still healthy.

Engineering managers and platform leads at teams of 10–200 engineersDevOps consultancies running releases for clientsTeams without a full observability platform
change-impact · example
$ change-impact assess --base v1
change-impact: CRITICAL (100/100) for v1..HEAD, 5 files, 1 commits
E2 +30 CH001 Destructive database migration: ALTER TABLE orders DROP COLUMN coupon_code
E4 +18 CH005 Memory limit lowered: k8s/payments.yaml 512Mi to 256Mi
reports high direct uses column coupon_code (services/reports/nightly.py:2)
web high 1 hop calls orders, whose API changed
$ change-impact verify --report impact.json
REGRESSED orders error_rate 0.002 before, 0.031 after (+1450%)
Real run on the built-in demo shop. Links come from what the repository and services.json say; calls it can't see should be declared in services.json.
ReadsGit, deploys, Terraform plans
Runs onYour laptop, server or CI
AccessRead-only
Verifies withPrometheus, Datadog, New Relic

The problem

"It was a small change." A dropped column breaks a nightly report in another folder, a lower memory limit slows the checkout, a Cloudflare setting takes down the API. Nobody connected the change to what it touched.

What it does

01

Reads a git range, the last successful production deploy (GitHub or GitLab), a Terraform plan before apply, or changes made in a console: CDN, DNS, IAM, database settings

02

Maps your services from docker-compose and Kubernetes manifests, plus a simple services.json for owners, tiers, roles and domains

03

Finds the services that use a dropped column, a removed environment variable, a changed IAM role, domain or database, with file and line

04

Follows callers one and two hops away, so you see who sees the errors

05

21 change rules with the known way each breaks: destructive migrations, narrowed IAM, lower memory limits, fewer replicas, probes, ports, API contracts, shared libraries, major upgrades

06

Risk score from LOW to CRITICAL with a checklist to run before deploying

07

After the deploy: health checks and before/after metrics for exactly the affected services, from Prometheus, Datadog or New Relic, or numbers from any tool

08

Learns from your own releases: how often each kind of change was followed by a regression

09

Comment on GitHub pull requests and GitLab merge requests with the score, evidence, a dependency diagram and the checklist; CI gate on the riskiest changes

10

Deployment timeline with the risk of each production deploy

11

Optional Claude review for the on-call engineer, citing the evidence

12

Read-only, runs in your CI or on a laptop; no agent in production

How it works

  1. Connect the repository and, optionally, GitHub or GitLab deployments
  2. Add owners, tiers and health checks for the important services
  3. Get a report on every pull request, and a check after every deploy

Works with

GitHubGitLabTerraformKubernetesdocker-composePrometheusDatadogNew RelicClaude

Runs in your CI

GitHub Actions workflow step
# On every pull request
uses: Deepanshu18Saini/change-impact@main
# After the deploy
change-impact verify --report impact.json
Licensed customers get the action or command-line tool installed in their own organisation; it runs on your runners, so your code and plans never leave them. The command-line tools run in GitLab CI the same way.

Your data

  • Runs in your CI or on a laptop; your code stays where it is.
  • Read-only access to deployments and metrics; it never rolls back or restarts anything.
  • The optional Claude review sees the assessment only, never whole files.

Who it's for

Engineering managers and platform leads at teams of 10–200 engineersDevOps consultancies running releases for clientsTeams without a full observability platform

Questions

How does it know what depends on what?

From docker-compose and Kubernetes files, environment variables that point at other services, imports, SQL that names the same tables, and a short services.json for what code can't show.

What happens after the deploy?

verify checks health URLs and compares each affected service's metrics before and after, and exits non-zero on a regression so a pipeline can stop.

Related

Often used with BlastRadar

See BlastRadar on your own data

A 30-minute call. We run the product on your export, repository or document and walk you through the results.

Book a demo