DB 형상관리를 위해 어떤 tool을 도입하여 어떻게 설계하면 될것인지에 대해
고민한 과정들을 기록합니다.
1탄 을 참고해주세요!

---

예상 시나리오

mamba 서비스에서 db 테이블을 수정하기 위해 칼럼을 추가하는 V001_add_colunm.sql 파일을 작성했다.

mamba의 git repository에 push 한다.

gitlab CI/CD 배포 과정에서 Flyway를 실행시켜 V001_add_colunm.sql 파일 내용인 add_column이 적용되도록 한다.

또한 배포 파이프라인에 .sql 파일만 추출하여 sql파일 저장소(git repo)로 push(저장) 되도록 한다.

각 프로젝트에서 DB를 수정하기 위한 .sql 파일을 작성하여 배포할때마다 sql파일들이 하나의 저장소에 모여 저장된다.

프로젝트 시작 전, 우리는 브랜치를 업데이트 시키기 위해 git pull 명령어를 수행한다.

그때, 코드를 최신화 하듯 최신까지 업데이트 된 .sql파일을 모두 다운받아 DB 변경 버전 history의 싱크를 맞추게 한다.

git pull or git update 명령어 실행 시, sql파일 저장소인 repository에서 모든 sql파일도 프로젝트로 다운되도록 hook을 설정해 놓는다.

즉, 프로젝트 개발 시작을 위해 업데이트 할 때, mamba프로젝트에서 작성했던 V001_add_colunm.sql 파일이 nutria로 다운로드 된다.

nutria 서비스에서 DB에 새로운 테이블을 만들고자 V002_create_table.sql 파일을 작성했다.

nutria repository에 push 하여 배포되면서, 앞서 말했던 mamba의 과정과 동일하게 DB 변경사항(create_table)이 적용되고, .sql 파일은 sql파일 저장소로 push된다.

sql파일 저장소는 DB변경이 될때마다 버전별로 sql파일이 차곡차곡 저장되어가게 될 것이다.

또 다른 프로젝트에서 프로젝트를 시작할 때, hook을 통해 sql파일 저장소에서 .sql 파일들이 다운되어 싱크가 맞춰지게 되고….(반복)

이런 과정으로 각기 다른 프로젝트에서 한개의 DB를 변경할때, DB history(sql파일)를 공유하기 때문에 각 프로젝트에서 DB를 변경할 수 있다.

배포할때, Flyway image를 pull 받아서 쓰려했는데 docker 로그인이 필요하다고 떴다.

개인 계정을 로그인 시키기엔 위험요소가 있어서 ecr에 flyway image를 등록해놓고

배포 시, ecr 주소에서 pull하도록 한다.