Continuous Integration

Sentry uses a variety of continuous integration services to help ensure we don't accidentally break the application.

GitHub Actions

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

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-backend or getsentry-frontend, whichever is relevant to your changes
• Select the environment. It should be "production" for regular production deploys
• Select the ref. Using master is 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.

Docker images

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:<sha>, getsentry/sentry:<short_sha>, or getsentry/sentry:latest to pull from a commit in getsentry/sentry master
• us.gcr.io/sentryio/sentry:<sha> to pull from a commit in any other branch or PR

CI workflow for testing changes with getsentry

See Workflow.

Troubleshooting CI

You might also be interested in troubleshooting the dev environment.

Problem:

When pushing your build to staging and you it fails the Ensure test image step on Travis.

Solution:

You probably forgot to push your branch on Sentry to GitHub.

Old Systems

For historical reference, we used to use Travis and Percy which have been replaced by GitHub actions and a GitHub action respectively.