Evolve your Database Schema easily and reliably across all your instances
데이터베이스 스키마의 변화를 손쉽게 관리
하는 기능을 가진 기술
1. FlywayDB 소개
1.1. 왜 DB Migration 을 사용하는가?
각기 다른 데이터베이스에서 동일한 DB스키마를 유지할 수 있는 기능이 필요하다. 
2. FlywayDB 동작방식 설명
마이그레이션 버전 1, 버전 2가 있는 상황에서 flyway는 SCHEMA_VERSION 라는 이름의 비어있는 단독 테이블을 생성한다.
테이블이 생성되면 flyway는 즉시 파일시스템 혹은 애플리케이션의 마이그레이션을 위해 지정된 클래스패스에서 SQL 혹은 JAVA 파일을 탐색한다. 탐색된 파일들은 버전에 따라서 정렬하여 실행한다. 
마이그레이션 버전1, 버전2가 각각 실행되면 SCHEMA_VERSION 테이블에는 다음과 같이 마이그레이션 이력이 저장된다.
애플리케이션이 실행될때마다 flyway 설정에 따라서 파일과 SCHEMA_VERSION의 변동사항을 확인하나. 새로운 버전의 파일이 추가되면 실행하고 그 변경이력을SCHEMA_VERSION에 추가한다.
참 쉽죠??
3. 프로젝트 적용
3.1. SpringBoot 설정
스프링부트에서는 데이터베이스 마이그레이션을 지원한다. 그 중에서 Flyway를 채택했다. 이전 프로젝트에서는 Carbon5(c5-db-migration) 라고 하는 마이그레이션 도구를 사용했는데...
그러다가 발견한 것이 Flyway. 손쉽게 사용가능함.
3.1.1. 의존성 추가
Maven
Gradle
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'com.h2database:h2:1.3.170'
classpath 'org.flywaydb:flyway-gradle-plugin:3.2.1'
}
}
apply plugin: 'org.flywaydb.flyway'
apply plugin: 'java'
flyway {
url = 'jdbc:h2:file:target/foobar'
user = 'sa'
}
SpringBoot
dependencies {
/**
* http://flywaydb.org/
* Database Migration tool
*/
compile "org.flywaydb:flyway-core"
}
3.1.2. application.yml(or properties) 설정
DB를 초기화하는 다양한 방법들이 있다.
- JPA 에 의한 초기화
- Hibernate 에 의한 초기화
- JDBC에 의한 초기화
- Batch를 이용한 초기화
그보다 높은 차원에서 손쉽게할 수 있는 것들이 있는데, 그중 하나가 바로 Flyway
flyway:
enabled: true
check-location: true # 마이그레이션 스크립트 파일이 존재하는지 여부를 확인
locations: classpath:db/migration # 마이그레이션 스크립트 위치
baseline-version: LATEST # 마이그레이션을 시작할 번호
sql-migration-prefix: V
sql-migration-suffix: .sql
url: jdbc:h2:file:~/.database/flywaydb;DB_CLOSE_DELAY=-1;AUTO_SERVER=TRUE;DB_CLOSE_ON_EXIT=FALSE; # Flyway 소유의 데이터소스를 생성하려고 하는 경우 사용
user: sa # Flyway 소유의 데이터소스를 생성하려고 하는 경우 사용
password: # Flyway 소유의 데이터소스를 생성하려고 하는 경우 사용
Flyway에 지정할 수 있는 속성은 다음과 같음
# FLYWAY (FlywayProperties)
flyway.*= # Any public property available on the auto-configured `Flyway` object
flyway.check-location=false # check that migration scripts location exists
flyway.locations=classpath:db/migration # locations of migrations scripts
flyway.schemas= # schemas to update
flyway.init-version= 1 # version to start migration
flyway.init-sqls= # SQL statements to execute to initialize a connection immediately after obtaining it
flyway.sql-migration-prefix=V
flyway.sql-migration-suffix=.sql
flyway.enabled=true
flyway.url= # JDBC url if you want Flyway to create its own DataSource
flyway.user= # JDBC username if you want Flyway to create its own DataSource
flyway.password= # JDBC password if you want Flyway to create its own DataSource
3.1.2. 디렉토리 설명
3.2. 스키마 관리방법 설명
- 프로젝트의 소스코드와 함께 관리한다.
- 로컬, 테스트와 출시 버전을 분리한다.
- 로컬, 개발은 update로도 충분...
- 테스트, 운영 등 서버는 validate 모드로 관리
- 프로젝트의 버전관리시스템에 기능을 활용하여 버전관리가 가능
3.2.1. DB 스키마 추출방법
어디까지나 수동.... 처음에는 수동처리가 필요함...
로컬 테스트에서 Hibernate에서 DDL 쿼리를 생성하도록 정의 생성하도록 설정
jpa:
hibernate:
ddl-auto: create-drop
테스트를 실행
사용할려는 DB에 따라 생성하는 SQL 스크립트가 달라질 수 있는데, 이는H2Database 에서 제공하는 기능을 활용하여 MySQL, Oracle 등으로 변경하면 하이버네이트의 방언Dialect 에 의해 적절한 쿼리가 생성됨
쿼리를 복사하여 손질
- 처음 쿼리는 V1__init_db_schema.sql 로 생성
3.2.2. 변경이력 관리
프로젝트 내에 포함되어 있으니 모든 것을 형상관리시스템에 맡긴다.
3.3. 활용방안
- 제품 출시 후 DB 스키마를 초기화하는 것이 아니라, 출시 이후 변경된 사항들에 대한 형상을 관리할 수 있다.
- 위에서 설명한 동작방식을 상기하기 바란다.
