사용자 지정 배포 보호 규칙 만들기

GitHub Apps을(를) 사용하여 제3자 시스템으로 배포 보호를 자동화합니다.

누가 이 기능을 사용할 수 있나요?

사용자 지정 배포 보호 규칙은 모든 플랜의 퍼블릭 리포지토리에서 사용할 수 있습니다. 프라이빗 또는 내부 리포지토리의 사용자 지정 배포 보호 규칙에 액세스하려면 GitHub Enterprise를 사용해야 합니다.

이 문서의 내용

참고: 태그 보호 규칙은 현재 베타 버전이며 변경될 수 있습니다.

사용자 지정 배포 보호 규칙 정보

타사 서비스를 사용하여 배포를 제어하는 사용자 지정 보호 규칙을 사용하도록 설정할 수 있습니다. 예를 들어 Datadog, Honeycomb, ServiceNow와 같은 서비스를 사용하여 GitHub에 대한 배포에 자동화된 승인을 제공할 수 있습니다.

사용자 지정 배포 보호 규칙은 GitHub Apps에 의해 제공되며 웹후크 및 콜백에 따라 실행됩니다. 워크플로 작업의 승인 또는 거부는 deployment_protection_rule 웹후크 사용을 기반으로 합니다. 자세한 내용은 "웹후크 이벤트 및 페이로드" 및 "배포 승인 또는 거부"를 참조하세요.

사용자 지정 배포 보호 규칙을 만들고 리포지토리에 설치하면 리포지토리의 모든 환경에 대해 사용자 지정 배포 보호 규칙이 자동으로 사용 가능하게 됩니다.

사용자 지정 배포 보호 규칙을 사용하여 배포 승인 또는 거부하기

IT 서비스 관리(ITSM) 시스템의 승인된 티켓, 종속성에 대한 취약한 검사 결과 또는 클라우드 리소스의 안정적인 상태 메트릭과 같은 외부 서비스에 정의된 조건에 따라 환경에 대한 배포를 승인하거나 거부할 수 있습니다. 배포를 승인하거나 거부하는 결정은 제3자 애플리케이션 통합 및 배포에서 정의한 게이팅 조건의 재량에 따라 결정됩니다. 다음은 배포 보호 규칙을 만들 수 있는 몇 가지 사용 사례입니다.

  • ITSM 및 보안 작업: 배포 준비 상태를 확인하는 품질, 보안 및 규정 준수 프로세스의 유효성을 검사하여 서비스 준비 상태를 검사할 수 있습니다.
  • 가시성 시스템: 모니터링 또는 관찰 시스템(자산 성능 관리 시스템 및 로깅 집계, 클라우드 리소스 상태 확인 시스템 등)을 참조하여 안전성 및 배포 준비 상태를 확인할 수 있습니다.
  • 코드 품질 및 테스트 도구: 환경에 배포해야 하는 CI 빌드에서 자동화된 테스트를 위해 검사할 수 있습니다.

또는 위의 사용 사례에 대한 사용자 고유의 보호 규칙을 작성하거나 사전 프로덕션 환경에서 프로덕션 환경으로의 배포를 안전하게 승인하거나 거부하는 사용자 지정 논리를 정의할 수 있습니다.

