시나리오를 통해 Flyway 사용법 학습하기

여는 글

우아한 테코톡의 코기님의 영상 뿐만 아니라 이미 Flyway에 대한 자료는 인터넷 상에 많이 공개 되어 있습니다. 다만, 제가 글 뿐으로는 사용 방법에 대해서 백 퍼센트 이해하기가 힘들었습니다. 그래서 해당 라이브러리가 해결해주는 문제의 범위, 그리고 한계점에 명확히 이해하기 위해 직접 간단한 테스트 프로젝트를 만들어 직접 만들어 보며 학습해보았습니다.

 

우선 Flyway 자체에 대해서는 아래 링크를 통해 이해하시고, 실제 실습은 제 Github Repository를 내려 받아서 직접 따라하시면서 공부해봅시다.

기본 학습 자료

• Flyway에 대해 설명하는 Toast의 글
• https://meetup.toast.com/posts/173
• 코기 님의 Flyway 소개와 이미 구축된 DB가 있는 경우에 대한 활용법https://ecsimsw.tistory.com/entry/Flyway-DB-마이그레이션-기존-데이터가-있는-경우?category=887812
• https://ecsimsw.tistory.com/entry/Flyway로-DB-Migration?category=887812

시나리오

실습 리포지토리

GitHub - jordy-torvalds/com.jordytorvalds.lab.flywaylab: flyway에 대해 직접 실습하며 이해해보기 위한 프로젝트

시나리오 1. 프로젝트 실행시 최초 상태

JPA의 DDL-AUTO 설정이 none으로 되어 있어 엔티티에 대한 테이블을 생성하지 않아 도메인과 관련된 테이블이 하나도 없는 상태입니다. 그러나 spring.flyway.baselineOnMigrate 를 true로 줬기 때문에 flyway_schema_history 테이블이 생성되었습니다.

flyway_schema_history 테이블이 DB Mirgration SQL의 버전을 관리 합니다.

시나리오 2. .sql 파일을 통한 테이블 마이그레이션

프로젝트의 파일 트리를 보면 src/resources/db/migraiton 디렉토리가 있습니다. 해당 디렉토리가 flyway의 마이그레이션 SQL이 들어가는 기본 경로 입니다. V1__jordy.temp 파일의 확장자를 .sql로 바꾼후에 실행해봅시다.

해당 파일은 버전1로 관리되는 jordy란 주석이 달린 데이터베이스 마이그레이션 SQL이란 의미를 가집니다. 자세한 DB 마이그레이션 .sql 파일의 네이밍 룰은 위 학습 자료를 확인해주세요.

실행한 후 localhost:8080/web-console에 접속해서 확인해보시면 테이블 V1__jordy.sql 파일 내용 대로 테이블이 생성되었으며, 동시에 이에 해당하는 DB 마이그레이션 데이터가 추가됐음을 알 수 있습니다.

시나리오2. DDL-AUTO 옵션 none → update

jpa의 ddl-auto 옵션이 none일 떈 스프링 앱 프로세스 실행 시 아무것도 하지 않지만, update일 떄는 변경된 내용에 대해 갱신을 합니다.

현재 프로젝트에서는 TABLE1부터 3까지 총 3개의 @Table이 붙은 클래스가 있으므로 ddl-auto 옵션을 update로 변경한 후 스프링 앱 프로세스를 실행하면 테이블 3개가 인서트 될 것입니다. 이 작업이 flyway에 영향을 줄까요?

주지 않습니다!

flyway_schema_history 테이블 전과 동일 합니다.

시나리오3. flyway_schema_history 테이블 내 히스토리 데이터 직접 삭제

flyway_schema_history 테이블 내에 추가되어 있는 V1 기록을 삭제하면 어떻게 될까요?

일단 V1 SQL 파일에 대한 정보를 flyway_schema_history에 삽입한 후에 ADD1, ADD2 테이블 마이그레이션에 대한 예외가 발생합니다.

 

그리고 spring.flyway.validate-on-migrate 옵션에 따라 처리되는 내용도 조금 다른데, 해당 옵션이 true인 상태에서 마이그레이션 시 예외가 발생하면 이전 상태로 복원되는 반면에, false인 상태에서 마이그레이션이 예외가 발생하면 예외가 발생되기 전 실행 내용은 유지 됩니다.

 

이에 대한 것은 ADD1 테이블과 flyway_schema_history의 실패 이력을 삭제한 후에 테스트 해보시면 확인하실 수 있습니다.

 

마이그레이션 실패한 .SQL 파일의 내용이 이미 적용이 완벽히 완료된 상태일 때 대응하기 위한 방법은 flyway_schema_history 내 관련 row의 success 컬럼의 값을 TRUE로 바꿔주면 정상적으로 기동 됩니다.

 

시나리오4. 기존에 마이그레이션한 테이블을 직접 삭제

V2__jordy.temp 파일의 확장자를 SQL로 변경한 후에 실행하면 ADD1부터 4까지 생성되실 겁니다. 이떄 테이블 ADD1과 3을 삭제하고 스프링 앱 프로세스를 재실행하면 어떻게 될까요?

정답은 신경쓰지 않는다 입니다! 그래서 flyway를 사용을 시작한 시점부터 별도로 직접 DDL을 실행해서 변경을 할 경우 추적이 힘들 수 있습니다.

임의로 table1을 삭제한 후에 ddl-auto를 validate로 설정하여 실행해보았습니다.

이를 보조하기 위해 jpa의 ddl-auto를 validate로 할 경우 소스코드로 설정해놓은 테이블에 대해서는 유효성 검사가 가능하므로 db 마이그레이션으로 DB 변경 이력을 버저닝함과 동시에 ddl-auto의 옵션을 validate로 확인하시면 되겠습니다.

지금까지 시나리오를 통해 Flyway의 사용법을 알아보았습니다!

읽어주셔서 감사합니다.