이전 포스트에서 Flyway를 사용해 프로덕션 DB의 마이그레이션 버전 관리를 했던 경험을 기록했다. 로컬 환경에서 마이그레이션 버전 관리가 필요할까? 프로덕션 서버의 DB 관리 시 빛을 발할 Flyway이지만, 동작을 보장하기 위해 로컬 환경의 DB와 개발 서버의 DB에서도 똑같이 적용할 필요가 있다. 개발 서버의 DB에도 데이터는 들어가기 쉽다. 프로덕션 서버라고 생각하고 올바른 데이터의 CRUD만을 최대한 다루면 유효한 데이터만을 개발 DB에 담고 개발 DB의 버전 관리 또한 유의미하게 할 수 있다. 그렇다면 로컬 환경의 DB는 어떨까? 개발자들이 각자 개발하는 만큼 기능이나 스키마의 추가나 삭제, 변경 등이 각자의 컴퓨터에서 무분별하게 이루어질 것이다. 버전 관리가 유의미하진 않지만, Flyway..
Spring
웹 애플리케이션 프로젝트에서 DB 마이그레이션을 위해 사용했던 Flyway에 대해 정리해보겠다. Flyway Flyway는 오픈소스 DB 마이그레이션 툴이다. 핵심적으로 무엇을 도와주냐면, DB 스키마에 대한 변경을 추적하고 업데이트나 롤백을 쉽게 진행하도록 애플리케이션의 DB 스키마 버전 관리를 도와준다. 자바/스프링 프로젝트를 위한 툴이 아닌 다른 언어로 된 애플리케이션을 사용할 때도 쓸 수 있고, CLI나 API 등을 지원하기도 하고 데스크탑 애플리케이션도 존재한다. 왜 변경사항을 추적할까? 로컬 디바이스, 우리의 컴퓨터에서 개발을 할 때는 변경의 추적이 상관없을 수도 있다. 내가 개발해서 내가 사용한다면 그 안의 데이터를 내가 직접 관리하고, 그 관리가 중요하지 않을 수도 있지 않은가? 하지만 변..
다른 글에서 소개했던 것처럼, 스프링 부트의 application.yaml을 이용해 Properties를 관리하는 방법은 다양한 애너테이션을 이용한 여러가지 방법이 있다. 그 중에서 내가 생각하기에 가장 객체지향스러운 방법을 오늘 포스트에서 다뤄보려 한다. @ConfigurationProperties의 단점 @ConfigurationProperties는 YAML의 계층형을 따라서 자동으로 카멜 케이스의 필드와 매칭되는 설정 값을 찾아 매핑을 진행한다. 스프링 프레임워크가 아닌 스프링 부트에서 지원을 하는 애너테이션이니 주의가 필요하다. 문자열을 이용한 하드코딩이 아니기 때문에 @Value보단 더 선호되는 애너테이션이라고 생각이 드는데, setter 메서드가 반드시 필요하다는 것이 아쉽다. 불변으로 생성할..
DB의 정보라던지 JWT의 내용이라던지 소스코드 외부적으로 값을 세팅해 줄 필요가 있을 경우 /resources 디렉토리 아래 .properties 혹은 .yaml에서 값을 읽어올 수 있다. 스프링 부트는 기본적으로 DB를 사용할 일이 있으면 application.yaml에서 DB 연결을 위한 값을 자동으로 설정한다. 이처럼 프레임워크의 흐름에 필요한 값을 넣기 위해 사용하는 경우도 있고, 개발자가 자체적으로 값을 소스코드 외부적으로 받아오도록 할 때 이러한 Properties들을 설정할 수 있는 방법은 여러가지가 있다.왜 Properties가 필요한가?우선 소스코드 외부적으로 왜 값을 넣어줄 필요가 있을지 생각을 해보자. 웹 서비스를 만들 땐 DB의 정보가 필요하다. 만약 팀원이 여러명 있다면, 각자의..
