[Key Word 개발기] Flyway 적용기

부트캠프 협업프로젝트에서 flyway를 적용하기로 했다. 개인프로젝트때도 적용해보기도 했고 특히 협업프로젝트때 적용하면 좋을 것같아서 팀원들에게 적용하자고 말하게되었다.

 

---

Flyway??

이미 블로그에 flyway에 대해서 적은 적이 있다. 그럼에도 우리 프로젝트에 왜 flyway를 적용했는지 정리하고자 한다.

 

일단 flyway란 데이터베이스 마이그레이션 툴로서 데이터베이스 변경사항을 추적하고, 업데이트나 롤백을 보다 쉽게할 수 있도록 도와주는 도구이다.

 

https://documentation.red-gate.com/flyway/quickstart-how-flyway-works/why-database-migrations

 

데이터 마이그레이션이 필요한 이유는 프로젝트를 진행할때 위 그림처럼 여러 환경에서 데이터베이스가 존재한다.

팀원들이 각자 로컬에서 데이터베이스를 이용하기도 하고, CI, Test 할때도 각각 별도의 데이터베이스를 이용한다. 

 

팀원들이 각자 로컬에서 개발을 하다보면 엔티티의 구조 변화로 인해 데이터베이스 스키마 변경이 필요할때가 있다.

만약 데이터마이그레이션이 없다면 일일히 스키마 수정을 위한 DDL을 각 환경별로 실행시켜줘야한다.

 

물론 Hibernate설정에서 ddl-auto를 통해서 맞출 수 있지만, 실제 배포에서는 저런 설정을 하면 안된다.

(ddl-auto가 create이면 이전기록을 날려버리니까 배포환경에서 절대 사용못함)

 

사실상 개발할때 테이블이 변경되는데에는 별로 상관이 없다. 단순히 Drop하고 바뀐 엔티티 구조에 맞게 DDL을 변경하면 된다.

그러나 Production 서버에서 Drop을 할 수 있는가??? 안된다. 그럼 데이터 다 날라가는데..??

 

그럼 Production 서버에는 Alter table을 통해 테이블 스키마를 변경해야한다. 간단한 변경이라면 직접 ddl를 작성하여 실행할 수 있지만 사람의 실수도 존재하고 형상관리도 어렵다.

 

정리하자면

- 직접 ddl작성으로 인해 사람 실수 방지

- 형상 관리(변경사항을 체계적으로 추적, 통제하는 것) -> db변경을 관리하는 것(깃 처럼 코드 히스토리 다룸)

- 모든 서버에 공통적으로 적용할 수 있는점(각 배포 환경에 돌아다니면서 직접 스키마 변경하는 거 막음)

- 추가적으로 런타임시 자동으로 실행되기 때문에 실수할 여지를 줄여줌