[etc] Flyway 이용전략

Flyway는 개발영역에서만 사용

이용전략

• 개발(로컬)에는 V1__, V2__, V3__ 으로 자유롭게 업데이트 한다.

• IntelliJ 사용자는 Flyway migration creation plugin 사용: https://plugins.jetbrains.com/plugin/8597-flyway-migration-creation

• ex) V2018.06.11.21.46.00__첫번째.sql, V2018.06.11.21.50.00__두번째.sql

• 스키마 충돌 버전관리를 위해서 우선고려할 수 있는 방법이다.

• commit & push 전(공개 전): 하나의 파일로 통합하여 정리한 후 정상동작을 확인하고 푸시한다.

• 스테이지, 운영 단계에 스키마 변경에는 Flyway를 사용하지 않는다.

  • 스키마 변경 전에는 DB 상태 모니터링 하면서 장인정신으로 한땀한땀 반영한다.

  • DB 락 여부 확인, 속도 저하 등을 확인하며 진행

  • 운영데이터가 많이 누적된 경우에 처리속도가 느려 락이 걸리는 등의 상황이 발생할 수 있다.

추가사항

• H2 인-메모리 디비는 프로토타이핑 용으로 사용한다.

• H2에서 사용하는 쿼리가 실제 운영단계에 반영되었을 때 문제발생 가능성이 높다.

• cleanOnValidationError: 검증 중에 에러가 발생하면 자동으로 클린 처리를 함. ← 위험!!

  • https://flywaydb.org/documentation/commandline/validate.html

cleanOnValidationError

Whether to automatically call clean or not when a validation error occurs. This is exclusively intended as a convenience for development. Even tough we strongly recommend not to change migration scripts once they have been checked into SCM and run, this provides a way of dealing with this case in a smooth manner. The database will be wiped clean automatically, ensuring that the next migration will bring you back to the state checked into SCM. Warning ! Do not enable in production !

• https://stackoverflow.com/questions/14579368/feature-cleanonvalidationerror-seems-to-be-dangerous

  • 개발안정화 단계에서는 운영에서 사용하는 DBMS와 일치시키도록 한다.

• 로컬에 운영과 동일한 DB 설치

• Docker를 이용하여 설치