지금 운영으로 배포하기 전에 계속해서 수동으로
> supabase link --project-ref [운영DB]
> supabase migration list
> supabase db push
> supabase link --project-ref [개발DB]
이 작업을 해줘야 하는데 너무 귀찮았고, 사람인지라 실수로 DB는 반영 안 하고 코드만 반영해서 운영 쪽에서 에러가 날 수 있을 것 같았다.
그래서 운영 배포 시 자동으로 migration을 반영해 주도록 GitHub Actions를 이용하기로 했다.
현재 프론트엔드는 Vercel 플랫폼을 통해 배포하고 있다. 그래서 DB 마이그레이션이 먼저 성공한 뒤에 프론트 배포가 이어지도록 순서를 보장해 주는 게 좋다. 이 흐름으로 가져가려면 Vercel의 Git 연동 자동 배포는 꺼두는 편이 낫다.

Vercel 해당 프로젝트에서 Settings -> Build and Deployment -> Ignored Build Step으로 들어가서 Don't build anything으로 설정해 주자.
그러면 GitHub에 push를 하거나 PR을 올려도 Vercel이 연결된 Git 기준으로 자동 빌드를 실행하지 않게 된다. 다만 이 설정은 “자동 빌드를 막는 것”에 가깝고, Vercel과 Git 연동 자체가 완전히 사라지는 것은 아니다.
그런 후 deploy.yml을 아래처럼 작성해 준다.
Supabase CLI 버전은 혹시 모를 상황을 대비해 현재 로컬에 깔려 있는 버전과 통일시켰다.
Link Supabase project 단계에서 운영 DB로 연결해 주고,
Push DB migrations 단계에서 운영 DB에 작업 내용을 반영해 준다.
그리고 Vercel 자동 배포는 꺼놨으므로 Deploy to Vercel 단계에서 배포를 진행해 준다.
name: Deploy
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Supabase CLI
uses: supabase/setup-cli@v1
with:
version: 2.78.1
- name: Link Supabase project
run: supabase link --project-ref ${{ secrets.SUPABASE_PROJECT_ID }}
env:
SUPABASE_ACCESS_TOKEN: ${{ secrets.SUPABASE_ACCESS_TOKEN }}
- name: Push DB migrations
run: supabase db push
env:
SUPABASE_ACCESS_TOKEN: ${{ secrets.SUPABASE_ACCESS_TOKEN }}
- name: Deploy to Vercel
run: npx vercel --prod --token=${{ secrets.VERCEL_TOKEN }} --yes
env:
VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}
이제 귀찮게 추가된 migration 파일이 있을 때마다 확인해서 운영쪽에 직접 반영해주지 않아도 된다.
운영 배포를 하면 GitHub Actions가 migration 반영부터 Vercel 배포까지 순서대로 처리해 주기 때문이다.
덕분에 DB는 반영되지 않았는데 코드만 먼저 반영돼서 운영에서 에러가 나는 상황도 방지할 수 있게 됐다.