[Supabase] 마이그레이션 & 배포 자동화

 

일단 하면서 발전하는거지.

 

 

앱 첫 출시후 테스트 환경이 필요하다는걸 깨달았다. 테스트 데이터를 추가시키거나 백엔드 설정을 바꾸는 등 다음 버전 개발을 위한 테스트를 실제 유저가 사용하고 있는 환경에서 할 수는 없어서 테스트 환경과 프로덕션 환경을 분리시키기로 하였다. 사실 처음부터 생각을 했어야 됐는데 놓친것 같다. 이제라도 알면 됐지 뭐..

 

 

1. Supabase 테스트 프로젝트 생성

일단 서치를 한 바로는 로컬에서 서버를 생성하여 테스트 시에는 로컬 서버로 연결을 하고 배포 후에 클라우드 서버에 연결을 하는 방법과 프로젝트를 두개를 만들어서 테스트와 프로덕션 환경을 분리하는 방법이 있는것 같았다. 일단 전자의 경우 트래픽이 잡히지 않아서 마음껏 테스트를 해볼수 있고 후자의 경우는 GUI를 통해 개발을 편하게 해볼수 있다는 장점이 있었다. 나는 후자를 선택하였는데 아무래도 개발 어린이라 그런지 GUI 가 있는게 더 편할것 같았다. 또한 어차피 테스트 할때에는 egress나 storage 를 그렇게 많이 차지 하지는 않을것 같아서 무료 플랜을 사용 하면 될것 같았다.

 

2. Github Repository 연결

 

1.  Supabse CLI 를 설치한다. 없으면 brew로 다운받아야 한다.

# supabase CLI 설정
brew install supabase/tap/supabase

# Linux
curl -fsSL https://cli.supabase.com/install/linux | sh

# Windows (using Scoop)
scoop install supabase

 

 

2.  Supabase 프로덕션 프로젝트 로컬로 받아오기

# pull 받아올 폴더로 이동
cd backend
 
# supabase 로그인
supabase login
 
# 현재 디렉토리에 프로젝트 초기화
supabase init 
 
# Supabase 프로젝트와 연결
supabase link --project-ref <your-project-ref>

# db 받아오기
supabase db pull

 

 만약 Make sure your local git repo is up-to-date. 이런 에러가 나온다면 로컬과 원격 데이터베이스 간의 마이그레이션 이력이 일치하지 않거나, 로컬에 데이터베이스 설정 파일이 완전하지 않기 때문이다. 아래 명령어로 마이그레이션 상태를 복구해준다.

# Supabase CLI에서 마이그레이션 상태를 복구
supabase migration repair --status reverted 20241130000000

 

 

3. 연결하고 싶은 레포로 연결 후 메인 브랜치에 push한다.

git init
git remote add origin <github-repo-url>
git add .
git commit -m "Initial commit"
git branch -M main   
git push -u origin main

 

 

 

3. Github Actions를 이용한 배포 자동화

GitHub Actions 란?

Github가 공식적으로 제공하는 빌드, 테스트 및 배포 파이프라인을 자동화할 수 있는 CI/CD 플랫폼

repository에서 PR이나 push 같은 이벤트(event)를 트리거(trigger)로 github 작업 workflow를 구성할 수 있다. workflow는 하나 이상의 작업이 실행되는 자동화 프로세스로, 각 작업은 자체 가상 머신 또는 컨테이너 내부에서 실행된다.
workflow는 yml파일에 의해 구성되며, 테스트, 배포 등 기능에 따라 여러 개의 workflow도 만들 수 있다. 생성된 workflow는 .github/workflows 디렉토리 이하에 위치한다.

설정 파일(.yml)에 명시된 main branch로의 push를 trigger로 Github Actions가 실행되도록 구성한다.

 

 Github Actions를 사용하여 배포 자동화를 설정 한다. 아래 영상을 보면 자세히 알려준다.
https://www.youtube.com/watch?v=rOLyOsBR1Uc&t=3s

 

 

1.github/workflows 폴더 생성후 해당 폴더에 main.yaml 파일을 만들고 아래와 같이 작성한다.

name: Release (Production)

on:
  push:
    branches:
      - main
  workflow_dispatch:

jobs:
  release:
    runs-on: ubuntu-latest
    env:
      SUPABASE_ACCESS_TOKEN: ${{ secrets.SUPABASE_ACCESS_TOKEN }}
      SUPABASE_DB_PASSWORD: ${{ secrets.PRODUCTION_DB_PASSWORD }}
      SUPABASE_PROJECT_ID: ${{ secrets.PRODUCTION_PROJECT_ID }}

    steps:
      - uses: actions/checkout@v4
      - uses: supabase/setup-cli@v1
        with:
          version: latest

      - run: supabase link --project-ref $SUPABASE_PROJECT_ID
      - run: supabase db push

 

 

2. 해당 레포에 Actions secrets를 생성한다. 

 

 

3. 변경사항을 메인 브랜치에 머지하면 워크 플로우에 이런식으로 나온다. 그러면 github actions를 사용한 배포 자동화가 된것이다.

 

 

 

3. 테스트 환경  변경사항 마이그레이션

마지막으로 supabase db diff를 사용하여 두 데이터베이스 간의 차이를 비교하고 마이그레이션 파일을 생성한다.
테스트 데이터베이스(test-db-url)와 로컬의 현재 스키마 간의 차이점을 비교하고, 그 차이를 새로운 마이그레이션 파일로 저장하는 방법이다. 

중요한 점은 이건 스키마의 차이만 가져오기 때문에 만약 데이터 베이스의 데이터나 스토리지나 edge function, RLS (Row-Level Security) 규칙 변경 등은 따로 처리를 해줘야한다. 또한 Supabase Realtime 설정 변경은 supabase db diff로 자동으로 추적되지 않기 때문에 변경을 수동으로 관리해야 한다고 한다.

 

 

1. 마이그레이션 파일 생성

#db-url <test-db-url>: 비교할 test 데이터베이스의 연결 URL.
#file <migration-name>.sql: 생성할 마이그레이션 파일의 이름. 예: 20241128_add_column.sql.
supabase db diff --db-url <test-db-url> --file <migration-name>.sql

 

다른 방법이지만 이런식으로 는 스키마를 dump한뒤 생성된 마이그레이션 파일을 밀어 넣어주는 방법도 있다. (아래 블로그 참고)

https://chaechae.life/blog/supabase-cli-migration

Supabase CLI활용 - Supabase CLI로 migration하기

 

참고로 edge function은 이런식으로 하나하나 따로 가져와야 한다.

#<function-name>: 가져오려는 함수의 이름.
#<project-ref>: 프로젝트의 참조 ID (예: abcd1234).
supabase functions pull <function-name> --project-ref <project-ref>

 

 

2. 변경사항을 마찬가지로 push 하고 메인 브랜치에 머지하면 자동으로 변경사항이 프로덕션 환경으로 자동 배포가 된다.

 

 

 

끝으로

홀로 프로젝트를 하면서 여러 플로우를 경험할 수 있어서 좋다는걸 몸소 느끼게 되었다. 물론 다른 사람들과 여러 개발 지식을 공유하면서 발전하는 것도 좋지만 혼자 할 경우 다른 방면으로 발전을 할 수 있는것 같다. 새로운 도전을 할 수 있어서 뿌듯했다.