승인 및 검사 정의

Azure DevOps Services

파이프라인은 스테이지로 구성됩니다. 파이프라인 작성자가 스테이지에서 조건을 정의하여 스테이지를 실행할지 여부를 제어할 수 있습니다. 스테이지가 실행되어야 하는지와 시기를 제어하는 또 다른 방법은 승인 및 검사 통해서입니다.

승인 및 기타 검사 yaml 파일에 정의되지 않습니다. 파이프라인 yaml 파일을 수정하는 사용자는 스테이지를 시작하기 전에 수행된 검사 수정할 수 없습니다. 관리 리소스의 주체는 Azure Pipelines의 웹 인터페이스를 사용하여 검사 관리합니다.

파이프라인은 환경, 서비스 연결, 에이전트 풀, 변수 그룹 및 보안 파일과 같은 리소스를 사용합니다. 검사를 통해 리소스 소유자는 파이프라인의 단계가 리소스를 사용할 수 있는지와 시기를 제어할 수 있습니다. 리소스의 소유자는 해당 리소스를 사용하는 단계를 시작하기 전에 충족해야 하는 검사 정의할 수 있습니다. 예를 들어 환경에 대한 수동 승인 검사 지정된 사용자가 배포되는 변경 내용을 검토한 후에만 해당 환경에 배포되도록 합니다.

스테이지는 여러 작업으로 구성되며 각 작업은 여러 리소스를 사용할 수 있습니다. 스테이지 실행을 시작하기 전에 해당 단계에서 사용되는 모든 리소스에 대한 모든 검사 충족해야 합니다. Azure Pipelines는 각 단계 전에 파이프라인 실행을 일시 중지하고 보류 중인 모든 검사 완료될 때까지 기다립니다.

승인 및 검사 5개 범주가 있으며 각 범주 내에서 생성된 순서대로 실행됩니다. 검사는 각 검사 지정된 재시도 간격에 따라 다시 평가됩니다. 제한 시간이 지정될 때까지 모든 검사 성공하지 못하면 해당 단계가 실행되지 않습니다. 검사 중 하나라도 실패하는 경우(예: 리소스 중 하나에 대한 승인을 거부하는 경우) 해당 단계가 실행되지 않습니다. 그러나 승인 및 검사 시간이 초과되면 단계를 다시 시도할 수 있습니다.

정적 검사 먼저 실행된 후 사전 검사 승인이 실행됩니다. 순서대로 범주는 다음과 같습니다.

1. 정적 검사: 분기 컨트롤, 필수 템플릿 및 아티팩트 평가
2. 사전 검사 승인
3. 동적 검사: 승인, Azure 함수 호출, REST API 호출, 업무 시간, Azure Monitor 경고 쿼리
4. 검사 후 승인
5. 배타적 잠금

승인 및 검사 탭에서 실행 순서를 볼 수도 있습니다.

Important

환경, 서비스 연결, 리포지토리, 변수 그룹, 보안 파일 및 에이전트 풀에서 검사를 구성할 수 있습니다.

서비스 연결은 변수로 지정할 수 없습니다.

승인

승인 및 검사 사용하여 스테이지가 실행되는 시기를 수동으로 제어할 수 있습니다. 이 검사 일반적으로 프로덕션 환경에 대한 배포를 제어하는 데 사용됩니다.

1. Azure DevOps 조직에 로그인한 다음 프로젝트로 이동합니다.

2. 파이프라인>환경을 선택한 다음, 환경을 선택합니다.

3. 승인 및 검사 탭을 선택한 다음, 기호를 + 선택하여 새 검사 추가합니다.

   

4. 승인 선택한 다음, 다음을 선택합니다.

5. 사용자 또는 그룹을 지정된 승인자로 추가하고 원하는 경우 승인자에 대한 지침을 제공합니다. 승인자가 자신의 실행을 승인하지 못하도록 허용하거나 제한할지 여부를 지정하고 원하는 시간 제한을 지정합니다. 지정된 시간 제한 내에 승인이 완료되지 않으면 스테이지는 건너뛴 것으로 표시됩니다.

