GitHub Actions를 사용하여 배포

필수 조건

GitHub Actions의 구문에 익숙해야 합니다. 자세한 내용은 워크플로 작성을(를) 참조하세요.

환경은 일반적인 배포 대상(예: production, staging 또는 development)을 설명하는 데 사용됩니다. GitHub Actions 워크플로가 환경에 배포되면 환경이 리포지토리의 기본 페이지에 표시됩니다. 작업을 진행하기 위해 승인을 요구하거나 워크플로, 사용자 지정 배포 보호 규칙을 사용하여 게이트 배포를 트리거할 수 있는 분기를 제한하거나 비밀에 대한 액세스를 제한할 수 있습니다. 환경을 만드는 방법에 대한 자세한 내용은 배포 환경 관리을(를) 참조하세요.

보호 규칙 및 비밀을 사용하여 환경을 구성할 수 있습니다. 워크플로 작업이 환경을 참조하는 경우 환경의 모든 보호 규칙이 통과될 때까지 작업이 시작되지 않습니다. 또한 작업은 모든 배포 보호 규칙이 통과될 때까지 환경에 정의된 비밀에 액세스할 수 없습니다. 자세한 내용은 이 문서의 사용자 지정 배포 보호 규칙 사용을 참조하세요.

동시성 사용

동시성은 동일한 동시성 그룹을 사용하는 단일 작업 또는 워크플로만 한 번에 실행되도록 합니다. 환경에 최대 하나의 배포가 진행 중이고 한 번에 하나의 배포가 보류되도록 동시성을 사용할 수 있습니다. 동시성에 대한 자세한 내용은 워크플로 및 작업의 동시 실행 제어을(를) 참조하세요.

참고 항목

concurrency 및 environment는 연결되어 있지 않습니다. 동시성 값은 모든 문자열일 수 있습니다. 환경 이름이 될 필요는 없습니다. 또한 다른 워크플로가 동일한 환경을 사용하지만 동시성을 지정하지 않는 경우 해당 워크플로에는 동시성 규칙이 적용되지 않습니다.

예를 들어 다음 워크플로가 실행될 때 production 동시성 그룹을 사용하는 작업이나 워크플로가 진행 중인 경우 상태가 pending인 상태에서 일시 중지됩니다. 또한 production 동시성 그룹을 사용하고 상태가 pending인 모든 작업 또는 워크플로를 취소합니다. 즉, production 동시성 그룹을 사용하는 최대 하나의 실행 중인 작업 또는 하나의 보류 중인 작업 또는 워크플로가 있습니다.

name: Deployment

concurrency: production

on:
  push:
    branches:
      - main

jobs:
  deployment:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: deploy
        # ...deployment-specific steps

작업 수준에서 동시성을 지정할 수도 있습니다. 이렇게 하면 동시 작업이 pending인 경우에도 워크플로의 다른 작업을 진행할 수 있습니다.

name: Deployment

on:
  push:
    branches:
      - main

jobs:
  deployment:
    runs-on: ubuntu-latest
    environment: production
    concurrency: production
    steps:
      - name: deploy
        # ...deployment-specific steps

동일한 동시성 그룹에서 현재 실행 중인 작업 또는 워크플로를 취소하는 데 cancel-in-progress를 사용할 수도 있습니다.

name: Deployment

concurrency:
  group: production
  cancel-in-progress: true

on:
  push:
    branches:
      - main

jobs:
  deployment:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: deploy
        # ...deployment-specific steps

배포 관련 단계 작성에 대한 지침은 배포 예제 찾기를 참조하세요.

배포 기록 보기

GitHub Actions 워크플로가 환경에 배포되면 환경이 리포지토리의 기본 페이지에 표시됩니다. 환경에 대한 배포 보기에 대한 자세한 내용은 배포 기록 보기을(를) 참조하세요.

워크플로 실행 모니터링

모든 워크플로 실행은 실행 진행률을 보여주는 실시간 그래프를 생성합니다. 이 그래프를 사용하여 배포를 모니터링하고 디버그할 수 있습니다. 자세한 내용은 시각화 그래프 사용을(를) 참조하세요.

각 워크플로 실행의 로그와 워크플로 실행 기록을 볼 수도 있습니다. 자세한 내용은 워크플로 실행 기록 보기을(를) 참조하세요.

워크플로의 필수 검토 사용

