Should staging use a db reset or be treated like production?
Hey guys, I need some assistance with how I should use a staging environment.
My plan was to have a
supabase db reset in my staging environments gh action file, so each time I push something I get a fresh staging env with all the migrations and seed data (seed.sql + Python script for images in buckets).
But this is giving me some trouble because, contrary to what happens locally (supabase db reset also cleans up all the buckets), the buckets in staging stay where they are. That means I’d have to clean them up manually after each push, or my GH Action will fail when trying to recreate a bucket (buckets are created as DB entries and thus are part of the migrations).
Now my question is: is my mental model of the staging environment wrong, and should I treat it more like a production environment? Meaning only new migrations are applied and staging can’t roll back. Once a migration is applied, I’d need to create another migration to revert unwanted changes, and change supabase db reset to supabase db push.2 Replies
Staging is treated as a production environment without sensitive data or real user's data. So it should not be reset. You only reset QA (if you have a QA branch) and development.
Okay thanks, I will do that!