Does change have to be scary? “Change is the only constant in life.” Heraclitus said about change. And we can say change is a nightmare for most IT practitioners everywhere. But we also know systems must be changed to improve in time. Change is inevitable for us. It is also essential to know that not every change causes problems. Changes that cause the pain are undetected, unplanned, unmanaged changes. Developer teams spend between 20% and 50% of their time identifying, triaging, diagnosing, and fixing issues. At the root of those problems are always the question of “what has changed”. The longer it takes to find the cause of the problem, the team will spend more time solving the problem and can’t move forward with a new task. Another problem is that as systems and deployment pipeline processes become more complex, it becomes more difficult to identify issues.
In the market, many observability tools provide basic deployment tracking features. But today, I want to talk about New Relic’s new and improved feature Change Tracking. In contrast to its competitors’ capabilities, New Relic Change Tracking feature is more flexible and can keep track of various change events and deployments. The New Relic observability platform collects different parameters like events, logs, traces, etc. With the help of all these parameters, New Relic inspects the entire flow in context and shows you if something has changed and how it is affecting your system. With the help of all these parameters, we can evaluate our system and analyze our problems.
Most IT outages occur due to some change. When one team deploys a change, the information may not be documented or accessible to other teams. This uncertainty can result in employees having to manually search for details such as who made the deployment, what changes were made, and when they happened, often requiring separate tools. New Relic’s primary motivation to start improving the change tracking feature is the acknowledgement that the company ships reliable features faster than other companies and tends to have happier developers and development teams.
New Relic APM has an existing API called REST API V2. With REST API, users can record fundamental deployment markers today. This usage will continue to exist. But New Relic developed a new API called NerdGraph API. This new API integrates with Jenkins and Github Actions as a start, and it will continue improving in time. Also, New Relic CLI support comes into the picture with this new API.
How to track your changes with New Relic Change Tracking?
The Change Tracking feature is an intelligent way to monitor your changes. You can start using change tracking by designating which changes you want to monitor. To track changes, New Relic offers us various ways. I will list these options below:
Track With CI/CD
- Jenkins: New Relic provides a plugin for Jenkins integration. With the help of this plugin, it became easier to use the change tracking feature.
- GitHub Actions: You can integrate Gitlab Actions CI/CD process by editing Github Actions yaml.
|
name: Change Tracking Marker |
Track with NerdGraph (GraphQL):
You can track your changes using GraphQL mutations and queries via our NerdGraph API. I will add an example mutation below:|
mutation { |
Track with CLI:
You can use the CLI option to create deployment markers for monitoring changes. To use this option, you must install New Relic CLI and create a deployment marker using the CLI command as a starter.|
newrelic entity deployment create --guid INSERT_YOUR_GUID_HERE --version <1.0.0> |
Note: If your current CI/CD tool is not supported for the Change Tracking integration, you can continue your setup with either CLI or NerdGraph.
This screenshot is a traditional New Relic observability summary page. As you can see, these lollipop markers are stand-for deployments markers.
Under the events section, you can reach out new change tracking interface.
When you hover over these markers, you will see a quick insight into related change.
And if you want to inspect a specific change, you need to click on the marker, which will direct you to the following interface deployment analysis UI. On this page, you will see golden signal dashboards related to your change and how this change affects your system. The primary information this page wants to deliver to the user is to show a snapshot of before and after deployment and to understand the health and quality impact on the entity. The golden signals of the application are brought together, and the change before and after the application is calculated based on an average of 3 hours. In addition, the graphics of sections such as logs, errors, and incidents in New Relic are added to this screen, which gives us a more general view.
Also, a new comparison feature is added inside of Change Tracking to compare two different deployment markers. You can say, I want to look at the last deployment compared to the one before. With this comparison feature, you are now able to do that.
As you can see, each time series chart will show a different line for different a deployment. With the help of this feature, we will be able to compare the relative performance of each deployment.
Conclusion
To see when new deployments happen in our team or outside of our team and how it affects our system, New Relic offers us a Change Tracking feature. With the change tracking feature, it is possible to understand the impact of those changes and how to troubleshoot, triage, and resolve incidents faster.
References
https://docs.newrelic.com/docs/change-tracking/change-tracking-introduction/