- Prod - developer.mozilla.org
- Stage - developer.allizom.org
- Dev(s) - [main].content.dev.mdn.mozit.cloud
Prod and stage are supposed to be as similar as possible.
All environments are as separate from each other as possible.
You can manually trigger a build for any environment (using the GitHub UI) but only prod and stage build on a cron job.
We will try to commit to maintaining the (public) details for each environment in this spreadsheet.
But the best source of details are in viewing the 3 GitHub Action workflows:
prod-build.yml
stage-build.yml
dev-build.yml
Note! Yes, these files are very similar in various tricks and techniques are blatantly repeated across all three files. But the benefit is that it keeps things simple for the benefit of security.
The stage environment is updated most frequently. Use it for quality assurance testing.
Unlike dev, the stage environment is actually connected to a real database (the Kuma stage environment).
Use this environment when you can't wait for the cron schedule for stage, or if you want to try out a specific (git) branch.
The default deployment prefix is main
which is the first word in the domain
name: main.content.dev.mdn.mozit.cloud
. But you can deploy to the dev
environment with a custom prefix. E.g. web-perf-experiment123
and then the URL
becomes: web-perf-experiment123.content.dev.mdn.mozit.cloud
.
The biggest difference between dev compared to prod & stage, is that the backend API is faked in dev. This includes the ability to sign in. Also, in prod & stage, the CDN (AWS CloudFront) is configured to fall back to Kuma to render what can't be rendered as a static asset.
These URLs give you a comparison between what's the main
(for Yari) and main
(for Content) in the git repo, compared to what's made it into each deployment
environment. This helps to answer "Has my change gone live yet?"