필수 검토자로 구성된 환경을 참조하는 작업은 시작하기 전에 승인을 기다립니다. 작업이 승인을 기다리는 동안 “대기 중” 상태가 됩니다. 작업이 30일 이내에 승인되지 않으면 자동으로 실패합니다.

환경 및 필수 승인에 대한 자세한 내용은 배포 환경 관리을(를) 참조하세요. REST API를 사용하여 배포를 검토하는 방법에 대한 내용은 워크플로 실행에 대한 REST API 엔드포인트을(를) 참조하세요.

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

참고 항목

사용자 지정 배포 보호 규칙은 현재 공개 미리 보기 버전이며 변경될 수 있습니다.

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

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

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

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

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

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

앱을 통한 배포 추적

GitHub의 개인 계정 또는 조직이 Microsoft Teams 또는 Slack과 통합된 경우 Microsoft Teams 또는 Slack을 통해 환경을 사용하는 배포를 추적할 수 있습니다. 예를 들어 배포가 승인 보류 중이거나 배포가 승인된 경우 또는 배포 상태가 변경된 경우 앱을 통해 알림을 받을 수 있습니다. Microsoft Teams 또는 Slack 통합에 대한 자세한 내용은 주요 GitHub 통합을(를) 참조하세요.

배포 및 배포 상태 웹후크를 사용하여 배포를 추적하는 앱을 빌드할 수도 있습니다. 환경을 참조하는 워크플로 작업이 실행되면 환경 이름으로 설정된 environment 속성이 있는 배포 개체를 만듭니다. 워크플로가 진행됨에 따라 환경 이름으로 설정된 environment 속성, 환경의 URL로 설정된 environment_url 속성(워크플로에 지정된 경우), 작업의 상태로 설정된 state 속성이 있는 배포 상태 개체도 만듭니다. 자세한 내용은 GitHub 앱 설명서 및 웹후크 이벤트 및 페이로드을(를) 참조하세요.

실행기 선택

GitHub 호스트 실행기 또는 자체 호스트형 실행기에서 배포 워크플로를 실행할 수 있습니다. GitHub 호스트 실행기의 트래픽은 광범위한 네트워크 주소에서 올 수 있습니다. 내부 환경에 배포 중이고 회사에서 외부 트래픽을 개인 네트워크로 제한하는 경우 GitHub 호스트 실행기에서 실행되는 GitHub Actions 워크플로는 내부 서비스 또는 리소스와 통신하지 못할 수 있습니다. 이를 극복하기 위해 자체 실행기를 호스트할 수 있습니다. 자세한 내용은 자체 호스팅 실행기 및 GitHub 호스팅 실행기을(를) 참조하세요.

상태 배지 표시

상태 배지를 사용하여 배포 워크플로의 상태를 표시할 수 있습니다. 상태 배지는 워크플로가 현재 실패 중 또는 통과 중인지 보여줍니다. 상태 배지를 추가하는 일반적인 위치는 리포지토리의 README.md 파일이지만 원하는 웹 페이지에 추가할 수도 있습니다. 기본적으로 배지는 기본 분기의 상태를 표시합니다. 기본 분기 워크플로 실행이 없으면 모든 분기에서 가장 최근 실행의 상태가 표시됩니다. URL의 branch 및 event 쿼리 매개 변수를 사용하여 특정 분기 또는 이벤트에 대한 워크플로 실행의 상태를 표시할 수 있습니다.

자세한 내용은 워크플로 상태 배지 추가을(를) 참조하세요.

배포 예제 찾기

이 문서에서는 배포 워크플로에 추가할 수 있는 GitHub Actions의 기능을 보여줍니다.

GitHub는 Azure Web App과 같은 여러 인기 서비스에 대한 배포 워크플로 템플릿을 제공합니다. 워크플로 템플릿으로 시작하는 방법을 알아보려면 워크플로 템플릿 사용 항목을 참조하거나 배포 워크플로 템플릿의 전체 목록을 확인하세요. Azure App Service에 Node.js 배포 항목과 같은 특정 배포 워크플로에 대한 자세한 가이드를 확인할 수도 있습니다.

또한 많은 서비스 공급자는 자사 서비스에 배포하기 위한 GitHub Marketplace에 대한 작업을 제공합니다. 전체 목록은 GitHub Marketplace를 참조하세요.

이 문서의 내용