This is the New Relic entry in our Annie meets X series, next to Annie meets pup, Annie meets gcx, and Annie meets acli. The integration uses New Relic Change Tracking and the New Relic CLI.
Summary
A platform team upgrades session-cache from Redis 7.0 to Redis 7.2. The deploy pipeline sees one infrastructure change. Production sees the messier version: checkout, notifications, and catalog all read that cache.
Redis 7.2 rollout
checkout-service payments
notification-worker notifications
catalog-api catalogNew Relic is already where those teams look when latency or errors move. The open question comes earlier: which New Relic entities should receive the Change Tracking event?
Anyshift via annie do affected services, owners, New Relic targets, evidence
New Relic CLI native Change Tracking eventsNew Relic stays the operational surface. Anyshift, through annie do, answers where the event belongs and why before handing off the approved write.
The Problem
In New Relic, a Change Tracking event is the recorded change. The UI can show that event as a marker on charts and on the entity's Change tracking page.
That matters because the visual marker only helps when it appears on the chart someone is actually reading.
If checkout latency jumps after the Redis rollout, the checkout team should see that rollout on the checkout timeline. They should not have to know that checkout reads session-cache, that session-cache was upgraded by the platform team, or that the same cache also feeds notifications and catalog.
New Relic already has the right product surface. Change Tracking records changes and connects them to performance data. A New Relic entity is the monitored object that gets the event. In this demo, that means a workload for checkout, a workload for notifications, and a workload for catalog. The New Relic CLI can create a Change Tracking event for an entity, with fields such as entitySearch, groupId, deepLink, commit, and version.
The CLI still needs an answer from somewhere:
Which New Relic entities should get this Change Tracking event?That answer lives outside observability, across code imports, Terraform, live infrastructure, deploy history, and ownership signals. That is the context Anyshift brings into annie do.
The Context Anyshift Adds
This workflow is valuable because of the context Anyshift brings before New Relic writes anything.
For the Redis rollout, annie do asks the Anyshift graph for routing facts that usually live in different places:
- Dependency context: checkout, notifications, and catalog all read
session-cache, even though only the cache changed. - Runtime context: these are the production services still running. Sandbox and deprecated workloads are skipped.
- Ownership context: checkout maps to payments, the worker maps to notifications, and the catalog API maps to catalog.
- New Relic context: each service maps to the New Relic entity where the Change Tracking event should appear.
- Evidence context: every target has a short reason, such as "reads session-cache on cart paths" or "reads session-cache before dispatch."
That is the point of the integration. The event is useful because it lands on the chart the right team will open later, with enough explanation to trust why it is there.
How Anyshift Runs It
The Anyshift side is one workflow. annie do is the command the engineer runs: it pulls the production context above from the Anyshift graph, prepares the New Relic writes, and stops for review.
The hard boundary is the write path. newrelic, New Relic's CLI, owns that part with New Relic auth.
The engineer starts with a plain-English request:
The run above is from the demo tenant. After approval, it executes the New Relic CLI steps and saves the audit file on disk.
Behind that short plan, Anyshift has already answered the important question: which production entities should see this rollout in New Relic, and what evidence justifies each one.
Then annie do renders the reviewed handoff in Go. The shell loop and New Relic payload are deterministic. The engineer reads the generated steps before anything is sent.
The Review Boundary
The generated file is the review surface. The full runbook stays on disk; the excerpt below shows the useful part: the Anyshift context, the New Relic command, and the shared groupId before the engineer approves the write.
The shared groupId keeps the events tied together as one change set. Each entity still gets its own Change Tracking event, because checkout, notifications, and catalog read different New Relic views.
It Lands in New Relic
Before the run, the checkout workload has no recent Change Tracking event for the Redis rollout.
After approval, the New Relic CLI writes the event to that same workload. Same demo tenant, same checkout entity.
The same CLI run wrote Change Tracking events for notification-worker-prod and catalog-api-prod as well. The runbook records all three returned Change Tracking IDs under the same groupId.
Why the Deploy Pipeline Is Not Enough
A deploy pipeline can create a Change Tracking event for the service it just shipped. Useful, and often enough.
Shared changes are where that breaks down. A Redis upgrade, IAM policy change, queue configuration update, or Terraform module change can affect services that did not deploy at all. Their New Relic charts miss the event, even if those teams are the ones debugging later.
Through annie do, Anyshift handles placement before the event is written: it finds the production services that depend on the changed component, maps them to New Relic entities, and prepares one reviewed Change Tracking event per affected entity.
New Relic gets context the deploy pipeline does not have:
- which production services consume the changed component
- which team owns each service
- which New Relic entity should receive the event
- why that entity was included
- how the whole rollout can be queried through one
groupId
When a team opens New Relic during an incident, the relevant change is already on their chart.
The Handoff
Anyshift never holds New Relic credentials in this workflow. The New Relic CLI owns the write path, and the runbook on disk is the contract between them.
What Teams Get
Before this, a shared production change can be recorded and still be invisible to the team that feels it.
Afterward, the checkout team sees the Redis rollout on checkout. Notifications sees it on the worker. Catalog sees it on the API. Each event has the same source link, the same group ID, and a short explanation for why that service was included.
Engineers keep working in New Relic. Anyshift supplies the production context New Relic cannot infer from one PR or deploy event alone.
Where This Goes Next
The next New Relic workflows are nearby.
Pre-change preview. Before a risky rollout, Anyshift can show which New Relic entities will receive events and which teams own them, directly from annie do.
Post-change correlation. If latency or errors move after an event lands, Anyshift can attach the graph evidence that explains why the change is relevant to that entity.
Change-set reporting. Because every event shares a groupId, teams can query the rollout across entities and compare impact by service.
For New Relic, the win is simple: the right Change Tracking event on the right entity before the incident starts.
