Sentry uses a variety of continuous integration services to help ensure we don't accidentally break the application.
GitHub actions is our primary CI system and runs our tests on every pull request and on merges to master. It is required that tests pass before changes can be merged.
Freight is how we deploy our applications to staging & production.
Deploying to Production
To deploy to production using Freight, follow these steps:
- Click the "Deploy" button in the top right
- Select the application using the dropdown. To deploy changes to Sentry select either
getsentry-frontend, whichever is relevant to your changes
- Select the environment. It should be "production" for regular production deploys
- Select the ref. Using
masteris usually right, but you can also opt to deploy a specific commit
- Freight will show you the list of undeployed commits. At this point you may choose to deploy an earlier commit rather than
master. If so, update the ref to the commit SHA
- If all looks well, click "Ship It!"
- Wait for the deploy to finish
Reverting / Rolling Back After a Bad Deploy
If you've deployed something bad, you'll need to do the following:
- Immediately deploy the most recently known good commit using Freight. Under "Deploy History" click the release you want to roll back to, and click "Re-deploy" in the bottom right
- Lock Freight deploys by clicking the "Lock Deploys" button in the top right
- Inform #team-engineering that you're rolling back a bad deploy, and that no one should deploy getsentry master until the issue is resolved.
- Keep an eye on the deploy, as deploys MUST finish, otherwise it's possible some web machines will still be stuck on the bad deploy's code.
- Fix the issue, and get it merged into master.
- Unlock Freight deploys
- Deploy the fix, and verify that the issue has indeed been fixed.
- Inform #team-engineering that it is safe to deploy getsentry again.
We use Google Cloud Build to build our Docker containers. Every single commit (including from PRs) gets built, tested and becomes available at
us.gcr.io/sentryio/sentry:<sha> with no retention guarantees. Every push to
master gets built, tested and pushed to Docker Hub permanently. You can set
SENTRY_IMAGE to the following, when working with getsentry/self-hosted:
getsentry/sentry:latestto pull from a commit in getsentry/sentry
us.gcr.io/sentryio/sentry:<sha>to pull from a commit in any other branch or PR
CI workflow for testing changes with getsentry
You might also be interested in troubleshooting the dev environment.
When pushing your build to staging and you it fails the
Ensure test image step on Travis.
You probably forgot to push your branch on Sentry to GitHub.
For historical reference, we used to use Travis and Percy which have been replaced by GitHub actions and a GitHub action respectively.