프로덕션 전 대량 테스트 API - Azure Durable Functions가 포함된 Azure DevOps 릴리스 게이트하는 방법

프로덕션 전 대량 테스트 API - Azure Durable Functions가 포함된 Azure DevOps 릴리스 게이트하는 방법

 

API를 일괄적으로 검증하고 검증 후 자동으로 애플리케이션을 프로덕션 환경으로 릴리스

Unsplash의 Mikhail Fesenko 사진

개발자는 Azure DevOps의 릴리스 파이프라인을 통해 여러 단계에 걸쳐 애플리케이션을 배포할 수 있습니다. 릴리스 파이프라인은 DevOps 엔지니어가 빌드 프로세스, 단위 테스트, 통합 테스트 등과 같은 자동화된 작업 및 작업을 정의할 수 있는 방식과 유사합니다.

작업 외에도 패키지가 다음 단계로 진행되기 전에 배포 전 조건 확인 및 배포 후 조건 확인을 정의할 수도 있습니다. 아래 다이어그램은 흐름을 시각적으로 보여줍니다.

출처: https://docs.microsoft.com/en-us/azure/devops/pipelines/release/approvals/?view=azure-devops

조건에서 선택한 구성원의 승인이 필요한 사람의 개입을 정의하거나 배포를 릴리스하기 전에 조건을 확인하기 위해 수행할 수 있는 여러 자동화 작업이 있는 게이트를 정의할 수 있습니다.

이 기사는 릴리스 게이트에 초점을 맞출 것입니다. 릴리스 게이트는 규정 준수 여부를 확인하거나 애플리케이션 기능 또는 준비 상태에 대한 유효성 검사 여부에 관계없이 배포 후 문제를 줄이는 데 도움이 될 수 있는 추가 검사 계층을 보장할 수 있습니다.

시나리오

자동화된 테스트 단계의 일부로 개발자는 종종 파이프라인 내에 자동화된 단위 테스트 및 통합 테스트를 포함합니다. 기능 테스트 측면에서 자동화된 방법과 테스터가 테스트를 수행하도록 하는 방법이 혼합되어 있습니다. 상당히 일반적인 기능 테스트는 REST API 호출을 수행하여 서비스가 의도한 대로 작동하는지 확인하는 것입니다.

시스템용 API 호출 외에도 외부 API 호출(예: 외부 끝점 상태 확인, 규정 준수 확인 등)이 포함될 수도 있습니다.

아래 다이어그램과 같이 릴리스 게이트 아래에서 사용할 수 있는 몇 가지 옵션이 있습니다.

Azure 정책 준수 확인은 일반적으로 고객이 조직 표준을 준수하는 환경에서 워크로드를 배포할 수 있도록 하는 데 사용됩니다. 일반 연결 또는 Azure Functions를 통해 API를 호출할 수도 있습니다. 마지막으로 Azure Monitor 경고 및 작업 항목을 쿼리하는 것도 새 환경에 대한 릴리스가 특정 표준을 따르도록 하는 데 중요합니다. 릴리스 게이트에 대한 자세한 내용은 https://docs.microsoft.com/en-us/azure/devops/pipelines/release/approvals/gates?view=azure-devops에서 확인할 수 있습니다.

REST API에 대한 일반 연결을 정의하는 것은 간단합니다. 프로젝트 설정에서 서비스 연결을 만들고 서버 URL과 인증 세부 정보를 정의하면 됩니다.

이것은 여러 API에서 작동합니다. 우리는 그것들을 하나씩 정의할 수 있습니다. 20개, 30개 또는 그 이상의 API는 어떻습니까?

그러면 파이프라인 내에서 하지 않는 이유가 궁금할 것입니다. 예, 파이프라인 내에 이 활동을 포함할 수 있습니다. 여기서 주요 차이점은 결과 조건을 정의하고 사람의 승인에 대한 수동 개입과 함께 배포를 다음 단계 또는 환경으로 진행할 수 있는지 여부를 결정하는 기능입니다.

