마이크로 서비스로 지속적인 배송을 관리하는 방법은 무엇입니까?

Question

지금 우리는 Jenkins와 CI 및 CD로 협력하고 있으며 Agile 방법론 (스프린트)도 사용하고 있습니다. 내 소프트웨어의 릴리스를 어떻게 관리 할 수 ​​있는지 궁금합니다.

예를 들어 우리는 비즈니스를위한 쇼핑 사이트를 개발 중입니다. 개발은 3 마이크로 서비스를 사용하는 응용 프로그램으로 구성됩니다.

구성 요소 :

응용 프로그램 : 판매
마이크로 서비스 2 : 사용자
마이크로 서비스 3 :의 제품

초기 상태의 사용자 인터페이스를
마이크로 서비스 1 쇼핑 사이트 :

처음부터 쇼핑 사이트를 개발하기 시작합니다. 전에 우리가 Agile Methodology (Sprints)로 작업하기 전에 말했던 것처럼.

스프린트 1 :
- 제품 마이크로 서비스를 개발하십시오.
- 사용자 마이크로 서비스를 개발하십시오. 내가 테스트를 끝과 끝을 할 수없는 응용 프로그램이 준비 나하지 않기 때문에이 시간까지

스프린트 1
끝 난 단지 단위 테스트, 계약 테스트 등과 같은 마이크로 서비스 테스트를 적용 할 수 있습니다 전체 시스템을 기반으로 한 기능 테스트는 UAT 환경 (사용자에게 베타 버전 표시)에 배포 할 수 없습니다. 사용자가 탐색 테스트를 수행 할 수 없기 때문입니다. 따라서 지금은 애플리케이션 및 판매용 마이크로 서비스가 끝날 때까지 기다려야하므로 베타 버전을 사용자에게 보여줄 수 있고 다른 유형의 테스트를 적용 할 수 있습니다.

스프린트 2 :
- 영업 마이크로 서비스를 개발하십시오.
- 응용 프로그램을 개발하십시오. 이제 필요한 모든 구성 요소는 사용자의 요구 사항을 달성하기 위해 완료되어

스프린트 2의
끝, 우리는 파이프 라인을 계속할 수 있습니다. 우리가 베타 버전을 보여주기 전에 필요한 모든 테스트를 사용자에게 적용합니다.

그래서 백만 달러의 질문은 젠킨스와 기트 랩에서 어떻게이 시나리오를 수행 할 것인가입니다.

마이크로 서비스는 시스템의 모든 구성 요소에 독립적이어야한다는 것을 알고 있지만 결국 시스템이 서로 의존합니다. 예를 들어 "배송"과 같은 새로운 마이크로 서비스를 추가하는 경우이 새로운 기능은 다음과 같아야합니다. 따라서 새로운 시스템을 출시하기 전에 마이크로 서비스 및 응용 프로그램 인터페이스를 "제공"하는 데 의존해야한다는 것을 의미합니다. 두 가지 개발 없이는 프로덕션 환경에 배포하기 전에 사용자 요구 사항을 완전히 테스트 할 수 없기 때문입니다.

P. 이 글에 혼란스러워서 죄송 합니다만,이 주제에 대해 새롭게 완성되었습니다.

Answer 1

마이크로 서비스의 "독립적 인"측면은 여기에서 필수적입니다.기본적으로 각 서비스를 독립 실행 형 응용 프로그램으로 취급 할 수 있어야하며 UI는 판매/사용자/제품 서비스를 "libs"(예 : C# DLL, Java Jars 등)로 의존해서는 안되며 대신 서로를 호출하는 API (예 : REST API).

을하지만 그 대신이 같은이 있어야합니다

차이를 설명하기 위해이 없어야합니다.

이제 당신은 당신의 UI와 각 서비스 사이의 REST API를 사용하여 멋진 microservices 세계에있는 가정하자.

젠킨스에서는 다소 단순 해집니다. 각 서비스 (+ 기본 응용 프로그램)에 대해 이 대상 서버에서 서비스를 컴파일, 테스트 및 배포하는 작업을 원합니다.

는만큼 당신의 서비스는 독립적으로 당신은 응용 프로그램이 제대로 versionning 처리 할 경우, 당신은 당신의 젠킨스 작업의 사이에 동기화 어떤 종류의 필요가 없습니다.

물론 빌드/테스트/배포 프로세스는 공통 파이프 라인 파일에 외부화되므로 다른 작업에서 다시 사용할 수 있습니다. 새로운 판매 끝점을 사용하는 UI 부분을 커밋하기 전에 판매 서비스에 새로운 API 끝점을 설정하면됩니다 ...하지만 나는 상식 일뿐입니다!

젠킨스를 처음 접한다면, 좋은 출발은 pipeline documentation입니다!