끌어오기 요청 상태 사용하여 끌어오기 요청 워크플로 사용자 지정 및 확장

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

끌어오기 요청은 리포지토리 내에서 코드 검토를 용이하게 하고 코드 이동을 관리하기 위한 훌륭한 도구입니다. 분기 정책은 모든 코드 변경에 대해 수행해야 하는 요구 사항을 설정하여 끌어오기 요청 프로세스 중에 코드 품질을 적용합니다. 이러한 정책을 통해 팀은 코드 검토 및 자동화된 빌드 실행과 관련된 많은 모범 사례를 적용할 수 있지만, 많은 팀에는 코드에서 수행할 추가 요구 사항 및 유효성 검사가 있습니다. 이러한 개별 및 사용자 지정 요구 사항을 충족하기 위해 Azure Repos는 끌어오기 요청 상태 제공합니다. 끌어오기 요청 상태 PR 워크플로에 통합되고 외부 서비스가 간단한 성공/실패 유형 정보를 끌어오기 요청과 연결하여 코드 변경에 프로그래밍 방식으로 로그오프할 수 있도록 합니다. 필요에 따라 외부 서비스가 변경을 승인할 때까지 끌어오기 요청을 차단할 수 있습니다.

PR 워크플로에 통합하려면 다음과 같은 몇 가지 다른 개념이 포함됩니다.

• 끌어오기 요청 상태 - 서비스에서 성공/실패 정보를 끌어오기 요청과 연결하는 방법을 제공합니다.
• 상태 정책 - 끌어오기 요청 상태 성공을 나타내기 전까지 끌어오기 요청 완료를 차단하는 메커니즘을 제공합니다.
• 사용자 지정 작업 - Azure DevOps Services 확장을 사용하여 상태 메뉴를 확장하는 방법을 제공합니다.

이 항목에서는 끌어오기 요청 상태 및 PR 워크플로에서 통합하는 데 사용할 수 있는 방법에 대해 알아봅니다.

끌어오기 요청 상태

끌어오기 요청 상태 서비스가 상태 API를 사용하여 간단한 성공/실패 유형 정보를 끌어오기 요청과 연결하는 방법을 제공합니다. 상태 네 가지 주요 데이터 요소로 구성됩니다.

• 상태입니다. 미리 정의된 상태 중 하나: succeeded, failed, pending, notSetnotApplicable또는 error.
• 설명. 최종 사용자에 대한 상태 설명하는 문자열입니다.
• 컨텍스트. 일반적으로 상태 게시하는 엔터티를 설명하는 상태 이름입니다.
• URL. 사용자가 상태 관련된 자세한 정보를 가져올 수 있는 링크입니다.

기본적으로 상태 사용자 또는 서비스가 끌어오기 요청에 대한 평가를 게시하고 다음과 같은 질문에 대한 답변을 제공하는 방법입니다.

• 변경 내용이 요구 사항을 충족했나요?
• 요구 사항을 충족하기 위해 해야 할 일에 대해 자세히 알아볼 수 있는 위치는 어디인가요?

예를 살펴보겠습니다. 프로젝트의 모든 코드 변경 내용을 빌드하는 데 필요한 CI 서비스를 고려합니다. 해당 서비스가 끌어오기 요청의 변경 내용을 평가할 때 빌드 및 테스트 결과를 다시 게시해야 합니다. 빌드를 통과하는 변경 내용의 경우 다음과 같은 상태 PR에 게시될 수 있습니다.

{
    "state": "succeeded",
    "description": "CI build succeeded",
    "context": {
        "name": "my-ci-system",
        "genre": "continuous-integration"
    },
    "targetUrl": "http://contoso.com/CI/builds/1"
}

이 상태 PR 세부 정보 보기에서 최종 사용자에게 표시됩니다.

• 아이콘state(녹색 검사, 빨간색 X, succeededfailed시계pending, 빨간색 ! for error)을 사용하여 사용자에게 표시됩니다.
• 아이콘 description 옆에 표시되며 context 도구 설명에서 사용할 수 있습니다.
• A가 targetUrl 적용되면 설명이 URL에 대한 링크로 렌더링됩니다.

업데이트 상태

서비스는 추가 상태 게시하여 단일 PR에 대한 PR 상태 업데이트할 수 있으며, 그 중 최신 항목만 각 고유context에 대해 표시됩니다. 여러 상태 게시하면 사용자가 기대치를 관리하는 데 도움이 됩니다. 예를 들어 상태 게시 pending 하는 것은 시스템에서 이벤트를 수신하고 작업을 시작하고 있음을 사용자에게 인정하는 좋은 방법입니다. 다음 예제와 같은 정보를 description 사용하면 사용자가 시스템의 작동 방식을 이해하는 데 도움이 될 수 있습니다.

• "빌드 대기 중"
• "빌드 진행 중"
• "빌드 성공"

반복 상태

PR의 원본 분기가 변경되면 최신 변경 내용을 추적하기 위해 새 "반복"이 만들어집니다. 코드 변경 내용을 평가하는 서비스는 PR의 각 반복에 새 상태 게시하려고 합니다. PR의 특정 반복에 상태 게시하면 상태 평가된 코드에만 적용되고 향후 업데이트는 적용되지 않습니다.

