- 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)
updated the base gist to reflect the ^^^ realignment