스프링 클라우드 컨트랙트 공식 레퍼런스를 한글로 번역한 문서입니다.
전체 목차는 여기에 있습니다.
이번 섹션에선 스텁stub의 다양한 버전 관리 방법에 대해 설명한다:
7.4.1. API Versioning
버전 관리란 실제로 무엇을 의미하는 걸까? API 버전을 참조한다면, 여러 가지 방법을 사용할 수 있다:
- 하이퍼미디어 링크를 사용하면서 어떤 방법으로도 API 버전을 지정하지 않는 방법
- 헤더와 URL을 통해 버전을 전달하는 방법
어떤 방법이 더 나은지에 대한 질문엔 답하지 않겠다. 가지고 있는 요구사항과 비지니스 가치에 맞는 방법을 선택하는 것이 좋다.
API의 버전을 관리한다고 생각해보자. 이 경우 지원하는 버전 수만큼 명세contract도 따로따로 제공해야 한다. 모든 버전마다 하위 폴더를 따로 만들거나, 명세contract 이름에 버전을 추가하는 등 가장 적합한 방법을 선택하면 된다.
7.4.2. JAR versioning
버전 관리의 의미가 스텁stub이 포함된 JAR의 버전을 말하는 것이라면, 기본적으로 두 가지 방법이 있다.
지속적인 배포continuous delivery and deployment를 적용 중이라고 가정해보자. 즉, 파이프라인을 통과할 때마다 jar 버전을 새로 만들고, 언제든지 프로덕션으로 이동할 수 있는 상태다. 예시로 다음과 같은 jar 버전이 존재한다고 하면 (2016.10.20. 20:15:21에 빌드했다고 가정):
1.0.0.20161020-201521-RELEASE
다음과 같은 스텁stub jar가 만들어질 거다:
1.0.0.20161020-201521-RELEASE-stubs.jar
이 경우 스텁stub을 참조하려면, application.yml이나 @AutoConfigureStubRunner 안에 스텁stub의 최신 버전을 지정해야 한다. 다음 예제에서는 이를 위해 + 기호를 전달한다:
@AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:stubs:8080"})
하지만 고정 버전을 사용한다면 (예: 1.0.4.RELEASE 또는 2.1.1), jar의 구체적인 버전을 설정해야 한다. 아래 예시에선 2.1.1 버전을 설정하는 방법을 보여준다:
@AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:2.1.1:stubs:8080"})
7.4.3. Development or Production Stubs
연동 서비스에서 제공하는 스텁stub으로 테스트할 때 classifier를 잘 활용하면, 현재 개발 중인 버전과 프로덕션에 배포된 버전 중 어떤 것을 사용할지 선택할 수 있다. 프로덕션 배포 단계에서 prod-stubs classifier로 스텁stub을 배포하도록 빌드 설정을 변경하면, 개발 환경에선 개발 스텁stub으로, 운영 환경에선 프로덕션 스텁stub으로 테스트를 실행할 수 있다.
다음은 개발 버전의 스텁stub을 사용하는 테스트 예시다:
@AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:stubs:8080"})
다음은 프로덕션 버전의 스텁stub을 사용하는 테스트다:
@AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:prod-stubs:8080"})
이런 값들은 배포 파이프라인의 프로퍼티로도 전달할 수 있다.
Next :
7.5. 컨트랙트를 프로듀서 코드와 함께 두는 대신 공통 레포지토리에 보관하려면 어떻게 해야 하나요?
공통 레포지토리에 컨트랙트 보관하기
전체 목차는 여기에 있습니다.