[Spring] Note1. Flyway Setting

Note1. Flyway란?

데이터베이스 마이그레이션 툴로 Git의 데이터베이스 버전이라고 이해하면 된다.

기존에 Flyway를 도입하기 이전에는 데이터베이스 스키마 구조가 변경될 때마다 매번 FE측에 Sql 스크립트를 보내줘야만 했다. 

무엇보다 실제 프로덕션 환경이라면 서버에 직접 들어가 데이터베이스의 구조를 변경하는것은 위험하다.

그리고 이번 프로젝트에서는 빈번하게 데이터베이스가 변경되는 환경이라 매번 팀원들에게 데이터베이스를 수정하라고 공지하는 것도 번거로워서 Springboot 프로젝트에 Flyway를 도입을 결정했다. 

 

비슷한 db 형상관리 툴로 Liquibase가 존재하는듯 한데, 롤백, 스냅샷등의 기능이 필요하거나 자세한 커스텀이 필요하다면 Liquibase를 사용하는 편이 좋을 듯싶다. Liquibase와 Flyway의 차이점에 대해서는 아래 블로그에 자세하게 정리되어 있으니 참고하도록 하자. 

데이터 베이스 형상관리(Migration)툴 비교 Flyway vs Liquibase

 

Note2. Setup

Spring Boot pom.xml Dependency 

        <!-- Flyway Database Migration -->
        <dependency>
            <groupId>org.flywaydb</groupId>
            <artifactId>flyway-core</artifactId>
        </dependency>

 

JPA Hibernate ddl-auto option change

ddl-auto option을 update로 설정해두면 엔터티 클래스와 매핑되는 테이블이 없으면 자동으로 생성하고 변경사항을 적용한다. 

하지만 update 옵션은 한계가 있기에 실제 프로덕션 환경에서는 잘 사용하지 않는데 그 이유는 기존에 존재하는 컬럼 속성은 변경하지 않고 "새롭게 추가되는 컬럼의 변경사항만 반영한다"는 점이다.

따라서 nullable, datatype 등의 변경사항은 반영하지 못한다. 어찌보면 당연하게 만약 varchar(20)을 varchar(10)으로 변경했다고 가정해 보자. 그러면 10크기만큼의 데이터가 잘려간다. 

따라서 flyway를 도입하는 환경에서는 충돌을 막기 위해 ddl-auto option을 none으로 두도록 하자 

  jpa:
    hibernate:
      ddl-auto: none

 

Migration Script 

sql 스크립트 명명규칙은 고정으로 V{Version}__{description}.sql 형태이다. 

버전과 설명 사이에 언더스코어가 2개임에 유의하고 이는 기본값으로 application.yml에서 원하는 대로 커스텀이 가능하다.

하지만 명명규칙을 제대로 적어주지 않으면 flyway가 스크립트를 인식하지 못하니 조심하자

# Flyway 설정
flyway:
  enabled: true
  locations: classpath:db/migration
  baseline-on-migrate: true  # 기존 DB가 있을 경우 baseline 설정
  validate-on-migrate: true
  clean-disabled: true