“Change is inevitable…except from a vending machine.”

If memory serves (it was over 20 years ago), that’s what the free t-shirt that Microsoft gave me for being an official Windows 98 beta tester said. And yes, being a beta volunteer required me to haul my desktop PC to Redmond, WA (from Seattle)…because…I guess that’s how it was done back then? I remember they gave us pizza, and I needed to install more RAM. As I said before, it was a while ago; however, the whole “change is inevitable” thing is still valid today.

When you’re dealing with complex digital systems, the only real constant is change. Changing microservices and cloud infrastructure. New software releases and rollbacks. Any time a configuration changes, services can be impacted. If you’re dealing with a new digital incident, it’s helpful to know what changed so you can get a jump on your incident response. Better yet, find out when something changes that could lead to a digital incident.

We launched Change Impact Mapping to help teams quickly identify where changes have—and could—cause failures. This real-time, contextualized information helps DevOps teams identify the service causing problems as promptly as possible. By fully integrating change events from the software delivery process (CI/CD pipelines) and code repositories, we give teams complete visibility across these changes to better understand their impacts.

We’ve partnered with many of the software companies you depend on to collect these events, giving you an even more accurate view of your digital landscape. Below are some of the tools that PagerDuty can integrate with for Change Impact Mapping.

Pro tip: We recommend mapping your events to the PagerDuty service representing what you are changing. That way, responders can quickly identify recent changes to their service when they get notified of an incident. Here are some of our partners whose tools allow you to ingest change events.

GitHub

We partnered with GitHub to allow PagerDuty users to ingest change events from GitHub or GitHub Enterprise. New pull requests and commits can be fed into PagerDuty to provide even more context. Users can quickly review—in PagerDuty—change events from the service’s Recent Activity timelines during incident triage or hypercare. Any recent changes to a service are surfaced for the responder to see. You can navigate across all changes via a comprehensive list of Recent Changes among your services.

GitLab

PagerDuty’s GitLab integration helps teams send notification-free events from GitLab to PagerDuty services. Users can ingest merge request events to help provide context for anyone using PagerDuty. We recommend mapping your GitLab events to the PagerDuty service that represents what you are changing. By doing so, you’ll make it easy for responders to quickly identify recent changes on their service when they get notified about an incident.

Evolven

PagerDuty’s integration with Evolven FIRST helps prevent incidents by delivering actionable alerts on risky changes. When an incident does occur, teams can dig deeper into them and associate the changes that may have contributed to it.

Granular change data is gathered and analyzed by Evolven to enrich and provide context to automated remediation. This functionality also lends itself nicely to hypercare.

Ansible

Ansible is a powerful automation engine that makes systems and applications simple to deploy. PagerDuty’s Change Event integration for Ansible allows teams to ingest and track any code or infrastructure change as a PagerDuty change event.

Buildkite

Integrating Buildkite with PagerDuty ensures you’ll be able to configure your Buildkite pipelines to send change events to your services whenever a build completes—pass or fail. Need to filter signal from noise? Support for conditional notifications ensures you’re only sending the data that matters to you. PagerDuty provides the Event Intelligence, Buildkite delivers the events.

JFrog

With the JFrog Pipelines integration, events can be sent to PagerDuty during the software delivery process to reveal valuable information like what software is being built, what versions are being delivered, what environments are being provisioned, what builds are failing, and much more. This allows teams to correlate production issues with potential software issues, understand software delivery workloads, and understand how teams are delivering their software.

Jenkins Change Events

The Jenkins Change Events integration allows users to send Change Events and trigger post-build incidents via PagerDuty. When teams do this, they can see all of their build events in just a few steps. Recent change events in Jenkins will appear on relevant incidents to help users troubleshoot more effectively. Users can view all recent changes in Jenkins based on team, service, and date.

Have you embraced the inevitability of non-vending machine changes? Ready to get started with Change Impact Mapping? PagerDuty’s integration library can be sorted by “changes” to give you the latest information on which tools you can ingest events from. You can also send your events to PagerDuty through the Change Events API.

From your PagerDuty account, head to Incidents > Recent Changes from the top navigation, or learn more about it here.