서비스 연결로 돌아갑니다. 다이어그램에서 볼 수 있듯이 효과적으로 엔드포인트를 하나씩 정의해야 하며, 이는 10개 이상의 엔드포인트를 호출하는 경우에는 불가능합니다. 그러면 모든 API 호출을 조정하고 응답을 집계하여 릴리스 게이트 역할을 하는 방법이 있습니까?

솔루션

Azure Functions는 마이크로 서비스 워크로드에서 자주 사용되는 "Functions-As-A-Service"에 대한 서버리스 컴퓨팅으로 잘 알려져 있습니다. 일반적으로 상태가 없고 수명이 짧습니다. 반면 Azure Durable Functions는 Azure Functions의 이점 외에도 상태 저장 작업을 처리하기 위한 것입니다. 특히 Azure Durable Functions는 작업을 병렬로 또는 정의된 순서로 수행하는 오케스트레이터 역할을 하는 데 탁월합니다. 다양한 사용 사례에 대한 Azure Durable Functions에 대한 많은 애플리케이션 패턴이 있으며 여기에 문서화되어 있습니다. https://docs.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-overview?tabs=csharp

이 컨텍스트에서 이 사용 사례에 대해 Fan out/fan in 패턴을 사용할 수 있습니다. 아이디어는 간단합니다. 오케스트레이터를 호출하면 REST API 목록을 호출하고 마지막으로 결과를 집계하고 출력으로 반환합니다.

이것이 어떻게 작동하는지 자세히 봅시다.

Azure 내구성 기능 오케스트레이터

템플릿부터 시작하겠습니다. VS Code 또는 Visual Studio를 사용하여 Azure Functions 템플릿을 선택할 수 있으며 이 경우에는 내구성 기능 오케스트레이션 출발점으로. 다음 템플릿이 생성됩니다.

3가지 기능을 생성합니다.DurableFunctionsOrchestration", "DurableFunctionsOrchestration_Hello", 그리고 "DurableFunctionsOrchestration_HttpStart". 바닥부터 이해합시다.

"DurableFunctionsOrchestration_HttpStart"는 워크플로의 진입점으로 정의되며 내구성 있는 클라이언트 역할을 합니다. 27행에서 볼 수 있듯이 HTTP Trigger를 사용하고 있습니다. 이것이 의미하는 바는 HTTP GET 또는 HTTP Post를 수락하고 오케스트레이션 흐름을 시작한다는 것입니다. 물론 사용 사례에 따라 타이머 트리거, Azure Service Bus 트리거 등과 같은 다른 트리거도 정의합니다. 다음은 사용 가능한 바인딩 목록이며 트리거에 지원되는 바인딩을 사용할 수 있습니다.

이 예에서는 HTTP 트리거를 사용하겠습니다. 호출하기 쉽고 이 HTTP 트리거는 이 경우에 필요한 오케스트레이션 상태, 출력 등과 같은 오케스트레이션 세부 정보를 HTTP 응답으로 반환합니다.

"로 이동합시다.DurableFunctionsOrchestration". 이름에서 알 수 있듯이 이 기능은 활동을 조정합니다. 이전 활동의 출력에 따라 비동기 모드로 실행하거나 직렬로 실행하는 것과 같이 활동이 오케스트레이션되는 방식을 정의할 수 있습니다. 위의 예에서 10행에서 12행까지는 단순히 활동을 직렬로 트리거하여 기능 연결을 수행합니다. 위에서 언급한 6가지 패턴 중 하나를 디자인하는 곳입니다.

"에서 타겟 활동DurableFunctionsOrchestration"라고 "DurableFunctionsOrchestration_Hello", 문자열을 입력으로 사용합니다. 여기에서 모든 무거운 물건을 들어 올리는 작업이 수행됩니다.

우리의 시나리오로 돌아갑니다. 아이디어는 상태 및 출력의 유효성을 검사하고 결과를 다시 Azure Pipeline 릴리스 게이트로 반환하기 위해 여러 API 호출을 실행하는 것을 목표로 하는 함수를 만드는 것입니다.

