Flyway 이용한 형상관리

 

1.    Flayway?

데이터베이스 형상관리 툴

1)      로컬에서 변경한 데이터베이스의 스키마나 데이터를 운영 데이터베이스에 반영하는 것을 누락하는 것을 막기 위해 사용한다.

2)      개발 DB와 운영 DB의 스키마를 비교하거나, 운영 DB에 수작업을 가하는 업무와 위험성을 줄이기 위해 사용한다.

3)      생성한 형상을 새로운 DB에 적용하는 마이그레이션 툴

4)      지원 DB : Oracle, SQL Server, DB2, MySQL, Aurora MySQL, MariaDB, Percona XtraDB Cluster, PostgreSQL, Aurora PostgreSQL, RedShift, CockroachDB, SPA HANA, Sysbase ASE, Informix, H2, HSQLDB, Derby, SQLLite

5)      버전 : Community Edition(무료), Pro Edition(유료), Enterprise Edition(유료)
https://flywaydb.org/download/

 

2.    동작 방식

l  설치 후 기본 설정 진행하면 버전 관리 테이블을 생성되고
Flyway는 마이그레이션을 위해 파일 시스템이나 클래스 패스를 검사 하기 시작
(SQL or JAVA)
마이그레이션은 버전 번호를 기준으로 정렬 되고 순서대로 적용
각 마이그레이션이 적용될 때마다 스키마 기록 테이블이 그에 따라 업데이트

 

3.    명령어

1)      migrate - 스키마정보를 DB에 마이그레이션한다.

2)      clean - flyway로 생성한 스키마를 모두 삭제한다고 하지만, 해당 데이터 베이스의 모든 테이블을 삭제한다. (절대 서비스에 사용하면 안됨 – 테스트 서버에서도 사용 자제)

3)      info - DB에 적용된 스키마 정보와, 로컬에 pending 되어있는 변경 정보를 보여준다.

4)      validate - DB에 적용된 스키마 정보와, 로컬의 변경 점을 비교하여 보여준다.

5)      undo – 실행한 마이그레이션을 취소한다 (Pro버전 이상만 존재)
           target이 설정되어야 하며 지정안하면 취소가 힘들고 복구가 어렵다.

6)      repair - 마이그레이션 실패한 내역을 수정한다 (삭제, 교체)

7)      baseline - flyway로 형상 버전관리를 시작할 baseline 을 설정한다.

8)      참조 : https://flywaydb.org/documentation/command/migrate

 

4.    기본 사용법 (windows command Line을 기준으로 설명)

l  flyway파일 다운로드

1)      사용환경에 따라 설치 또는 API 다운로드 https://flywaydb.org/download/

2)      압축 해제 및 API 연동

l  해당 압축 해제 폴더에 conf에 내용 수정 (flyway.conf)

1)      flyway.url= : 상단에 DB에 맞는 형태의 jdbc 연결로 확인
ex) flyway.url=jdbc:sqlserver://localhost:1433;databaseName=AdventureWorks2017

2)      flyway.user= : 디비 접근 유저(DDL, write, read 권한이 필요)

3)      flyway.password= : 디비 접근 유저의 비밀번호

4)      해당 설정으로 기본 명령이 해당 DB에 접근하여 처리하나 옵션을 통하여 다른 DB에 접근할 수 있다.

l  기준점 잡기

1)      해당 데이터베이스의 버전의 시작점을 잡아주는 작업

2)      설정 전

3)      설정 명렁어 실행
flyway baseline

 

4)      설정 후

 

5)      flyway_schema_history 테이블 생성과 정보를 재 조회 했을 시 Version 1로 기준이 잡혀 있는 것을 확인할 수 있다.

l  형상 관리 패치

1)      flyway 폴더 내에 sql 이라는 폴더가 존재 해당 폴더에 패치 스크립트를 넣는다.

 

2)      패치 스크립트의 파일명

A.     Versioned Migrations : 마이그레이션 쿼리의 버전을 관리하도록 하는 스크립트 파일

B.      Undo Migrations : 실행 취소를 위한 스크립트 파일(이전의 버전으로 돌아간다.)
Pro 버전 이상에서만 사용

C.      Repeatable Migrations : 패치 때 마다 반복적으로 실행되는 스크립트
(view, function, Stored Procedure 등을 재생성 하거나 패치 때 마다 삭제되거나 등등)

D.     각 파트의 설명

