- should RAILS_ENV == DD_ENV
- should DD_ENV == NAMESPACE_STAGE
how do we make these decisions?
- lower level deployed heroku apps use 'staging' as RAILS_ENV.
- prod uses 'production' as RAILS_ENV
- the namespace stage is either
PRODUCTION, DEVELOPMENT or STAGING depending on the deployment account;
| Account |
Namespace Stage |
Deployment Environments |
ftf-radix-production |
PRODUCTION |
radix-prod, environments w/ prod data |
ftf-radix-staging |
STAGING |
radix-stg, and PR/review environments |
ftf-radix-development |
DEVELOPMENT |
radix-dev, and sandbox environments |
- We are setting default values. RAILS_ENV, DD_ENV, &c can be explicitly provided per deployment environment.
- We can add additional NAMESPACE_STAGES. these could align w/ AMPLIFY_STAGES, currently;
PRODUCTION, BETA, DEVELOPMENT, EXPERIMENTAL, PULL_REQUEST
- local rails development currently uses RAILS_ENV=development
- We base
RAILS_ENV on the namespace stage
| NAMESPACE_STAGE |
RAILS_ENV |
| PRODUCTION |
production |
| DEVELOPMENT |
development |
| STAGING |
staging |
thus RAILS_ENV=development remains for local development (in docker compose). TODO: is this what we want? is local dev (docker compose) set to "development" in other rails services? what is community standard?
- We set
DD_ENV to Environment tag, aka terraform.workspace
| WORKSPACE |
DD_ENV |
| prod |
prod |
| dev |
dev |
| sandbox |
sandbox |
- Pull request / review / qa environments will be given the
STAGING namespace stage, and thus staging RAILS_ENV.
| Deployment ID |
NAMESPACE_STAGE |
RAILS_ENV |
DD_ENV |
| radix-prod |
PRODUCTION |
production |
prod |
| radix-stg |
STAGING |
staging |
stg |
| radix-dev |
DEVELOPMENT |
development |
dev |
| radix-sandbox |
DEVELOPMENT |
development |
sandbox |
| radix-pr-73 |
STAGING |
staging |
pr-73 |
(local development would continue to use development as RAILS_ENV)
After speaking w/ @Erika-Barr-FTF there's a few alternative proposals;
align everything 1:1
this requires making changes to our namespace stages to better match RAILS_ENV. We would replace 'DEVELOPMENT' with 'STAGING'
avoid test environment
if we can't use RAILS_ENV=test in any of our deployed ("remote", "AWS", "heroku") environments, then we will set RAILS_ENV to 'staging' in all deployed environments lower than production.
💭 This has the adverse effect of limiting the ability to toggle "QA" like behavior in lower level environments (like review environments and sandboxes) through the RAILS_ENV environment variable.