Skip to main content

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

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

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

Custom deployment protection rules are available in public repositories for all plans. For access to custom deployment protection rules in private or internal repositories, you must use GitHub Enterprise. For more information, see "GitHub’s plans."

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

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

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

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

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

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

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

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

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

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

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

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

배포 승인 또는 거부

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

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

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

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

    curl --request POST \
    --url "https://api.github.com/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.com에 다른 작업을 수행하지 않고 상태 보고서를 추가하려면 POST 요청을 /repos/OWNER/REPO/actions/runs/RUN_ID/deployment_protection_rule에 보냅니다. 요청 본문에서 state를 생략합니다. 자세한 내용은 "워크플로 실행에 대한 REST API 엔드포인트"을 참조하세요. 동일한 배포에 상태 보고서를 최대 10번 게시할 수 있습니다. 상태 보고서는 Markdown 서식을 지원하며 최대 1024자까지 가능합니다.

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

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

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

GitHub Marketplace에 사용자 지정 배포 보호 규칙 게시

GitHub App을(를) GitHub Marketplace에 게시하여 개발자가 적절한 보호 규칙을 검색하고 이를 GitHub 리포지토리에 설치할 수 있습니다. 또는 필요에 맞게 기존 사용자 지정 배포 보호 규칙을 찾아볼 수 있습니다. 자세한 내용은 "앱용 GitHub Marketplace 정보" 및 "GitHub Marketplace에 앱 나열"을 참조하세요.