Part three in a series about how to deploy a secured, monitored, optimized web application (short bonus part)
One of the most important things a software need, not just a web application, is the ability to log all the events and errors that occur when it's being used by our end users so we can actually see what went wrong and fix it before the user even finish the email to the support team.
This part will introduce how to utilize Sentry, the SaaS based logging service that provide real time error monitoring, tons of SDK's for every major language and framework out there, and what's important for us is the ability to integrate with our Git to see the errors per version/code change.
Prerequisites
A few things we'll need to get started is of course a Sentry account, our amplify.yml from the first post and an application we want to use it with.
Once the sentry account is up and you added the appropriate SDK to your application (this part is out of the scope for this post) we can add it to our pipeline that will generate source-maps to actually point to our original code before it's compilation/bundling/uglification/etcification took place.
Integrate It!
Most application will initialize Sentry in the following manner:
Sentry.init({
dsn: "https://XXXXXXXXXXXXXXXXXXXXXXX@sentry.io/XXXXXX",
release: <% COMMIT_HASH %>
});
The <% COMMIT_HASH %> is what we will replace pre-building our application so Sentry can point to the specific commit that added the changes either breaking or fixing an issue.
In the amplify.yml file at the preBuild stage on my project (this change depending on the software you are building) I call a script I built to change all the environment variables during CI. replacing <% COMMIT_HASH %> with AWS_COMMIT_ID.
Mapping
To upload the relevant source maps we will have to define a few environment variables at the Amplify console, SENTRY_AUTH_TOKEN, SENTRY_ORG and SENTRY_PROJECT.
Afterwards we can add to our amplify.yml in the postBuild step the following lines
- npx sentry-cli releases new AWS_COMMIT_ID
- npx sentry-cli releases set-commits --auto AWS_COMMIT_ID
- npx sentry-cli releases files AWS_COMMIT_ID upload-sourcemaps path/to/source-maps -x .js -x .map --validate --verbose --rewrite --strip-common-prefix
- npx sentry-cli releases finalize AWS_COMMIT_ID
which is pretty self explanatory, once a build is successful you should see in your sentry dashboard a new release and when an error is logged now and it's associated to the release it will pinpoint the code that changed or fixed that error which is pretty amazing if you ask me.
Hope you enjoyed this short bonus part, in the following post I'll introduce another great tool to help with visual regression snapshots.
Top comments (4)
Not quite understand this part:
How can it be set exactly in JS/next.js projects?
Yes good question, the author hasn't mentioned the templating system they're using here or how they've put exposed commit hash as an environment variable.
But for most JS/Next.js projects to use environment variables would use
process.envlike so:Or, because this would be directly exposed to the client-side (i.e. public), like this with Next.js:
Reference: nextjs.org/docs/basic-features/env...
Note that the Amplify build environment exposes the git commit hash for you by default. So if you need use that env var locally, you'll need to get the actual git commit hash, and then expose it as an env var yourself (for consistency perhaps), which is another story... e.g. javascript.plainenglish.io/passing...
Thanks so much for this! Might be worth adding that the following env variables should be set in the amplify console:
SENTRY_AUTH_TOKEN
SENTRY_ORG
SENTRY_PROJECT
True 👆