참고 항목

만드는 PR에 100,000개 이상의 수정된 파일이 포함된 경우 성능 및 안정성상의 이유로 해당 PR은 반복을 지원하지 않습니다. 즉, 이러한 PR에 대한 추가 변경 내용이 포함되지만 해당 변경에 대한 새 반복은 생성되지 않습니다. 또한 존재하지 않는 반복에 대한 상태 만들려는 시도는 오류를 반환합니다.

반대로 게시된 상태 코드와 관계없이 전체 PR에 적용되는 경우 반복에 게시할 필요가 없을 수 있습니다. 예를 들어 작성자(변경할 수 없는 PR 속성)가 특정 그룹에 속한다는 검사 한 번만 평가하면 되고 반복 상태 필요하지 않습니다.

상태 정책을 구성할 때 반복 상태 사용하는 경우 새 변경 내용이 있을 때마다 다시 설정 조건을 상태 다시 설정해야 합니다. 이렇게 하면 최신 반복succeeded에 상태 때까지 PR을 병합할 수 없습니다.

반복 및 끌어오기 요청에 상태 게시하는 REST API 예제를 참조하세요.

상태 정책

상태 단독으로 사용하면 PR 환경 내의 사용자에게 외부 서비스의 세부 정보를 제공할 수 있습니다. 경우에 따라 PR에 대한 정보를 공유하는 것이 모두 필요하지만, 다른 경우에는 요구 사항이 충족될 때까지 PR의 병합을 차단해야 합니다. 기본 정책과 마찬가지로 상태 정책은 요구 사항이 충족될 때까지 외부 서비스가 PR 완료를 차단하는 방법을 제공합니다. 정책이 필요한 경우 끌어오기 요청을 완료하기 위해 전달해야 합니다. 정책이 선택 사항인 경우 정보 전용이며 끌어오기 요청을 완료하기 위해 상태 succeeded 필요하지 않습니다.

상태 정책은 다른 분기 정책과 마찬가지로 구성됩니다. 새 상태 정책을 추가할 때 상태 정책의 이름과장르를 입력해야 합니다. 상태 이전에 게시된 경우 목록에서 선택할 수 있습니다. 새 정책인 경우 형식 장르/이름으로 정책 이름을 입력할 수 있습니다.

상태 정책을 지정하는 경우 이 정책을 통과하려면 선택한 이름과 일치하는 상태 succeededcontext 있어야 합니다.

권한 있는 계정을 선택하여 특정 계정에 정책을 승인할 상태 게시할 권한이 있어야 할 수도 있습니다.

정책 적용 가능성

정책 적용 가능성 옵션은 끌어오기 요청을 만드는 즉시 이 정책이 적용되는지 또는 첫 번째 상태 끌어오기 요청에 게시된 후에만 정책이 적용되는지 여부를 결정합니다.

1. 기본적으로 적용 - 끌어오기 요청이 만들어지는 즉시 정책이 적용됩니다. 이 옵션을 사용하면 상태 게시될 때까지 succeeded 끌어오기 요청을 만든 후에 정책이 전달되지 않습니다. PR은 정책 요구 사항을 제거하는 상태 notApplicable게시하여 정책에서 제외된 것으로 표시될 수 있습니다.

2. 조건부 - 첫 번째 상태 끌어오기 요청에 게시될 때까지 정책이 적용되지 않습니다.

이러한 옵션을 함께 사용하여 동적 정책 모음을 만들 수 있습니다. PR이 해당 정책에 대해 평가되는 동안 최상위 "오케스트레이션" 정책을 기본적으로 적용하도록 설정할 수 있습니다. 그런 다음 추가 조건부 정책이 적용되도록 결정되면(특정 빌드 출력에 따라) 상태 게시하여 필요할 수 있습니다. 이 오케스트레이션 정책은 평가가 완료되면 표시 succeeded 되거나 정책이 적용되지 않음을 PR에 표시하도록 표시 notApplicable 될 수 있습니다.

사용자 지정 작업

PR 상태 업데이트하기 위해 서비스를 트리거할 수 있는 미리 정의된 서비스 후크 이벤트 외에도 Azure DevOps Services 확장을 사용하여 최종 사용자에게 트리거 작업을 제공하여 상태 메뉴를 확장할 수 있습니다. 예를 들어 상태 최종 사용자가 다시 시작할 수 있는 테스트 실행에 해당하는 경우 실행을 트리거하는 상태 메뉴에 다시 시작 메뉴 항목이 있을 수 있습니다. 상태 메뉴를 추가하려면 기여 모델을 사용해야 합니다. 자세한 내용은 Azure DevOps 확장 샘플을 참조 하세요.

다음 단계

PR 상태 API에 대해 자세히 알아보고 방법 가이드를 검사.

• Node.js 사용하여 끌어오기 요청 상태 서버 만들기
• Azure Functions를 사용하여 사용자 지정 분기 정책 만들기
• 외부 서비스에 대한 분기 정책 구성