Deployment tracking is the practice of notifying your error monitoring tool every time you release code, so each error can be attributed to the release that introduced it. Without it, an error feed tells you what is broken but not which change broke it.
The unit of attribution is normally a git SHA. You send it at deploy time, and errors that arrive afterward line up against it.
Example
curl https://api.rollbar.com/api/1/deploy \
-H "X-Rollbar-Access-Token: $ROLLBAR_SERVER_TOKEN" \
-F environment=production \
-F revision=$(git rev-parse HEAD) \
-F local_username="$USER"
Run that as the last step of the pipeline and the deploy is on the record before the first error of the new release arrives.
What Rollbar does with deploys
Rollbar identifies a suspect deploy for each error: the last deploy before the error first occurred, or the last deploy before it reactivated if the item had been resolved. Rollbar shows deploys inline in the live item feed, so a cluster of new items sitting directly after a release is visible without running a query. Rollbar can also auto-resolve every active item on deploy, which turns whatever reappears next into a statement about the release you just shipped.
Rollbar does not detect deploys on its own. Your CI or CD tool has to call the deploy endpoint, which requires environment and revision and accepts an optional status of started, succeeded, failed, or timed_out. A deploy left at started is set to timed_out after the project’s timeout period, 60 minutes by default.
Deployment frequency and failed deployment recovery time are two of DORA’s five software delivery metrics, and neither is measurable if nothing records when a deploy happened.
Related terms
Read the deployment tracking docs.
Sources
- Rollbar Docs, Deploy Tracking: https://docs.rollbar.com/docs/deploy-tracking
- Rollbar API Reference, Report a deploy: https://docs.rollbar.com/reference/post-deploy
- DORA, DORA’s software delivery performance metrics: https://dora.dev/guides/dora-metrics-four-keys/