6. 완료되면 만들기를 선택합니다.

   

7. 승인 검사 트리거되면 아래 예제와 같이 프롬프트 창이 사용자 인터페이스에 표시됩니다. 이 창에서는 승인자가 함께 제공되는 지침과 함께 실행을 거부하거나 승인하는 옵션을 제공합니다.

   

승인을 검토할 수 있는 사용자 목록은 승인 및 검사 실행이 시작될 때 수정됩니다. 즉, 검사 실행이 시작된 후 완료된 승인 검사 사용자 및 그룹 목록에 대한 변경 내용은 선택되지 않습니다.

참고 항목

그룹이 승인자로 지정된 경우 그룹 내의 한 사용자만 실행을 승인해야 실행이 진행됩니다.

지연된 승인

승인이 지정된 시간과 배포를 시작해야 하는 시간이 일치하지 않는 경우가 있습니다. 예를 들어 저녁에 트래픽이 적은 시간이 될 때까지 새 릴리스 배포를 기다리는 것이 좋습니다.

이 시나리오를 해결하기 위해 승인을 연기하고 승인이 적용되는 시간을 설정할 수 있습니다.

1. 승인 연기를 선택합니다.

   

2. 승인 시간을 설정합니다.

   

검사 패널에서 승인이 사전 승인으로 표시됩니다. 승인은 정해진 시간에 적용됩니다.

분기 제어

분기 제어 검사 사용하여 파이프라인과 연결된 모든 리소스가 허용된 분기에서 빌드되고 분기가 보호를 사용하도록 설정되어 있는지 확인할 수 있습니다. 이 검사 릴리스 준비 상태 및 배포 품질을 제어하는 데 도움이 됩니다. 여러 리소스가 파이프라인과 연결된 경우 모든 리소스의 원본이 확인됩니다. 다른 파이프라인을 연결한 경우 배포되는 특정 실행의 분기가 보호를 위해 확인됩니다.

분기 컨트롤 검사 정의하려면 다음을 수행합니다.

1. Azure DevOps 프로젝트에서 보호해야 하는 리소스(예: 환경)로 이동합니다.

2. 리소스의 승인 및 확인으로 이동합니다.

3. 분기 컨트롤 검사 선택하고 허용된 분기의 쉼표로 구분된 목록을 제공합니다. 분기에서 보호를 사용하도록 설정할 수 있습니다. 분기 중 하나에 대한 보호 상태 알 수 없는 경우 검사 동작을 정의할 수도 있습니다.

   

런타임에 검사 허용된 목록에 대해 실행 중인 모든 연결된 리소스에 대한 분기의 유효성을 검사합니다. 분기 중 하나라도 조건과 일치하지 않으면 검사 실패하고 스테이지가 실패로 표시됩니다.

참고 항목

검사 분기 이름을 정규화해야 합니다. 분기 이름의 형식이 인지 확인합니다. refs/heads/<branch name>

업무 시간

환경에 대한 모든 배포가 특정 시간 범위에서만 수행되도록 하려는 경우 검사 업무 시간이 이상적인 솔루션입니다. 파이프라인을 실행하면 리소스를 사용하는 단계의 실행이 업무 시간 동안 대기합니다. 동시에 실행되는 여러 실행이 있는 경우 각 실행은 독립적으로 확인됩니다. 업무 시간이 시작될 때 검사 모든 실행에 성공한 것으로 표시됩니다.

업무 시간이 끝날 때 스테이지 실행이 시작되지 않은 경우(다른 검사 보류됨) 업무 시간 승인이 자동으로 철회되고 재평가가 다음 날로 예정되어 있습니다. 스테이지 실행이 검사 지정된 제한 시간 내에 시작되지 않고 스테이지가 실패한 것으로 표시되면 검사 실패합니다.

Azure 함수 호출

