Aligning RAILS_ENV, DD_ENV, Amplify Stage, Namespace Stage in AWS Deployments

README.md

Questions

• should RAILS_ENV == DD_ENV
• should DD_ENV == NAMESPACE_STAGE

how do we make these decisions?

current environment

• 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

considertations

• 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

Recommendation

1. 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?

2. We set DD_ENV to Environment tag, aka terraform.workspace

WORKSPACE	DD_ENV
prod	prod
dev	dev
sandbox	sandbox

3. Pull request / review / qa environments will be given the STAGING namespace stage, and thus staging RAILS_ENV.

Examples

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'

Deployment ID	NAMESPACE_STAGE	RAILS_ENV	DD_ENV
radix-prod	PRODUCTION	production	PRODUCTION
radix-dev	STAGING	staging	STAGING
radix-stg	STAGING	staging	STAGING
radix-sandbox	TEST	test	TEST
radix-pr-73	TEST	test	TEST

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.

Deployment ID	NAMESPACE_STAGE	RAILS_ENV	DD_ENV
radix-prod	PRODUCTION	production	PRODUCTION
radix-dev-staging	DEVELOPMENT	staging	DEVELOPMENT
radix-stg	DEVELOPMENT	staging	DEVELOPMENT
radix-sandbox	TEST	staging	TEST
radix-pr-73	TEST	staging	TEST

My vote is align 1:1

@taylor-kems TY for the feedback and I agree. To help facilitate this I've alligned all of our aws account tiers accordingly. They were previously prod, sdlc, and sandbox... and they are now production, staging, and development. E.g.

ftf-radix-production (radix-prod, environments w/ prod data)
ftf-radix-staging (radix-stg, and PR/review environments)
ftf-radix-development (radix-dev, and sandbox environments)

I am not sure we're setup to use RAILS_ENV=development in a deployed (to AWS ECS) environment... and may need to consider using the RAILS_ENV=test or fixing development so it can be used outside of local. Not sure what best option is. /cc @Erika-Barr-FTF @darlan-ftf

updated the base gist to reflect the ^^^ realignment

😍