Annie is Anyshift's CLI for turning graph context into reviewed actions. This article shows how annie do works with sentry-cli release management: Anyshift finds the affected Sentry projects, then Sentry records the release and deploy through its own CLI.
Release Context Across The Real Impact Zone
Sentry releases are powerful when the right projects receive them. Sentry's release setup docs explain how releases connect new issues, regressions, deploys, commits, and release health.
The gap is scope. A graph-connector deploy can affect graph-connector, anyshift-backend, and slackbot, even though only one service shipped. A CI job can tell Sentry about the service it deployed. It usually cannot know every production service that will feel the change.
That is the value Anyshift adds: it reads the production graph, maps affected services to Sentry projects through DSN and environment evidence, skips non-production services, then asks sentry-cli to create one release and production deploy record across the actual impact zone.
Sentry remains the place where engineers triage issues. Anyshift makes sure Sentry gets the deploy context for the projects that will need it.
One Deploy Can Affect Projects That Did Not Ship
Sentry defines a release as a version of code deployed to an environment. When Sentry knows about a release, it can identify new issues and regressions, connect them to commits, and show release health.
That works well for a single service. It gets weaker when the change is shared infrastructure, a queue migration, an SDK change, or a service that fans out to other services. The projects that start throwing errors are not always the project that deployed.
Without the graph, teams either mark only the deploying project, which leaves downstream Sentry projects without context, or they manually keep a list of "also affected" projects. That list goes stale.
The Graph Chooses The Right Sentry Projects
In the demo, the request is:
annie do --print "mark the graph-connector deploy across affected Sentry projects"Before Sentry receives a write, Anyshift builds the project set:
1. Deploy target. graph-connector maps to the production workload and release.
2. Runtime impact. The graph follows queue, API, and dependency edges to the services expected to see errors during the deploy.
3. Sentry mapping. Anyshift maps each affected service to a Sentry project through `SENTRY_DSN` references and the Sentry `environment` tag.
4. Skip reasons. Sandbox-only or unmapped services stay out of the release.
This is the Anyshift part of the workflow: decide which Sentry projects should receive the same release context, and which services should be skipped. Sentry has not been touched yet.
Review First, Then Sentry Writes
annie do --print is the Anyshift CLI step. It turns graph context into a reviewable plan: the affected projects, the reason each one is included, and the Sentry commands that would run after approval. At this point, nothing has been written to Sentry.
After approval, the workflow crosses the boundary to Sentry's native CLI. In the isolated demo tenant, this is the command shape we tested: sentry-cli reads the organization and token from the local environment, then receives the project list Anyshift selected from the graph.
Those are Sentry concepts, not Anyshift concepts. The Sentry CLI creates the release, finalizes it, and records the deploy. When repository metadata is available, the same runbook can also call Sentry's commit association step. Anyshift only decides the project set and evidence before the write.
The Result In Sentry: One Release, Three Projects
One release now spans every affected Sentry project:
graph-connector, because it deployed.anyshift-backend, because it reads graph-connector output during fanout.slackbot, because notification retries are expected through the backend path.
Sentry can now use the same release and deploy context across those projects. If a new issue appears in slackbot right after the deploy, the release is visible where the engineer is already triaging, instead of being trapped in the service that happened to run CI.
Before the run, the Releases view has no matching release for 2026-05-28.demo-5:
After sentry-cli runs, the same Releases view shows 2026-05-28.demo-5 in graph-connector-demo, marked production. Sentry collapses the attached downstream projects as 2 hidden projects; in this demo, those are slackbot-demo and anyshift-backend-demo.
Nothing changes alert behavior. Sentry still captures issues, alert rules still work, and the deploy record becomes part of the evidence trail.
Why One CI Job Misses Downstream Impact
A CI job knows what it deployed. It can run sentry-cli for that project, and that is often enough.
Shared production changes are different. A queue drain, database migration, Terraform module update, or graph-ingestion deploy can affect services whose code did not change. Those teams still need release context in Sentry when they debug the errors.
Through its production graph, Anyshift supplies the missing join: code, infrastructure, live runtime dependencies, Sentry DSNs, environments, deploy history, and ownership. Sentry supplies the product surface where issues, regressions, commits, and release health already live.
What Sentry Teams Get
For Sentry users, the workflow is simple:
- More accurate release context on the projects that actually see errors.
- Better regression triage because affected downstream projects share the same deploy record.
- No stale project list and no hidden write path.
- A saved runbook explaining why each Sentry project was included.
The nearby verbs follow the same shape: annotate a Sentry issue with graph evidence, route ownership rules from the production graph, or open a focused triage view for every project touched by a risky deploy.
If your team uses Sentry and wants release context that follows production reality instead of one CI project at a time, contact us.