이제 Azure Durable Functions에 대한 아이디어를 얻었으므로 이 시나리오에서 구현하는 방법을 살펴보겠습니다. 모든 무거운 작업을 수행하는 기능인 활동부터 시작하겠습니다.

나는 이름을 지었다 HealthCheck_Executor. 데모 목적으로 백엔드 API에 에코를 수행하고 반환된 메시지가 내 입력과 동일한지 확인했습니다. 내가 한 유일한 추가 작업은 APICheckObject, API 이름 및 상태를 캡처합니다. 나중에 모든 결과를 집계하기를 원하므로 1 또는 0을 수행하는 것이 간단한 방법이며 동시에 어떤 API가 의도한 대로 작동하지 않는지 식별할 수 있습니다.

다음으로 오케스트레이터로 넘어가겠습니다. 해결해야 할 첫 번째 질문은 올바른 패턴을 사용해야 하는 것입니다. 기능 연결 및 팬 아웃/팬 인이 실행 가능한 후보인 것 같습니다.

예를 들어, 두 번째 API는 첫 번째 API의 출력에 따라 달라집니다. 제 경우에는 모든 API가 서로 독립적이므로 팬아웃/팬인을 선택하여 모든 실행을 더 짧은 실행 시간 동안 병렬화합니다.

그런 다음 결과를 전체 프로세스의 출력으로 개체 목록으로 반환합니다.

퍼즐의 마지막 조각은 이 내구성 함수를 호출하는 방법입니다. 나는 HTTP 트리거를 고수할 것이지만 한 가지가 더 필요합니다. 이 지속 기능을 직접 호출하면 주로 상태를 확인하거나 작업을 종료하기 위해 여러 URL을 반환합니다. Azure Pipeline 릴리스 게이트는 출력을 사용할 수 없습니다.

이 문제를 해결하기 위해 HTTP 트리거를 사용하여 다른 Azure Functions를 만들고 이 내구성 함수를 호출하는 동시에 Azure DevOps에서 유효성 검사를 위해 출력을 집계할 수 있습니다.

전체 소스 코드는 GitHub에서 찾을 수 있습니다.

Azure Pipeline 릴리스 게이트 유효성 검사

위의 Azure Functions의 출력을 살펴보겠습니다. 총 성공 호출과 해당 API 이름 및 상태가 있습니다.

{
"totalSuccess":3,
"details":[
{"apiName":"test1","apiStatus":1},
{"apiName":"test2","apiStatus":1}, 
{"apiName":"test3","apiStatus":1}
]
}

Azure Pipeline에서 릴리스 파이프라인으로 이동하여 릴리스 게이트를 수정해 보겠습니다. 릴리스 게이트에 Azure Functions를 추가하기 위해 사전 배포 또는 사후 배포를 진행할 수 있습니다. 제 경우에는 사후 배치로 이동합니다. Azure Functions를 추가하는 것은 간단합니다. 왼쪽 상단의 "Gates" 아래에 있는 "+ Add"를 클릭하고 Azure Functions URL과 Azure Functions Key를 입력하기만 하면 됩니다. 키를 검색할 위치를 모르는 경우 Azure Portal 내부에 있습니다.

방금 API 응답을 보여주었고 이제 이 배포 후 확인의 성공 기준을 정의할 수 있습니다. 성공한 호출의 총 수를 확인하고 성공 호출이 내 매개변수 내에 있으면 확인이 통과됩니다. 문서에서 조건을 정의하는 다른 방법에 대해 자세히 알아볼 수 있습니다.

다음은 내 릴리스 게이트의 모습입니다.

유효성을 확인하려면 릴리스를 만들고 로그를 확인하기만 하면 됩니다. 상태가 5분 간격으로 두 번 확인됨을 알 수 있습니다. 위의 배포 게이트 페이지에서 매개변수를 정의할 수 있습니다.

아래 다이어그램은 전체 흐름을 시각화합니다.

이제 API를 일괄적으로 검증할 수 있으며 검증 후 자동으로 애플리케이션을 프로덕션 환경으로 릴리스할 수 있습니다!