Announcing a New GitHub Action: Bring Observability Data Directly into GitHub with Lightstep’s Pre-Deploy Check
by Fran Thorpe
In a world where minutes of downtime can cost millions of dollars, developers are frustrated by multitudes of unknowns that come with deploying new code. With the release of our new GitHub Action, the Lightstep Pre-Deploy Check, developers can be proactive about ensuring the quality and performance of their software before it’s actually deployed. Designed specifically to help developers regain control over the performance and reliability of their code, the Lightstep Pre-Deploy Check, completes a risk assessment and delivers an understanding of entire system health within their service Pull Request, so developers can avoid deploys that are going to run into problems — even before code is merged.
Despite merging more than 87M+ PRs last year to date, there has been zero visibility into the health status of a system within a pull request itself. Pull requests are increasingly being used for surfacing insights about changes to software, including code quality checks and security testing. Yet developers are merging their approved code without visibility within a pull request into the health status of the system their service depends on. They have to rely on red or green alerts, or updates and messages in other monitoring products. And they do not have a consolidated view of the services and owners that their service connects to. The result is time wasted with poor experience, rollbacks, and troubleshooting after the PR is merged and deployed.
By automatically bringing relevant observability data directly into the development workflow, The Lightstep Pre-Deploy Check provides a context-rich view of the health of the whole system — related services, service ownership, latest error status — before code is merged, and inside a pull request. Developers can now understand the state of production before merges and deploys happen without having to switch between multiple screens. And after they merge their code, developers have ready access to details they need to troubleshoot in the event that something does go wrong.
With call stack tracing, Rollbar automates the process of surfacing and triaging new and critical errors. Once the error is identified, Rollbar provides actionable insights as next steps for engineering teams. The latest example is the integration with Lightstep, enabling a developer to move seamlessly from a critical error alert in Rollbar, to a deep-dive root cause discovery exercise.
When the Rollbar Versions feature is enabled, errors are collected for a service instrumented in Lightstep and available via a link in the Pre-Deploy Check details. The Lightstep action checks for new errors since the last deploy, and connects the Rollbar UI from the GitHub PR via a link in the Pre-Deploy Check details.
Since 2018, Lightstep has partnered with PagerDuty to ensure developers and engineering teams can move quickly to understand and determine the root cause, typically associated with software issues running in production. Both alert and observability context can also provide relevant insights just before developers make an important code change to a production system.
For example: A service owner working in GitHub is about to merge a pull request that has passed code checks and code reviews. Currently, they don’t have access to product health context or necessarily know who is on call and responsible for the service in production. For Lightstep and PagerDuty, this provides an opportunity to answer “Is the code ready to deploy?”
Automatically surfacing complementary data from Lightstep and PagerDuty, just before a merge is initiated helps teams ship more quickly and reliably. Developers gain additional context: who owns which service, information about the on-call team, and even an immediate view of system health and performance via a Lightstep Snapshot.
In the words of Steve Gross, Sr. Director, Strategic Ecosystem Development at Pagerduty: “Now developers automatically have PagerDuty on-call details inside of a pull request, alongside system health details, at their fingertips in one screen.”