As a developer of Notify, I want to be able to dynamically deploy the notify terragrunt infrastructure. If an s3 bucket is deleted, there is a considerable lag time (up to 1 hour) before that s3 bucket can be recreated. We should add a random prefix/postfix to the s3 bucket name to get around this issue.
WHY are we building?
It is important to be able to deploy dynamic environments for both BCP as well as better integration testing.
WHAT are we building?
Modify terragrunt.hcl to accept a variable for the remote_state name, migrate existing remote state names to environment var file.
VALUE created by our solution
We will be able to create new notify infrastructure environments very quickly, and at will.
Acceptance Criteria
Given some context, when (X) action occurs, then (Y) outcome is achieved.
[ ] Create a new environment without receiving s3 bucket errors
[ ] Existing environment remote states are moved to tfvars.
QA Steps
[ ] Create new environment
[ ] Destroy environment
[ ] Create environment again
[ ] Verify that production and staging are not affected by the reorg
Description
As a developer of Notify, I want to be able to dynamically deploy the notify terragrunt infrastructure. If an s3 bucket is deleted, there is a considerable lag time (up to 1 hour) before that s3 bucket can be recreated. We should add a random prefix/postfix to the s3 bucket name to get around this issue.
WHY are we building?
It is important to be able to deploy dynamic environments for both BCP as well as better integration testing.
WHAT are we building?
Modify terragrunt.hcl to accept a variable for the remote_state name, migrate existing remote state names to environment var file.
VALUE created by our solution
We will be able to create new notify infrastructure environments very quickly, and at will.
Acceptance Criteria
Given some context, when (X) action occurs, then (Y) outcome is achieved.
QA Steps