MSA - 의존성 관리 방법

less than 1 minute read

Global Dependency Dictionary System 정도로 불러도 되려나

MSA로 서비스를 구성할 때 발생하는 문제가

어떤 서비스를 Deprecated를 시켰을 때 이전 버전을 언제까지 유지시켜야 할지가 애매하다.

즉각적으로?

한달이상 호출이 없을 때?

모니터링 툴 돌리다가 수동으로?

그냥 소스코드 내부에 /v1 /v2 /v20171001 같은식으로 계속 유지시켜버릴까?

이런 방법은 다 확살하지 않거나 관리가 불편하거나 다양한 문제가 있다.

디비를 변경해야 하는경우에 버전업을 할 때 오류발생 가능성도 있고

 

배포시에 사전을 만들고 의존성을 갖는 프로젝트간의 관계를 가지고 있는게 좋을 것 같다.

일반적인 형태의 라이브러리나 프레임워크로 만들기는 힘들 것 같고

규칙성을 갖게 버저닝을 하고 배포를 해야할 것 같다.

v{메인버전_호환안될수있음}-버그픽스

v1_20171001-1

v1_20171001-2

버전 표기방식으로 흔히 쓰는건 이정도 아닌가

 

버그픽스버전의 경우

3번째칸은 변경되도 호환성에 문제가 없어야하고 1,2번칸이 변경될 경우 호환이 안될 가능성이 생기는걸로

버그픽스 버전이 배포되는 경우 유닛테스트 실행. 이상이 없어야만 배포허용.

 

버전업이 되는 경우

배포시 의존성을 갖는 서비스의 관리자에게 알림이 가고

유닛테스트가 실행. 오류가 나면 오류알림(해당서비스와 의존성을 갖는 서비스의 담당자)

의존성을 갖는 서비스의 담당자는 일정시일(1개월?)이내에 업데이트 권장

긴급수정 사항은 바로 업데이트

 

이 경우 배포툴에 각 개발자의 정보가 담겨있어야한다.