We can leverage @dleard 's helm chart to test backups to run this when deploying to -test.
Here's a playbook of how this could be done:
1) Use the test-backups chart to restore the latest prod backups from GCP in a sandbox namespace (tools or others)
2) Run a job testing the upcoming migrations on that restored cluster
3) Clean up everything in that namespace
4) Carry on with the deploy to -test
Acceptance Criteria
[ ] Any deployment to -test (release, hotfix or other) runs that playbook
[ ] Any failure cleans up the database cluster used to test (to not leave prod data around accidentally) and alerts developers (airflow?)
Additional context
Prod data should at all times be isolated and manipulated by internal tools
@dleard and @pbastia I forgot to ask about this one in refinement today. Do we need any further discussion to refine this? I'd like to bring this in next sprint if possible.
Describe the task
We can leverage @dleard 's helm chart to test backups to run this when deploying to -test. Here's a playbook of how this could be done: 1) Use the test-backups chart to restore the latest prod backups from GCP in a sandbox namespace (tools or others) 2) Run a job testing the upcoming migrations on that restored cluster 3) Clean up everything in that namespace 4) Carry on with the deploy to -test
Acceptance Criteria
Additional context