GitHub Apps을(를) 사용하여 사용자 지정 배포 보호 규칙 만들기

  1. GitHub App을(를) 생성합니다. 자세한 내용은 "GitHub 앱 등록"을 참조하세요. 다음과 같이 GitHub App을(를) 구성합니다.

    1. 필요에 따라 "사용자 식별 및 권한 부여"의 콜백 URL 텍스트 필드에 콜백 URL을 입력합니다. 자세한 내용은 "사용자 권한 부여 콜백 URL 정보"을 참조하세요.
    2. "사용 권한"에서 리포지토리 권한을 선택합니다.
    3. "작업" 오른쪽에서 드롭다운 메뉴를 클릭하고 액세스: 읽기 전용을 선택합니다.
      새 GitHub 앱을 만들 때 "리포지토리 권한" 섹션의 스크린샷. 작업 권한을 "읽기 전용"으로 선택하여 권한을 구성하는 단추가 진한 주황색 사각형으로 강조 표시됩니다.
    4. "배포" 오른쪽에서 드롭다운 메뉴를 클릭하고 액세스: 읽기 및 쓰기를 선택합니다.
      새 GitHub 앱을 만드는 동안 "리포지토리 권한" 섹션의 "배포" 권한 설정 스크린샷. 배포 권한을 "읽기 전용"으로 선택하여 권한을 구성하는 단추가 진한 주황색 사각형으로 강조 표시됩니다.
    5. "이벤트 구독"에서 배포 보호 규칙을 선택합니다.
      새 GitHub 앱을 만드는 동안 "이벤트 구독 섹션"의 스크린샷. 이벤트 구독 배포 보호 규칙에 대한 확인란이 진한 주황색 사각형으로 강조 표시됩니다.

  2. 리포지토리에 사용자 지정 배포 보호 규칙을 설치하고 사용 설정합니다. 자세한 내용은 "사용자 지정 배포 보호 규칙 구성"을 참조하세요.

배포 승인 또는 거부하기

워크플로가 사용자 지정 배포 보호 규칙이 사용 설정된 환경을 참조하는 작업에 도달하면 GitHub에서 deployment_protection_rule 페이로드를 포함하는 사용자가 구성한 URL로 POST 요청을 보냅니다. 배포 보호 규칙을 작성하여 deployment_protection_rule 페이로드에 따라 배포를 승인하거나 거부하는 REST API 요청을 자동으로 보낼 수 있습니다. 다음과 같이 REST API 요청을 구성합니다.

  1. 들어오는 POST 요청의 유효성을 검사합니다. 자세한 내용은 "웹후크 제공 유효성 검사하기"을 참조하세요.

  2. JWT(JSON Web Token)를 사용하여 GitHub App(으)로 인증합니다. 자세한 내용은 "GitHub 앱으로 인증"을 참조하세요.

  3. deployment_protection_rule 웹후크 페이로드의 설치 ID를 사용하여 설치 토큰을 생성합니다. 자세한 내용은 "GitHub 앱을 사용한 인증 정보"을(를) 참조하세요.

    curl --request POST \
--url "http(s)://HOSTNAME/api/v3/app/installations/INSTALLATION_ID/ACCESS_TOKENS" \
--header "Accept: application/vnd.github+json" \
--header "Authorization: Bearer {jwt}" \
--header "Content-Type: application/json" \
--data \
'{ \
   "repository_ids": [321], \
   "permissions": { \
      "deployments": "write" \
   } \
}'

  4. 필요에 따라 GitHub에 다른 작업을 수행하지 않고 상태 보고서를 추가하려면 /repos/OWNER/REPO/actions/runs/RUN_ID/deployment_protection_rule에 POST 요청을 보냅니다. 요청 본문에서 state을(를) 생략합니다. 자세한 내용은 "워크플로 실행에 대한 REST API 엔드포인트"을 참조하세요. 동일한 배포에 상태 보고서를 최대 10번 게시할 수 있습니다. 상태 보고서는 Markdown 서식을 지원하며 최대 1024자까지 가능합니다.

  5. 요청을 승인하거나 거부하려면 /repos/OWNER/REPO/actions/runs/RUN_ID/deployment_protection_rule에 POST 요청을 보냅니다 . 요청 본문에서 state 속성을 approved 또는 rejected(으)로 설정합니다. 자세한 내용은 "워크플로 실행에 대한 REST API 엔드포인트"을 참조하세요.

  6. 필요에 따라 /repos/OWNER/REPOSITORY_ID/actions/runs/RUN_ID/approvals에 GET 요청을 전송하여 워크플로 실행에 대한 승인 상태를 요청합니다. 자세한 내용은 "워크플로 실행에 대한 REST API 엔드포인트"을(를) 참조하세요.

  7. 필요에 따라 GitHub에 대한 배포를 검토합니다. 자세한 내용은 "배포 검토"을(를) 참조하세요.