우리 팀은 세 가지 마이크로 서비스를 개발합니다. 이 세 가지가 함께 작동하여 비즈니스 시나리오를 제공합니다. 그들은 REST와 RabbitMQ와 통신합니다. Toby Clemson's presentation on Microservice Testing에서와 같이 보입니다.마이크로 서비스 전반의 엔드 투 엔드 테스트를 여러 개의 연속 공급 파이프 라인에 포함시키는 방법은 무엇입니까?
각 마이크로 서비스에는 고유 한 연속 배달 파이프 라인이 있습니다. 그들은 배달이 아니며 배포 파이프 라인이 아니므로 결국 수동 릴리스 결정이 있음을 의미합니다.
비즈니스 시나리오, 즉 모든 마이크로 서비스에서 엔드 투 엔드 테스트를 딜리버리 파이프 라인에 포함하려면 어떻게해야합니까?
우리는 하나 이 세 microservices을 배포하고 그들에 대한 엔드 - 투 - 엔드 테스트를 실행 엔드 - 투 - 엔드 무대를 공유 추가
내 팀이 제안했다. 파이프 라인 중 하나가이 단계에 도달 할 때마다 배포 및 테스트가 진행됩니다. 세마포어는 파이프 라인이 차례대로 스테이지를 통과하도록 보장합니다. 실패는 3 개의 파이프 라인 모두를 정지시킵니다.
엔드 - 투 - 엔드 단계는 병목 : 나에게
, 이것은 microservice 아키텍처는 처음에 승리 모든 독립성을 희생 것으로 보인다. 빠른 파이프 라인은 느린 파이프 라인을 방해 할 수 있습니다. 왜냐하면 엔드 - 투 - 엔드 단계를 더 자주 예약하기 때문에 다른 테스트 단계를 기다릴 수 있기 때문입니다.
하나의 파이프 라인에서 오류가 발생하면 다른 파이프 라인이 제공되지 못하게되고 긴급 버그 수정을 전달하지 못하게됩니다.
이 솔루션은 마이크로 서비스의 다양한 조합이 필요한 새로운 비즈니스 시나리오에는 적용되지 않습니다. 우리는 모든 마이크로 서비스를 연결하는 수퍼 스테이지로 끝나거나 각각의 비즈니스 시나리오는 자체적 인 새로운 엔드 - 투 - 엔드 단계를 필요로합니다.
엔드 투 엔드 단계는 마이크로 서비스 버전의 정확한 조합이 함께 작동한다는 것을 확인하기 때문에 좁은 결과 만 보여줍니다. 프로덕션에 다른 버전이 포함되어있는 경우에도 이것이 작동한다는 보장은 없습니다.
무대도 수동 릴리스 결정과 충돌합니다. 빌드가 종단 간을 넘긴 경우에도 프로덕션으로 릴리스하지 않으면 어떻게 될까요? 생산에는 종단 간 전자 서비스와 다른 버전이 포함되어 뒤틀린 결과가 발생합니다.
이 작업을 수행하는 더 좋은 방법은 무엇입니까?
광범위하게 동의합니다. 이 제안서에있는 문제는 특정 비즈니스 사례가 충족되지 않으면 소프트웨어를 공개하고 싶지 않다는 기본 가정을 작성한다는 것입니다. 나는 비즈니스 케이스 테스트를 파이프 라인 외부에 배치하고 주기적으로 실행하고 싶다. 실패는 각 서비스의 백 로그에 대한 이슈로 제기되어야합니다. –