Best Practices - Next JS Vercel Deployements with Supabase
Currently I'm thinking of having 3 environments, vercel has the idea of preview, staging, production:
1. app-preview (used for localhost development & vercel preview builds)
2. app-staging (main branch)
3. app-production (production branch)
Does this developer lifecycle make sense?
1. make necessary database changes on localhost / docker
2. create preview pr -> open pr instantly triggers deploy to preview db
3. merge database pr -> triggers deploy to staging db
4. build application logic making use of the database change
5. create pr.....merge... deploy
Questions: (First time managing SQL DB from scratch)
1. Does it make sense to even deploy preview changes on PR open? I notice the migration files can get pretty messy if you accidentally make a mistake. create table -> drop table -> create table.
2. Is it common to have 100s or 1000s of migration files?
3. Is anyone already doing this? Any tips of tricks for connecting supabase to vercel deployments?
1. app-preview (used for localhost development & vercel preview builds)
2. app-staging (main branch)
3. app-production (production branch)
Does this developer lifecycle make sense?
1. make necessary database changes on localhost / docker
2. create preview pr -> open pr instantly triggers deploy to preview db
3. merge database pr -> triggers deploy to staging db
4. build application logic making use of the database change
5. create pr.....merge... deploy
Questions: (First time managing SQL DB from scratch)
1. Does it make sense to even deploy preview changes on PR open? I notice the migration files can get pretty messy if you accidentally make a mistake. create table -> drop table -> create table.
2. Is it common to have 100s or 1000s of migration files?
3. Is anyone already doing this? Any tips of tricks for connecting supabase to vercel deployments?
