Skip to content

Instantly share code, notes, and snippets.

@huntie
Last active July 1, 2020 09:43
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save huntie/17761448a28a5d71e0da377afecec770 to your computer and use it in GitHub Desktop.
Save huntie/17761448a28a5d71e0da377afecec770 to your computer and use it in GitHub Desktop.
Notes outlining concepts for scoping and referring to environments in cloud applications. To accurately answer, "What is an environment?".

AWS environment concepts

Notes outlining concepts for scoping and referring to environments in cloud applications. To accurately answer, "What is an environment?".

Environment type

e.g. dev or prod

The application environment classification. This defines what external environments/services the app should be configured against, and therefore the people and resources who should have access.

dev and prod should be sufficient for most setups. For variant deployed environments, you should create deployment stages with feature flags.

It is ALWAYS worth being explicit about the environment type when naming a resource, even if these are split across dedicated accounts.

Deployment stage

e.g. prod, prod-alpha, staging, or dev-1

A deployment stage is the label for a deployed resource. This includes the environment type and a purpose - this may align to concepts like a source branch or an intended set of users. Colloquially, this is the "environment name".

Used with Serverless Framework's --stage option, all created resources will be labelled with the deployment stage following the service name. For example: users-api-dev-1-myFunction.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment