기존에 사용하던 DB에서의 Flyway 도입기

사이드 프로젝트를 시작한지 어언 9개월.. 오랜만에 포스팅을 한다.

다들 직장과 병행하면서 진행하는거라 진척도가 빠르지 않지만,

이탈없이 꾸준히 참여해주시는 것만 해도 찬사를 보내고 싶다.

 

아무튼 이제 슬-슬 배포사이클을 돌리고 있어,

운영환경(freetier) 에서의 DB 형상관리를 위해서 Flyway를 도입하기로 했는데,

정리하며 도입기를 적어보고자 한다.

 

FlyWay란?

• DB Migration Tool, Git과 같은 DB의 형상관리 프로그램이다.
• 운용 서버에서는 hibernate의 ddl-auto: create or update 를 사용할 수 없기 떄문에 (사용해서도 안된다.)
• 우리도 배포된 환경에 도입해 보기로 했다.

 

초기 설정 방법 (의존성 설정)

• path
  • resources/db/migration 폴더에 지정해야지만 작동한다. (사실 커스터마이징 가능)
• build.gradle

    implementation("org.flywaydb:flyway-core")
    implementation("org.flywaydb:flyway-mysql")

 

• application.yml

  flyway:
    enabled: true
    baseline-on-migrate: true
    baseline-version: 1

 

baselineOnMigrate란?

테이블이 이미 존재하는, 비어있지 않은 스키마(데이터베이스)에서 실행될때, 자동으로 기준선을 설정

baseline까지의 모든 마이그레이션을 제외하고 현재 기준 데이터베이스부터 시작한다는 뜻
flyway를 프로젝트 시작부터 도입 할 수도 있지만, 아닌경우가 더 많은데, 이 경우에 사용해주어야 한다.

네이밍 규칙

 

 

•  Prefix
  • V는 현재 버전을 업데이트 하는 경우, U는 되돌리는 경우, R은 버전에 관계없이 매번 실행하는 경우에 사용된다.
  • 보통 U, R은 잘 사용되지 않는다.
• Version
  • V는 버전이 명시되어야 하고, R은 없어도 상관이 없다.
• Seperator
  • __ 와 같이 UnderScore 2개로 작성되어야 한다는 룰이 있다.
• Description
  • 단어의 구분은 UnderScore 1개로 이루어지며, 자유롭게 주석을 적을 수 있다.

결국, Flyway는 baseline 기준으로 스크립트의 최신 버전과 현재 데이터베이스의 버전이 다르다면, 최신순까지 스크립트를 순차적으로 실행하여 마이그레이션 해주는 놈인것이다.!

 

그렇다면, 우리 프로젝트엔 어떻게 적용했는가?

1. baseline을 지정한다.

application.yml에 다음과 같이 baseline을 지정해줬다.

  flyway:
    enabled: true
    baseline-on-migrate: true
    baseline-version: 1

 

이렇게 되면 현재 db 구조로 flyway_schema_history 테이블이 생기며,

flyway_schema_history 테이블

 

우리가 작성한 V2__머시기머시기.sql 부터 DDL을 적용시킨다는 것이다.

2. 여기서 한술 더떠 V1__init.sql도 작성해준다.

우리가 현재 가지고 있는 구조에 대한 DDL을 V1으로 만들어 준다.

이렇게 되면 현재 구조가 어떤지를 확인하기 수월해 진다는 장점을 가질 수 있었다.

예시들

3. 변경사항이 있을때마다 DDL을 작성해준다.

만약, anniversary 테이블에서 content 필드를 제거한다고 가정해보자.

그럼 V2__anniversary_delete_content.sql 등으로 만들고, 다음과 같이 작성하면된다.

ALTER TABLE anniversary DROP COLUMN content;

그러면, 다른 팀원들이 실행했을때는 V2 Schema까지 DB에 적용이 된다. (너무 신기방기..)

 

따라서 백엔드 팀원 모두가 이 flyway 사용해줘야 한다는 단점이 있지만,
잘 활용하면 굉장히 편한 라이브러리라고 생각해서 적극 도입해보기로 했다.