학습 배경

케이의 블로그를 참고해서 개발환경과 배포 환경을 분리해봤다. 하지만 이렇게 분리하고 나니 테스트가 거의 다 깨졌다.

처음에는 테스트 쪽에 application.yml을 생성하면 된다고 생각했는데 그렇지 않았다. 그래서 테스트코드 설정들을 보다가 @ActiveProfiles를 보게되었다. 문제 해결은 @ActiveProfiles("dev") 로 바꾸고 쉽게 해결되었다.

@ActiveProfiles와 @Profile을 잘 모른다고 생각하여 정리해보려 하였다.

Profile

profile은 활성화되었을 때 컨테이너에 등록되는 빈 정의들의 논리적인 묶음이라고 한다.

위의 문제 상황에서 봤듯이 배포환경이냐 개발환경에 따라 DataSource가 달라져야할 수도 있다. 이런 '환경'을 미리 등록해서 쉽게 필요한 설정을 바꿀 수 있다.

@Profile은 하나 또는 하나 이상의 profile들이 active될 때 뭐가 적합한 컴포넌트라는 것을 알려준다.

위와 같이하면 "development" 상황에서는 위의 dataSource를 사용하고, "production" 상황에서는 아래의 데이터 소스를 사용한다.
즉 현재의 profile에 따라 @Profile에서 일치하는 컴포넌트를 등록해서 실행하겠다는 뜻이다.

이렇게 Profile에 따라 다른 컴포넌트를 쓰게했다면 그 Profile이 있어야한다. 그리고 어느 profile을 active할지 알려줘야 한다.

가장 쉬운 방법은 ApplicationContext를 통해서 직접 알려주는 것이다.

또는 학습배경에 나왔던 것처럼 spring.profiles.active에서 프로퍼티 값으로 알려줄 수도 있고, web.xml 등을 이용할 수도 있다.

참고로 profile은 꼭 하나만 선택해야하는게 아니다. 여러 개의 profile을 충돌나지 않는 선에서 사용할 수도 있다.

공식문서

@ActiveProfiles

@ActiveProfiles("dev")를 붙임으로서 ApplicationContext에게 {"dev"} profile을 활성화해서 사용하라는 것을 알려주는 것이다.

공식문서에서도 @ActiveProfiles 어노테이션이 여러군데 선언되어 중복되는 것을 막기 위해 상위 클래스에 붙이고 상속해서 사용하는 것을 추천하고 있다.

• 공식문서

번외 - profile별 파일 관리

위에서 보는 것처럼 application-{profile}.yml파일을 생성할 수 있다. 그리고 그 profile을 활성화하면 그 파일을 이용한다. profile을 활성화하는 것은 application.yml을 이용해야 한다. (application.properties 마찬가지)

공식문서

결론

주어진 코드에 붙어서 사용하던 것인데 충분히 파악하지 않고 사용하였다. 이렇게 문제가 생길 때라도 틈틈히 공부를 해서 채워넣자.