Ephemeral Environments

• Temporary deployments that have self-contained versions of your application, generally every feature branch

How do databases work in ephemeral environments?

• Prepopulated data - it contains representative, anonymized data - to pass security audits, all Personally-Identifiable Information must be scrubbed from databases to be used in such envs

• Undoable - if data is deleted or modified, it should be easy to reset the database to its original state

• Migrated - Database uses the schema currently used in PROD and has proposed migrations run against it

  • On of the most common cases of problems uncovered by ephemeral environments are broken or non-preformat database migrations

Ephemeral environments lifecycle management:

• Option A: tie the lifecycle to the life of a pull request or merge request

• Option B: Create a ChatOps bot that allows creating a new environment for a specific branch with a small timeout

• Option C: Create an ephemeral environment for every commit, and hibernate them the second they are provisioned, then wake them up as they are required

DYI ephemeral environments:

• Budget 6-12 months of engineering time for setup, then dedicated person for managing these envs

• Will need clould service provider

• Create slackbot that responds to /env-create-for-mybrach <link>