Azure 함수는 Azure에서 제공하는 서버리스 계산 플랫폼입니다. Azure Functions를 사용하면 애플리케이션 인프라에 대한 걱정 없이 작은 코드 조각("함수"라고 함)을 실행할 수 있습니다. 높은 유연성을 감안할 때 Azure 함수는 고유한 검사 작성할 수 있는 좋은 방법을 제공합니다. 각 실행이 http 요청 시 트리거되고, 짧은 실행 시간이 있고, 응답을 반환하도록 검사 Azure 함수의 논리를 포함합니다. 검사 정의하는 동안 응답 본문을 구문 분석하여 검사 성공했는지 유추할 수 있습니다. 평가는 제어 옵션에서 평가 사이의 시간 설정을 사용하여 주기적으로 반복될 수 있습니다. 자세한 정보

구성된 시간 제한 내에서 검사 성공하지 못하면 연결된 단계를 건너뜁습니다. 스테이지에 따라 단계도 건너뜁습니다. 자세한 내용은 Azure Function App 작업을 참조 하세요.

참고 항목

사용자 정의 파이프라인 변수는 Sprint 215부터 검사 액세스할 수 있습니다.

Azure 함수 검사 호출을 사용하는 권장 방법에 대해 자세히 알아보세요. 검사는 해당 모드 및 준수할 재시도 횟수에 따라 특정 규칙을 따라야 합니다.

REST API 호출

REST API 검사 호출하면 기존 서비스와 통합할 수 있습니다. 주기적으로 REST API를 호출하고 성공적인 응답을 반환하는 경우 계속합니다. 자세한 정보

평가는 제어 옵션에서 평가 사이의 시간 설정을 사용하여 주기적으로 반복될 수 있습니다. 구성된 시간 제한 내에서 검사 성공하지 못하면 연결된 단계를 건너뜁습니다. 스테이지에 따라 단계도 건너뜁습니다. 자세한 내용은 REST API 호출 태스크를 참조 하세요.

참고 항목

사용자 정의 파이프라인 변수는 Sprint 215부터 검사 액세스할 수 있습니다.

REST API 검사 호출을 사용하는 권장 방법에 대해 자세히 알아보세요.

Azure Monitor 경고 쿼리

Azure Monitor는 Azure 인프라 및 각 개별 Azure 리소스의 데이터에 대한 시각화, 쿼리, 라우팅, 경고, 자동 크기 조정 및 자동화를 제공합니다. 경고는 인프라 또는 애플리케이션의 상태와 관련된 문제를 감지하고 수정 작업을 수행하는 표준 수단입니다. 카나리아 배포 및 준비된 롤아웃은 중요한 애플리케이션에 대한 회귀 위험을 낮추는 데 사용되는 일반적인 배포 전략입니다. 단계(고객 집합)에 배포한 후 애플리케이션은 일정 기간 동안 관찰됩니다. 배포 후 애플리케이션의 상태는 업데이트를 다음 단계로 만들지 여부를 결정하는 데 사용됩니다.

Azure Monitor 경고를 쿼리하면 Azure Monitor를 관찰하고 배포 후 애플리케이션에 대한 경고가 발생하지 않도록 할 수 있습니다. 평가 시 활성화된 경고 규칙이 없으면 검사 성공합니다. 자세한 정보

평가는 제어 옵션에서 평가 설정 사이의 시간 후에 반복됩니다 . 스테이지가 지정된 제한 시간 내에 실행을 시작하지 않은 경우 검사 실패합니다.

필수 템플릿

필요한 템플릿 검사 사용하여 특정 YAML 템플릿을 사용하도록 파이프라인을 적용할 수 있습니다. 이 검사 있으면 참조된 템플릿에서 확장되지 않으면 파이프라인이 실패합니다.

필요한 템플릿 승인을 정의하려면 다음을 수행합니다.

1. Azure DevOps 프로젝트에서 제한하려는 서비스 연결로 이동합니다.

2. 편집 옆의 메뉴에서 승인 및 검사를 엽니다.

3. 첫 번째 검사 추가 메뉴에서 필수 템플릿을 선택합니다.