I.       Prefix : 항상 대문자로 이루어져야 한다.
V – Versioned
U – Undo
R – Repeatable

II.      Vsersion : x.x 로 이루어진 패치 스크립트의 버전
x는 자연수로 인식되어 정렬된다.
ex) 2.2 vs 2.10 – 2.2가 먼저 실행

III.    Separator : __ (언더바 2개)

IV.    Description : 파일의 내용 설명

V.      Suffix : 확장자 (.sql 로만 이루어짐)

E.      참조 : https://flywaydb.org/documentation/migrations

3)      예제 파일 실행

A.     예제 스크립트 생성
create table test (
    ID int not null,
    NAME varchar(100) not null
)
go

B.      파일 패치 여부 확인
flyway info

패치 진행되지 않은 버전의 파일이 존재하는 것 확인 가능

C.      패치 실행
flyway migrate

성공 메시지가 발생되었다.

추후 한번 더 확인

패치 성공적으로 처리된 것 확인

테이블이 생성되어 있는 것을 확인 할 수 있다.

 

5.    응용 (다중 데이터베이스 및 다중 서버 관리)

l  해당 내용은 관리의 편의성을 위함이면 해당 cmd 파일을 생성하며 썼던 옵션들을 사용하여 직접적으로 명령을 내릴 수 있다.
해당 옵션 사용 가능여부는 해당 명령어의 Document에서 확인 가능하다.
https://flywaydb.org/documentation/migrations

l  다중 데이터베이스

1)      flyway가 들어있는 폴더에 데이터베이스명으로 폴더 생성

2)      데이터베이스 폴더 내부에 conf 파일 생성

3)      conf 파일 수정

A.     flyway.url= : 해당 데이터베이스 연결로 변경
Ex) flyway.url=jdbc:sqlserver://localhost:1433;databaseName=AdventureWorks2017

B.      flyway.user= : 해당 데이터베이스 접속 가능 계정

C.      flyway.password= : 해당 계정의 비밀번호

D.     flyway.locations= : sql 파일이 있을 위치(새로 만들 cmd 파일이 존재할 위치에서부터 상대주소)
ex) flyway.locations=filesystem:. (cmd 파일과 같은 위치)

4)      cmd 파일 생성

flyway 의 cmd 위치를 연결하고 -configFiles 옵션을 이용하여 conf 파일을 연결
ex) ../flyway-5.2.4/flyway.cmd -configFiles=../AdventureWorks2017/conf/flyway.conf %*

 

5)      cmd 파일 확인

6)      다른 데이터베이스 반복 작업 후 다른 내용인 것을 확인

l  다중 서버
sql 파일은 같은 것을 사용하고 연결만 바뀐 conf 파일을 사용해야 함으로 해당 데이터베이스 폴더 내에 cmd 파일을 추가적으로 사용하는 방식으로 처리 가능

1)      conf 파일 분리

2)      cmd 파일 분리 생성 및 수정(conf파일 연결 수정)

 

3)      같은 폴더에 sql 파일이 있으나 적용 여부 다르게 나오는 것 확인

 

6.    장점 및 단점, 서비스 적용 여부

l  장점 :

1.      여러 데이터베이스 및 서버에 따른 패치의 적용 여부를 관리할 수 있다.

2.      패치 스크립트의 히스토리 관리가 가능하다

3.      패치 작업 시 사람의 실수를 방지할 수 있다.

l  단점 :

1.      최초 baseline 실행 시 모두 같은 형상을 가지고 있어야 한다.

2.      데이터가 다르면 DML을 통한 로직 정보가 있다면 다른 결과를 가져 올 수 있다.

3.      스키마 비교를 할 수 없다.

l  서비스 적용 여부

1.      Diff 가능한 오픈소스와 혼용 사용하면 서비스의 적용하여 형상 관리를 보다 편히 할 수 있어 보임.

2.      batch 파일 등을 이용한 패치 스크립트 실행의 자동화 처리가 가능해 보인다.

3.      사전 준비를 통해 이전보다 누락없고 빠른 패치 스크립트의 실행이 가능할 것으로 보입니다.

l  참조
https://www.eduardopiairo.com/2017/02/27/flyway-command-line-easy-setup/
https://meetup.toast.com/posts/173
http://chanwookpark.github.io/dbmigration/flyway/2016/08/23/flyway/
https://bkim.tistory.com/2
https://flywaydb.org/documentation/