As a developer/operator of GC Notify I would like our dev environment to be refreshed every week so that we always have a new environment on Monday, and we can test our environment recovery scenarios.
WHY are we building?
This will ensure that Dev is not in a constant state of mess, and it will provide QA to our Terraform release where we will be able to quickly identify if there are breaking changes to Terraform.
WHAT are we building?
Automate the TF that will create the infrastructure resources
Create a github action that re-apply's the kustomize and helmfile code every Sunday night
Make sure snapshot is enabled and used in next step
Automate the database snapshot restoration (Requires investigation)
Document each of these scenarios
VALUE created by our solution
Increased BCP readiness
Increased development velocity
Potentially reduced cost in the dev environment (the system can be destroyed on weekends)
Acceptance Criteria
[ ] The dev environment is automatically created weekly + 1
[ ] The database restore is automated
[ ] The newly created dev environment "just works" (exclude QuickSight)
[ ] We can identify the cost of running/maintaining this process
Red Flags
[ ] Automation of the dumping of the database will require a large amount of storage, and where do we put that?
[ ] How are we going to handle steps that require Amazon!?
[ ] Quicksight in general
[ ] AWS is very finicky when it comes to TF destruction and application, need to get ahead of these
[ ] May need to descope some things for dev to consider the process healthy, without some functionality
QA Steps
[ ] The new environment functionality is tested by another developer who didn't work on this.
[ ] The UI tests are ran against the new environment.
[ ] The smoke tests are ran against the new environment.
[ ] The performance tests are ran against the new environment.
Description
As a developer/operator of GC Notify I would like our dev environment to be refreshed every week so that we always have a new environment on Monday, and we can test our environment recovery scenarios.
WHY are we building?
This will ensure that Dev is not in a constant state of mess, and it will provide QA to our Terraform release where we will be able to quickly identify if there are breaking changes to Terraform.
WHAT are we building?
VALUE created by our solution
Acceptance Criteria
Red Flags
QA Steps