4. 필요한 템플릿 파일을 가져오는 방법에 대한 세부 정보를 입력합니다.

   • 리포지토리 유형: 리포지토리의 위치(GitHub, Azure 또는 Bitbucket)입니다.
   • 리포지토리: 템플릿을 포함하는 리포지토리의 이름입니다.
   • 참조: 필요한 템플릿의 분기 또는 태그입니다.
   • 필요한 템플릿의 경로: 템플릿의 이름입니다.

동일한 서비스 연결에 필요한 템플릿을 여러 개 가질 수 있습니다. 이 예제에서 필요한 템플릿은 .입니다 production_template.yaml.

검사 사용 안 함

검사 디버깅할 때 일시적으로 사용하지 않도록 설정한 다음 다시 사용하도록 설정할 수 있습니다. 검사 사용하거나 사용하지 않도록 설정하려면 다음을 수행합니다.

1. Azure DevOps 프로젝트에서 검사 사용하여 리소스로 이동합니다.

2. 승인 및 검사 탭을 엽니다.

3. 상황에 맞는 메뉴에서 사용 안 함 또는 사용을 선택합니다.

   

검사 무시

핫픽스 배포와 같은 일부 상황에서는 검사 무시해야 할 수 있습니다. 검사 정의된 리소스에 대한 관리자 권한이 있는 경우에만 검사 무시할 수 있습니다.

승인, 업무 시간을 우회하거나, Azure 함수를 호출하거나, REST API 검사 호출하려면 리소스가 검토를 기다리는 경우 검사 무시를 선택합니다. 다음은 검사 업무 시간을 우회하는 예입니다.

검사 무시하면 검사 패널에서 검사 우회한 사람이 표시됩니다.

아티팩트 평가

사용자 지정 정책에 대해 환경에 배포할 아티팩트를 평가할 수 있습니다.

참고 항목

현재 컨테이너 이미지 아티팩트에서만 작동합니다.

아티팩트를 통해 사용자 지정 정책 평가를 정의하려면 아래 단계를 수행합니다.

1. Azure DevOps Services 프로젝트에서 보호해야 하는 환경으로 이동합니다. 환경을 만드는 방법에 대해 자세히 알아봅니다.

   

2. 환경에 대한 승인 및 검사 이동합니다.

   

3. 아티팩트 평가 선택

   

4. 정책 정의를 붙여넣고 저장을 선택합니다. 정책 정의 작성에 대한 자세한 내용을 참조하세요.

   

파이프라인을 실행하면 환경을 사용하는 스테이지에 들어가기 전에 해당 실행의 실행이 일시 중지됩니다. 지정된 정책은 사용 가능한 이미지 메타데이터에 대해 평가됩니다. 정책이 성공하면 검사 통과하고 그렇지 않으면 실패합니다. 검사 실패하면 스테이지가 실패로 표시됩니다.

통과

파이프라인 뷰에서 정책 검사 전체 로그를 볼 수도 있습니다.

실패함

파이프라인 뷰에서 정책 검사 전체 로그를 볼 수도 있습니다.

배타적 잠금

배타적 잠금 검사 파이프라인에서 한 번만 실행할 수 있습니다. 리소스를 사용하는 해당 파이프라인의 모든 실행에서 모든 단계가 일시 중지됩니다. 잠금을 사용하는 단계가 완료되면 다른 단계에서 리소스 사용을 계속할 수 있습니다. 또한 한 단계만 계속할 수 있습니다.

잠금을 시도하는 다른 단계의 동작은 파이프라인에 lockBehavior 대한 YAML 파일에 구성된 값으로 구성됩니다.

• runLatest - 최신 실행만 리소스에 대한 잠금을 획득합니다. runLatest 는 지정되지 않은 lockBehavior 경우 기본값입니다.
• sequential - 모든 실행은 보호된 리소스에 대한 잠금을 순차적으로 획득합니다.

배포에서 sequential 배타적 잠금 검사 사용하거나 runLatest다음 단계를 수행합니다.

