Flyway Get started

---

Why database migrations

먼저, Shiny라는 프로젝트를 하고 있다고 가정하고 시작을 해보자.

이 프로젝트은 Shiny DB와 연결되서 동작하는 Shiny  Soft을 제공하는 것입니다.

간단한 다이어그램으로 이것을 나타내 보면 다음과 같습니다.

우리는 소프트웨어와 database를 가지고 있다. 그리고 이것들은 우리가 원하는 대로 잘 동작할 것입니다.

하지만 대부분의 프로젝트에서, 이렇게 단순한 모습이 (해석해 보면) 다음과 같이 보여 질 것입니다.

우리는 하나의 (개발)환경만 다루는 것이 아니라 여러개를 다루어야 합니다.  이것은 많은 도전이 됩니다.

우리는 코드를 통해 이러한 것들을 잘 해결해 왔습니다.

• 버전 관리는 이제 매일 접하는 대중적인 좋은 툴이 되었습니다.
• 우리는 지속적인 빌드와 지속적 통합을 할 수 있게 되었습니다.
• 우리는 잘 정의된 릴리즈와 배포 프로세스를 가지고 있습니다.

하지만 데이터 베이스는 어떤가요?

불행히도 여기에서(database 영역)는 별로 좋은 성과가 없었습니다.

많은 프로젝트들이 여전히 수작업으로 SQL 스크립트를 적용하고 있습니다.

그리고 때로는 그렇게 하지도 못하고 있습니다. 그리고 많은 문제(질문)들이 생겨났습니다.

• 이 머신에 있는 데이터 베이스의 상태는 어떠한가?
• 이 스크립트가 이미 적용되었는가? 아니면 아직 적용되지 않았는가?
• 운영에 적용된 quick fix가 테스트 소프트웨어에 도 적용되었는가?
• 새로운 데이터 베이스 인스턴스를 어떻게 셋업할 것인가?

이러한 질문에 대한 대다수의 답들은: 잘 모르겠어 입니다.

Database migration은 이러한 혼란에서 control을 회복하는 가장 좋은 방법입니다.

이것은(database migration은) 여러분들에게:

• 바로 database를 생성하게 해줌
• 항상 database가 어떠한 상태인지 알려 줌
• 현재 버전에서 새로운 버전으로 명확한(deterministic) 방법으로 migration 해줌 

---

How Flyway works

* 역자주: 여기에서 migration이란 "migration 작업"이 아니라 "migration을 하기 위한 스크립트" 정도로 이해하면 좋습니다. 

가장 쉬운 시나리오는 빈 database에 Flyway를 설치(point)한 경우 입니다.

Flyway가 schema history table을 만들려고 시도합니다. 만약 database가 비어있으면, Flyway는 그것(Schema history table)을 찾지않고 대신 create합니다. 

이제 여러분은 flyway_schema_history라는 비어있는 테이블을 가진 데이터 베이스를 가지게 되었습니다.

이 테이블은 database의 상태를 추적하는 데 사용됩니다.

즉시 Flyway는 migration을 하기 위해 파일 시스템에나 어플리케이션의 classpath를 scanning하기 시작합니다. SQL이나 Java로 쓰여여져 있을 수 있습니다.(역자주: 마이그리이션 스크립트들)

마이그리이션은 version number에 따라 sort되고 차례대로 적용(마이그리이션을 진행)합니다.

각각의 마이그리이션이 적용되면, schema history table 도 거기에 맞춰 업데이트 됩니다.

lyway_schema_history

installed_rank	version	description	type	script	checksum	installed_by	installed_on	execution_time	success
1	1	Initial Setup	SQL	V1__Initial_Setup.sql	1996767037	axel	2016-02-04 22:23:00.0	546	true
2	2	First Changes	SQL	V2__First_Changes.sql	1279644856	axel	2016-02-06 09:18:00.0	127	true

metadata와 initial state가 가진 상태로, 우리는 newer versions으로 migration된 것을 확인(talk about)할 수 있습니다.

Flyway는 파일 시스템이나 어플리케이션의 classpath를 다시한번 scan합니다. migration들은 schema history table과 비교해서 체크됩닙니다. 만약 current라고 마킹된 version number 보다 낮거나 같다면, 무시됩니다.

나머지 migration은 pending migrations입니다.: 유효하지만 적용되지는 않는

그것들은 그리고 나서 version number에 따라 sort되고 순차적으로 실행(executed in order)됩니다:

 schema history table도 거기에 맞춰(작업한 순서) update 됩니다.

lyway_schema_history

installed_rank	version	description	type	script	checksum	installed_by	installed_on	execution_time	success
1	1	Initial Setup	SQL	V1__Initial_Setup.sql	1996767037	axel	2016-02-04 22:23:00.0	546	true
2	2	First Changes	SQL	V2__First_Changes.sql	1279644856	axel	2016-02-06 09:18:00.0	127	true
3	2.1	Refactoring	JDBC	V2_1__Refactoring		axel	2016-02-10 17:45:05.4	251	true

그리고 이것만 하면 됩니다. database를 변경시킬 필요가 있을 때마다, DDL이나 DML 상관없이, 단순이 새로은 migration을 만들고 현재 버전보다 높은 버전을 부여하면 됩니다. 다음으로 Flyway가 시작하면, 그것(migration)을 발견하고 적절하게 database를 업그레이드 할 것입니다.