<aside> 💡 토글로 접어두지 않은 부분은 필수적으로 읽고 적용해주셔야 합니다‼️

</aside>

<aside> 💡 공식문서에서는 Java 12까지 Gradle 6.x까지 지원한다고 쓰여있지만, 여러 적용 사례를 봤을 때 최신버전에서도 대체로 잘 작동하는 편인 것 같습니다

</aside>

논의사항

1. 어떤 환경(local, dev)에서 사용할 것인지
2. CI할 때 data container를 만드는 방법도 있는데 다들 어떻게 생각하지는지요

왜 사용할까?

간단 설명

사용시 주의사항 (Rules)

• SQL-based migration으로 작성 (마이그레이션은 sql, java, 스크립트 언어로 작성될 수 있음)

• File Naming

  

  • prefix (V)
    • V: 버전 마이그레이션
    • R: 반복 마이그레이션
    • ❗️V나 R로 시작해야 flyway가 인식 가능
  • version (2)
    • 버전 마이그레이션에서만 사용
    • 숫자, 점, 언더바 조합으로 사용
    • ❗️반복 마이그레이션에서 version을 명시하면 파일명 제약 위반으로 에러 발생
  • separator (__)
    • description 부분을 구분하기 위한 구분자
    • ❗️언더바 2개 써야함
  • description (Add_new_table)
    • schema_version 테이블에 저장시 설명으로 사용됨
    • 언더바, 스페이스로 단어 사이 구분
  • suffix (.sql)
    • 확장자

• migration file 위치

  : application.yml에서 spring.flyway.locations의 옵션으로 위치 설정 가능

  • default, classpath: prefix가 붙은 location → Java classpath (src/main/resources/db/migration)
  • filesystem: prefix가 붙은 location → 파일 시스템에서 찾음 (예시: filesystem:/my-project/my-other-folder )
  • s3: prefix가 붙은 location → AWS S3 버킷에서 찾음
    • AWS SDK v2사용해야 함. dependencies도 추가해야 함
    • (참고) 필요하다면 나중에 추가해볼 예정
  • gcs: prefix가 붙은 location → GCS 버킷에서 찾음

적용하기

의존성 및 properties 설정

DB schema 변경(또는 entity 변경) 후 마이그레이션 파일 작성법

1. 위 파일명 규칙에 맞게 마이그레이션 파일을 생성

   1. 생성 위치: src/main/resources/db/migration

2. 마이그레이션 파일에 sql로 변경사항 작성

   <aside> 💡 하나의 파일에 1개의 DDL만!! flyway는 checksum을 파일 단위로 관리하며 파일에 문제가 생겼을 때 이 이후의 로직을 실행하지 않기 때문.

   </aside>

merge 후에 다른 팀원이 작성한 버전과 같은 버전의 마이그레이션 파일을 작성한 경우

• 버전을 겹치지 않게 변경

활용하기