1. 환경(또는 다른 보호된 리소스)에서 배타적 잠금 검사 사용하도록 설정합니다.
2. 파이프라인에 대한 YAML 파일에서 호출 lockBehavior된 속성을 지정합니다. 전체 파이프라인 또는 지정된 단계에 대해 지정할 수 있습니다.

스테이지에서 설정:

stages:
- stage: A
  lockBehavior: sequential
  jobs:
  - job: Job
    steps:
    - script: Hey!

파이프라인에서 설정:

lockBehavior: runLatest
stages:
- stage: A
  jobs:
  - job: Job
    steps:
    - script: Hey!

지정 lockBehavior하지 않으면 기본값 runLatest 이 사용됩니다.

ServiceNow 변경 관리

이 검사 Marketplace에서 ServiceNow 변경 관리 확장을 설치해야 합니다.

servicenow 변경 관리 검사 파이프라인에서 ServiceNow 변경 관리 프로세스를 통합할 수 있습니다. 검사 추가하면 스테이지 시작 시 ServiceNow에서 새 변경 요청을 자동으로 만들 수 있습니다. 파이프라인은 단계를 시작하기 전에 변경 프로세스가 완료되기를 기다립니다. 자세한 내용은 여기에서 확인할 수 있습니다.

여러 승인 및 검사

스테이지는 여러 작업으로 구성되며 각 작업은 여러 리소스를 사용할 수 있습니다. 스테이지 실행을 시작하기 전에 해당 단계에서 사용되는 모든 리소스에 대한 모든 검사 충족해야 합니다. Azure Pipelines는 각 단계 전에 파이프라인 실행을 일시 중지하고 보류 중인 모든 검사 완료될 때까지 기다립니다.

단일 최종 부정 결정으로 인해 파이프라인에 대한 액세스가 거부되고 스테이지가 실패합니다. Azure 함수/REST API 및 배타적 잠금 호출을 제외한 모든 승인 및 검사 결정은 최종적입니다. Azure 함수/REST API 검사 성공적으로 호출을 다시 실행할 수 있습니다.

권장되는 방식으로 Azure 함수/REST API 검사 호출을 사용하는 경우 액세스 결정도 최종 결정됩니다.

호출 Azure 함수/REST API 검사 평가 사이의 시간을 0이 아닌 것으로 지정하면 검사 결정은 최종이 아닙니다. 이 시나리오는 살펴볼 가치가 있습니다.

예를 살펴보겠습니다. YAML 파이프라인에 서비스 연결을 사용하는 단계가 있다고 상상해 보십시오. 이 서비스 연결에는 두 개의 검사 구성됩니다.

1. 외부 승인이 부여되고 권장되는 방식으로 구성되었는지 확인하는 비동기 검사 부여된 외부 승인입니다.
2. 배포 이유가 유효하고 평가 사이의 시간을 7분으로 설정하는 배포 이유 유효성이라는 동기 검사.

가능한 검사 실행은 다음 다이어그램에 나와 있습니다.

이 실행에서:

• 외부 승인 허용 및 배포 이유 유효한 두 검사 동시에 호출됩니다. 배포 이유 유효성은 즉시 실패하지만 외부 승인이 보류 중이므로 다시 시도됩니다.
• 7분이 지나면 배포 이유 유효성 이 다시 시도되고 이번에는 통과합니다.
• 15 분 후에 외부 승인이 성공적으로 결정되어 Azure Pipelines로 다시 호출됩니다. 이제 두 검사 통과하므로 파이프라인이 스테이지를 계속 배포할 수 있습니다.

두 개의 동기 검사 포함하는 또 다른 예제를 살펴보겠습니다. YAML 파이프라인에 서비스 연결을 사용하는 단계가 있다고 가정합니다. 이 서비스 연결에는 두 개의 검사 구성됩니다.

1. 평가 사이의 시간을 5분으로 설정하는 동기화 검사 1이라는 동기 검사.
2. 평가 사이의 시간을 7분으로 설정하는 동기화 검사 2라는 동기 검사.

