2016-10-08 4 views
0

스프링 부트로 빌드 된 마이크로 서비스의 릴리스 관리 방법에 대한 조언을 찾고 있습니다.스프링 부트 및 릴리스 관리가있는 마이크로 서비스

내가 만든 프로젝트 중 대부분은 릴리스 플러그인 (maven)을 사용하여 태그를 만들고 maven 프로젝트 (jar, war, rpm)를 릴리스합니다. 일반적으로 이것은 배포 프로세스 동안 모든 하위 프로젝트 (jar, war)에 대한 상위/하위 관계에 의존합니다 (모 놀리스 소스 코드, 모두 단일 git 저장소에 있음). 사람들이 다른 부트 프로젝트 (마이크로 서비스)를 어떻게 유지하고 릴리즈를 수행하는지 궁금합니다. 출시 독립적으로 관리되도록 자식 저장소 당

  1. 한 봄 부트 프로젝트 (microservice 받는다는 프로젝트) :

    내가 볼때, 다음과 같은 가능한 전략이다.

  2. 각 모듈이 마이크로 서비스 인 다중 모듈 메이븐 프로젝트. 모든 서브 모듈 (마이크로 서비스)은 함께 릴리스되어야합니다. 상위 폼은 부트의 상위 폼을 사용해야합니다.
  3. 릴리즈를 기반으로 특정 하위 모듈 만 릴리스하는 maven-release-plugin 기능을 사용합니다. 이렇게하면 각 Maven 하위 모듈의 버전이 달라집니다 (잠재적으로).

팀에서 유용하다고 생각한 점은 무엇입니까? 나는 Boot의 프로그래밍 모델을 좋아하지만, Boot model로 일관된 릴리즈 전략을 사용하여 작업을 단순하게 유지할 수 있기를 희망한다.

+0

나를 위해 단 하나만 유효한 포인트입니다. 요점 2에서와 같이 일하면 마이크로 서비스를 수행해야 할 필요가 없거나 함께 배포해야하는 경우 마이크로 서비스를 수행 할 필요가 없습니다. – dunni

+0

나는 마이크로 서비스가 추가됨에 따라 이것이 커질 것이라는 점에 동의한다. 따라서 마이크로 서비스 릴리스 관리를 복잡하게 만든다. 많은 통합 테스트 및 회귀 테스트. – Alberto

+0

물론 가능합니다. 이는 마이크로 서비스 아키텍처의 단점이므로이를 처리 할 수 ​​있어야합니다 (예 : 고도로 자동화 된 인프라가 있어야 함). – dunni

답변

0

루프를 닫으려면 옵션 1을 사용하고 있습니다. 여러 저장소가있는 것처럼 보일 수 있지만 마이크로 서비스 아키텍처를 구현하면이 릴리스 관리 프로세스를 단순하게 만드는 좋은 devops 프로세스가 배제됩니다.