가능한 검사 실행은 다음 다이어그램에 나와 있습니다.

이 실행에서:

• 동기화 확인 1과 동기화 확인 2의 두 검사 동시에 호출됩니다. 동기화 확인 1은 통과하지만 동기화 검사 2가 실패하기 때문에 다시 시도됩니다.
• 5분이 되면 동기화 확인 1 이 다시 시도되지만 실패하므로 다시 시도됩니다.
• 분 7에서 동기화 확인 2 가 다시 시도되고 성공합니다. 통과 결정은 7분 동안 유효합니다. 동기화 확인 1이 이 시간 간격을 통과하지 못하면 동기화 검사 2가 다시 시도됩니다.
• 10분이 되면 동기화 검사 1 이 다시 시도되지만 실패하므로 다시 시도됩니다.
• 분 14에서 동기화 확인 2 가 다시 시도되고 성공합니다. 통과 결정은 7분 동안 유효합니다. 동기화 확인 1이 이 시간 간격을 통과하지 못하면 동기화 검사 2가 다시 시도됩니다.
• 15분이 되면 동기화 확인 1 이 다시 시도되고 성공합니다. 이제 두 검사 통과하므로 파이프라인이 스테이지를 계속 배포할 수 있습니다.

승인 및 동기 검사 관련된 예제를 살펴보겠습니다. 평가 사이의 시간(5분)을 사용하여 동기 검사 및 서비스 연결에 대한 승인을 구성한 경우를 상상해 보세요. 승인이 주어질 때까지 검사 결정에 관계없이 5분마다 실행됩니다.

FAQ

정의된 검사 시작되지 않았습니다. 무슨 일이 일어났나요?

검사 평가는 스테이지 조건이 충족되면 시작됩니다. 검사 리소스에 추가된 후 스테이지 실행이 시작되고 스테이지에서 리소스가 사용되는지 확인해야 합니다.

스테이지 예약에 검사 사용하려면 어떻게 해야 하나요?

업무 시간 검사 사용하여 스테이지 실행 시작 시간을 제어할 수 있습니다. 디자이너 릴리스의 스테이지에서 미리 정의된 일정과 동일한 동작을 수행할 수 있습니다.

나중에 실행되도록 예약된 스테이지에 대한 사전 승인을 어떻게 받을 수 있나요?

이 시나리오를 사용하도록 설정할 수 있습니다.

1. 검사 업무 시간을 통해 리소스에 배포하는 모든 단계가 기간 사이에 실행되도록 예약할 수 있습니다.
2. 승인이 동일한 리소스에 구성된 경우 스테이지는 시작하기 전에 승인을 기다립니다.
3. 리소스에서 두 검사 구성할 수 있습니다. 무대는 승인 및 업무 시간을 기다릴 것입니다. 승인이 완료된 후 예약된 다음 창에서 시작됩니다.

배포되는 아티팩트에서 보안 검사가 완료될 때까지 기다릴 수 있나요?

배포되는 아티팩트에서 보안 검색이 완료될 때까지 기다리려면 AquaScan과 같은 외부 검사 서비스를 사용해야 합니다. 배포되는 아티팩트를 검사 시작하기 전에 검색 서비스에 액세스할 수 있는 위치에 업로드해야 하며 미리 정의된 변수를 사용하여 식별할 수 있습니다. REST API 호출 검사 사용하여 보안 서비스의 API에서 대기하는 검사 추가하고 아티팩트 식별자를 입력으로 전달할 수 있습니다.

검사에서 이전 단계의 출력 변수를 어떻게 사용할 수 있나요?

기본적으로 미리 정의된 변수만 확인에 사용할 수 있습니다. 연결된 변수 그룹을 사용하여 다른 변수에 액세스할 수 있습니다. 이전 단계의 출력 변수는 변수 그룹에 쓸 수 있으며 검사에서 액세스할 수 있습니다.

자세한 정보

• Azure Function/REST API 검사 호출
• REST API 승인 및 검사
• 승인 쿼리 REST API