자습서: GitHub 및 Azure 배포 환경을 사용하여 CI/CD에서 환경 배포

이 자습서에서는 AZURE 배포 환경을 CI/CD 파이프라인에 통합하는 방법에 대해 알아봅니다. GitHub Actions, Azure Arc, GitLab 또는 Jenkins와 같은 CI/CD를 지원하는 GitOps 공급자를 사용할 수 있습니다.

CI/CD(지속적인 통합 및 지속적인 업데이트)는 소프트웨어 변경 사항을 빌드, 테스트, 배포하는 과정을 자동화하도록 지원하는 소프트웨어 개발 방식입니다. CI/CD를 사용하면 소프트웨어 변경 내용을 더 자주 릴리스하고 자신감을 가질 수 있습니다.

기본, 개발 및 테스트의 세 가지 분기를 특징으로 하는 워크플로를 사용합니다.

메인 브랜치는 항상 프로덕션으로 간주됩니다.
기본 분기에서 기능 분기를 만듭니다.
기능 분기를 주 분기로 병합하기 위한 끌어오기 요청을 만듭니다.

이 자습서의 워크플로는 간소화된 예제입니다. 실제 워크플로는 더 복잡할 수 있습니다.

이 자습서를 시작하기 전에 Azure 배포 환경의 주요 개념을 검토하여 배포 환경 구성 요소 및 개념을 숙지할 수 있습니다.

이 튜토리얼에서는 다음을 배우게 됩니다:

개발자 센터 만들기 및 구성
키 저장소 만들기
GitHub 리포지토리 만들기 및 구성
개발자 센터에 카탈로그 연결
배포 ID 구성
GitHub 환경 구성
CI/CD 파이프라인 테스트

필수 조건

제품	요구 사항
애저 (Azure)	- Azure 구독. - Azure 구독에 대한 소유자 권한입니다. - Azure CLI 가 설치되었습니다.
Git (기트 - 버전 관리 도구)	- GitHub 계정입니다. - Git이 설치되었습니다.

1. 개발자 센터 만들기 및 구성

이 섹션에서는 개발, 테스트 및 Prod의 세 가지 환경 유형으로 Azure Deployment Environments 개발 센터 및 프로젝트를 만듭니 다.

Prod 환경 유형에는 단일 프로덕션 환경이 포함됩니다.
각 기능 분기에 대해 Dev 에서 새 환경이 만들어집니다.
각 끌어오기 요청에 대한 테스트 에 새 환경이 만들어집니다.

1.1 Azure CLI 설정

시작하려면 Azure에 로그인합니다. 다음 명령을 실행하고 프롬프트에 따라 인증 프로세스를 완료합니다.

az login

다음으로, Azure CLI용 Azure devcenter 확장을 설치합니다.

az extension add --name devcenter --upgrade

현재 확장이 설치되었으므로 네임스페이스를 등록합니다 Microsoft.DevCenter .

az provider register --namespace Microsoft.DevCenter

팁 (조언)

이 자습서 전체에서는 나중에 사용할 환경 변수로 여러 값을 저장합니다. 또한 이러한 값을 다른 곳에 기록하여 필요할 때 사용할 수 있도록 할 수도 있습니다.

사용자 ID를 가져와서 나중에 사용할 수 있도록 환경 변수로 설정합니다.

MY_AZURE_ID=$(az ad signed-in-user show --query id -o tsv)

현재 구독에 대한 구독 ID를 검색합니다.

AZURE_SUBSCRIPTION_ID=$(az account show --query id --output tsv)

현재 테넌트에 대한 테넌트 ID를 검색합니다.

AZURE_TENANT_ID=$(az account show --query tenantId --output tsv)

다음 환경 변수를 설정합니다.

LOCATION="eastus"
AZURE_RESOURCE_GROUP=<resourceGroupName>
AZURE_DEVCENTER=<devcenterName>
AZURE_PROJECT=<projectName>
AZURE_KEYVAULT=<keyVaultName>

비고

글로벌하게 고유한 키 보관소 이름을 사용해야 합니다. 그렇지 않으면 다음 오류가 발생할 수 있습니다.

Code: VaultAlreadyExists Message: The vault name 'mykeyvaultname' is already in use. Vault names are globally unique so it is possible that the name is already taken.

1.2 개발자 센터 만들기

개발자 센터는 비슷한 설정이 있는 프로젝트 및 환경의 컬렉션입니다. 개발자 센터는 환경을 만드는 데 사용할 수 있는 템플릿 및 아티팩트 카탈로그에 대한 액세스를 제공합니다. 또한 개발자 센터는 환경 및 프로젝트에 대한 액세스를 관리하는 방법을 제공합니다.

리소스 그룹을 만듭니다.

az group create \
  --name $AZURE_RESOURCE_GROUP \
  --location $LOCATION

개발자 센터 만들기:

az devcenter admin devcenter create \
  --name $AZURE_DEVCENTER \
  --identity-type SystemAssigned \
  --resource-group $AZURE_RESOURCE_GROUP \
  --location $LOCATION

이전 명령은 JSON을 출력합니다. id 값 및 identity.principalId 값을 나중에 사용할 수 있도록 환경 변수로 각각 저장합니다.

AZURE_DEVCENTER_ID=<id>
AZURE_DEVCENTER_PRINCIPAL_ID=<identity.principalId>

1.3 구독에서 개발자 센터 ID 소유자 역할 할당

개발자 센터에는 환경 유형과 연결된 구독에 역할을 할당할 수 있는 권한이 필요합니다.

불필요한 복잡성을 줄이기 위해 이 자습서에서는 개발자 센터 및 모든 환경 유형에 대해 단일 구독을 사용합니다. 실제로 개발자 센터 및 대상 배포 구독은 다른 정책이 적용된 별도의 구독일 수 있습니다.

az role assignment create \
  --scope /subscriptions/$AZURE_SUBSCRIPTION_ID \
  --role Owner \
  --assignee-object-id $AZURE_DEVCENTER_PRINCIPAL_ID \
  --assignee-principal-type ServicePrincipal

1.4 환경 유형 만들기

개발 센터 수준에서 환경 유형은 개발 팀이 개발, 테스트, 샌드박스, 사전 제작 및 프로덕션과 같이 만들 수 있는 환경을 정의합니다.

개발, 테스트 및 Prod의 세 가지 새 환경 유형을 만듭니다.

az devcenter admin environment-type create \
  --name Dev \
  --resource-group $AZURE_RESOURCE_GROUP \
  --dev-center $AZURE_DEVCENTER

az devcenter admin environment-type create \
  --name Test \
  --resource-group $AZURE_RESOURCE_GROUP \
  --dev-center $AZURE_DEVCENTER

az devcenter admin environment-type create \
  --name Prod \
  --resource-group $AZURE_RESOURCE_GROUP \
  --dev-center $AZURE_DEVCENTER

1.5 프로젝트 만들기

프로젝트는 개발 팀의 액세스 지점입니다. 각 프로젝트는 개발자 센터와 연결됩니다.

프로젝트 만들기:

az devcenter admin project create \
  --name $AZURE_PROJECT \
  --resource-group $AZURE_RESOURCE_GROUP \
  --location $LOCATION \
  --dev-center-id $AZURE_DEVCENTER_ID

이전 명령은 JSON을 출력합니다. id 나중에 사용할 환경 변수로 값을 저장합니다.

AZURE_PROJECT_ID=<id>

프로젝트에서 DevCenter 프로젝트 관리자 역할을 자신에게 할당합니다.

az role assignment create \
  --scope "$AZURE_PROJECT_ID" \
  --role "DevCenter Project Admin" \
  --assignee-object-id $MY_AZURE_ID \
  --assignee-principal-type User

1.6 프로젝트 환경 유형 만들기

프로젝트 수준에서 플랫폼 엔지니어는 개발 팀에 적합한 환경 유형을 지정합니다.

개발자 센터에서 만든 각 환경 유형에 대해 새 프로젝트 환경 유형을 만듭니다.

az devcenter admin project-environment-type create \
  --name Dev \
  --roles "{\"b24988ac-6180-42a0-ab88-20f7382dd24c\":{}}" \
  --deployment-target-id /subscriptions/$AZURE_SUBSCRIPTION_ID \
  --resource-group $AZURE_RESOURCE_GROUP \
  --location $LOCATION \
  --project $AZURE_PROJECT \
  --identity-type SystemAssigned \
  --status Enabled

az devcenter admin project-environment-type create \
  --name Test \
  --roles "{\"b24988ac-6180-42a0-ab88-20f7382dd24c\":{}}" \
  --deployment-target-id /subscriptions/$AZURE_SUBSCRIPTION_ID \
  --resource-group $AZURE_RESOURCE_GROUP \
  --location $LOCATION \
  --project $AZURE_PROJECT \
  --identity-type SystemAssigned \
  --status Enabled

az devcenter admin project-environment-type create \
  --name Prod \
  --roles "{\"b24988ac-6180-42a0-ab88-20f7382dd24c\":{}}" \
  --deployment-target-id /subscriptions/$AZURE_SUBSCRIPTION_ID \
  --resource-group $AZURE_RESOURCE_GROUP \
  --location $LOCATION \
  --project $AZURE_PROJECT \
  --identity-type SystemAssigned \
  --status Enabled

2. 키 자격 증명 보관소 만들기

이 섹션에서는 새 Key Vault를 만듭니다. 자습서의 뒷부분에서 이 키 자격 증명 저장소를 사용하여 GitHub에서 개인 액세스 토큰을 저장합니다.

az keyvault create \
  --name $AZURE_KEYVAULT \
  --resource-group $AZURE_RESOURCE_GROUP \
  --location $LOCATION \
  --enable-rbac-authorization true

다시 이전 명령의 JSON 출력을 환경 변수로 저장 id 합니다.

AZURE_KEYVAULT_ID=<id>

새 Key Vault에 대해 본인에게 Key Vault 관리자 역할을 부여합니다.

az role assignment create \
  --scope $AZURE_KEYVAULT_ID \
  --role "Key Vault Administrator" \
  --assignee-object-id $MY_AZURE_ID \
  --assignee-principal-type User

개발자 센터의 ID에 Key Vault 비밀 사용자의 역할을 할당합니다.

az role assignment create \
  --scope $AZURE_KEYVAULT_ID \
  --role "Key Vault Secrets User" \
  --assignee-object-id $AZURE_DEVCENTER_PRINCIPAL_ID \
  --assignee-principal-type ServicePrincipal

3. GitHub 리포지토리 만들기 및 구성

이 섹션에서는 카탈로그를 저장할 새 GitHub 리포지토리를 만듭니다. Azure 배포 환경은 GitHub 및 Azure DevOps 리포지토리를 모두 지원합니다. 이 자습서에서는 GitHub를 사용합니다.

3.1 GitHub 리포지토리 만들기

이 단계에서는 미리 정의된 디렉터리 구조, 분기 및 파일이 있는 새 리포지토리를 GitHub 계정에 만듭니다. 이러한 항목은 샘플 템플릿 리포지토리에서 생성됩니다.

샘플 템플릿에서 새 GitHub 리포지토리를 생성합니다.
유료 GitHub 계정이 없는 경우 리포지토리를 공용으로 설정합니다.
리포지토리 만들기를 선택합니다.

3.2 리포지토리의 주 분기 보호

분기 보호 규칙을 설정하여 중요한 분기를 보호할 수 있습니다. 보호 규칙은 협업자가 분기를 삭제하거나 분기에 강제 푸시를 할 수 있는지 여부를 정의합니다. 또한 상태 검사 통과나 선형 커밋 기록 유지와 같은 브랜치로의 푸시에 대한 요구 사항도 설정합니다.

비고

보호된 분기는 조직용 GitHub Free 및 GitHub Free를 사용하는 공용 리포지토리 및 GitHub Pro, GitHub 팀, GitHub Enterprise Cloud 및 GitHub Enterprise Server를 사용하는 공용 및 프라이빗 리포지토리에서 사용할 수 있습니다. 자세한 내용은 GitHub 계획을 참조하세요.

아직 열려 있지 않은 경우 리포지토리의 기본 페이지로 이동합니다.
창 맨 위에 있는 메뉴에서 설정을 선택합니다.
왼쪽 사이드바의 코드 및 자동화 섹션에서 분기를 선택합니다.
분기 보호 규칙에서 분기 규칙 집합 추가를 선택합니다.
새 분기 규칙 집합 페이지의 규칙 집합 이름에서 CI-CD-tutorial-ruleset을 입력합니다.
대상 분기에서 대상 추가를 선택한 다음 기본 분기 포함 또는 모든 분기 포함을 선택합니다.
분기 규칙에서 병합하기 전에 끌어오기 요청을 요구를 선택합니다.
필요에 따라 더 많은 보호 규칙을 사용하도록 설정할 수 있습니다.
선택하고생성합니다.

3.3 리포지토리 변수 구성

사이드바의 보안 섹션에서 비밀 및 변수를선택한 다음 작업을 선택합니다.
변수 탭을 선택합니다.

다음 표의 각 항목에 대해 다음을 수행합니다.

새 리포지토리 변수를 선택합니다.
이름 필드에 변수 이름을 입력합니다.
값 필드에 테이블에 설명된 값을 입력합니다.
변수 추가를 선택합니다.

변수 이름	변수 값
AZURE_DEVCENTER	개발자 센터 이름
AZURE_PROJECT	프로젝트 이름
애저_카탈로그	환경으로 설정
AZURE_CATALOG_ITEM	FunctionApp으로 설정
AZURE_SUBSCRIPTION_ID	Azure 구독 ID
AZURE_TENANT_ID (Azure 테넌트 ID)	Azure 테넌트 ID

3.4 GitHub 개인용 액세스 토큰 만들기

다음으로, Azure Deployment Environments 개발자 센터에서 리포지토리에 연결하고 환경 카탈로그를 사용할 수 있도록 세분화된 개인용 액세스 토큰 을 만듭니다.

비고

피드백 토론에서 세분화된 개인용 액세스 토큰에 대한 피드백을 남길 수 있습니다.

GitHub.com 페이지의 오른쪽 위 모서리에서 프로필 사진을 선택한 다음 설정을 선택합니다.
왼쪽 사이드바에서 개발자 설정을 선택합니다.
왼쪽 사이드바의 개인용 액세스 토큰에서 세분화된 토큰을 선택한 다음 새 토큰 생성을 선택합니다.
새 세분화된 개인용 액세스 토큰 페이지의 토큰 이름 아래에 토큰의 이름을 입력합니다.
만료일에서 토큰의 만료 기간을 선택합니다.
리소스 소유자에서 GitHub 사용자 이름을 선택합니다.
리포지토리 액세스에서 리포지토리만 선택합니다. 선택한 리포지토리에서 만든 리포지토리를 검색하고 선택합니다.
사용 권한에서 리포지토리 권한을 선택한 다음, 내용을 읽기 전용으로 변경합니다.
토큰 생성을 선택합니다.
개인용 액세스 토큰을 복사하고 저장합니다. 다시 볼 수 없습니다.

3.5 개인용 액세스 토큰을 키 자격 증명 보관소에 저장

다음으로 개인 액세스 토큰을 pat라는 키 자격 증명 보관소 비밀로 저장합니다.

az keyvault secret set \
    --name pat \
    --vault-name $AZURE_KEYVAULT \
    --value <personalAccessToken>

4. 개발자 센터에 카탈로그 연결

Azure 배포 환경에서 카탈로그 는 환경 정의 집합을 포함하는 리포지토리입니다. 카탈로그 항목은 IaC(Infrastructure-as-code) 템플릿 및 매니페스트 역할을 하는 환경 파일로 구성됩니다. 템플릿은 환경을 정의하고 환경 파일은 템플릿에 대한 메타데이터를 제공합니다. 개발 팀은 카탈로그의 환경 정의를 사용하여 환경을 만듭니다.

GitHub 리포지토리를 만드는 데 사용한 템플릿에는 환경 폴더의 카탈로그가 포함되어 있습니다 .

개발자 센터에 카탈로그 추가

다음 명령에서 < Organization/Repository >를 GitHub 조직 및 리포지토리 이름으로 바꾸십시오.

az devcenter admin catalog create \
    --name Environments \
    --resource-group $AZURE_RESOURCE_GROUP \
    --dev-center $AZURE_DEVCENTER \
    --git-hub path="/Environments" branch="main" secret-identifier="https://$AZURE_KEYVAULT.vault.azure.net/secrets/pat" uri="https://github.com/< Organization/Repository >.git"

5. 배포 ID 구성

GitHub Actions를 사용한 OpenID Connect 는 단기 토큰을 사용하여 강화된 보안을 제공하는 인증 방법입니다. Azure에 GitHub Actions를 인증하는 것이 좋습니다.

비밀을 사용하여 서비스 주체를 직접 인증할 수도 있지만 이 자습서의 범위를 벗어납니다.

5.1 배포 ID 생성

세 가지 환경 유형 각각 에 대해 Microsoft Entra 애플리케이션 및 서비스 주체 를 등록합니다.

개발용 Microsoft Entra 애플리케이션을 만듭니다.
```
az ad app create --display-name "$AZURE_PROJECT-Dev"
```
이 명령은 Graph API를 id 사용하여 페더레이션된 자격 증명을 만들 때 사용하는 JSON과 appId 클라이언트 ID라고도 하는 JSON을 출력합니다.

다음 환경 변수를 설정합니다.
```
DEV_AZURE_CLIENT_ID=<appId>
DEV_APPLICATION_ID=<id>
```
테스트에 대해 다음 단계를 반복합니다.
```
az ad app create --display-name "$AZURE_PROJECT-Test"
```
```
TEST_AZURE_CLIENT_ID=<appId>
TEST_APPLICATION_ID=<id>
```
Prod에 대해 단계를 다시 반복합니다.
```
az ad app create --display-name "$AZURE_PROJECT-Prod"
```
```
PROD_AZURE_CLIENT_ID=<appId>
PROD_APPLICATION_ID=<id>
```
각 애플리케이션에 대한 서비스 주체를 만듭니다.

다음 명령을 실행하여 Dev용 새 서비스 주체를 만듭니다.
```
 az ad sp create --id $DEV_AZURE_CLIENT_ID
```
이 명령은 다음 단계에서 사용할 다른 id JSON 출력을 생성합니다.

다음 환경 변수를 설정합니다.
```
DEV_SERVICE_PRINCIPAL_ID=<id>
```
테스트에 대해 다음 단계를 반복합니다.
```
 az ad sp create --id $TEST_AZURE_CLIENT_ID
```
```
TEST_SERVICE_PRINCIPAL_ID=<id>
```
Prod에 대해 단계를 다시 반복합니다.
```
 az ad sp create --id $PROD_AZURE_CLIENT_ID
```
```
PROD_SERVICE_PRINCIPAL_ID=<id>
```

다음 명령을 실행하여 각 Microsoft Entra 애플리케이션에 대한 새 페더레이션 ID 자격 증명을 만듭니 다.

다음 세 가지 명령 각각에서 < Organization/Repository >를 GitHub 조직 및 리포지토리 이름으로 바꾸십시오.

Dev에 대한 페더레이션 ID 자격 증명을 만듭니다.

az rest --method POST \
    --uri "https://graph.microsoft.com/beta/applications/$DEV_APPLICATION_ID/federatedIdentityCredentials" \
    --body '{"name":"ADEDev","issuer":"https://token.actions.githubusercontent.com","subject":"repo:< Organization/Repository >:environment:Dev","description":"Dev","audiences":["api://AzureADTokenExchange"]}'

테스트에 대한 자격 증명을 만듭니다.

az rest --method POST \
    --uri "https://graph.microsoft.com/beta/applications/$TEST_APPLICATION_ID/federatedIdentityCredentials" \
    --body '{"name":"ADETest","issuer":"https://token.actions.githubusercontent.com","subject":"repo:< Organization/Repository >:environment:Test","description":"Test","audiences":["api://AzureADTokenExchange"]}'

Prod에 대한 자격 증명을 만듭니다.

az rest --method POST \
    --uri "https://graph.microsoft.com/beta/applications/$PROD_APPLICATION_ID/federatedIdentityCredentials" \
    --body '{"name":"ADEProd","issuer":"https://token.actions.githubusercontent.com","subject":"repo:< Organization/Repository >:environment:Prod","description":"Prod","audiences":["api://AzureADTokenExchange"]}'

5.2 배포 ID에 역할 할당

각 배포 ID에게 프로젝트에 대한 읽기 역할을 할당합니다.

az role assignment create \
    --scope "$AZURE_PROJECT_ID" \
    --role Reader \
    --assignee-object-id $DEV_SERVICE_PRINCIPAL_ID \
    --assignee-principal-type ServicePrincipal

az role assignment create \
    --scope "$AZURE_PROJECT_ID" \
    --role Reader \
    --assignee-object-id $TEST_SERVICE_PRINCIPAL_ID \
    --assignee-principal-type ServicePrincipal

az role assignment create \
    --scope "$AZURE_PROJECT_ID" \
    --role Reader \
    --assignee-object-id $PROD_SERVICE_PRINCIPAL_ID \
    --assignee-principal-type ServicePrincipal

각 배포 ID의 해당 환경 유형에 배포 환경 사용자 역할을 할당합니다.

az role assignment create \
    --scope "$AZURE_PROJECT_ID/environmentTypes/Dev" \
    --role "Deployment Environments User" \
    --assignee-object-id $DEV_SERVICE_PRINCIPAL_ID \
    --assignee-principal-type ServicePrincipal

az role assignment create \
    --scope "$AZURE_PROJECT_ID/environmentTypes/Test" \
    --role "Deployment Environments User" \
    --assignee-object-id $TEST_SERVICE_PRINCIPAL_ID \
    --assignee-principal-type ServicePrincipal

az role assignment create \
    --scope "$AZURE_PROJECT_ID/environmentTypes/Prod" \
    --role "Deployment Environments User" \
    --assignee-object-id $PROD_SERVICE_PRINCIPAL_ID \
    --assignee-principal-type ServicePrincipal

6. GitHub 환경 구성

GitHub 환경을 사용하면 보호 규칙 및 비밀을 사용하여 환경을 구성할 수 있습니다. 환경을 참조하는 워크플로 작업은 환경의 비밀을 실행하거나 액세스하기 전에 환경에 대한 모든 보호 규칙을 따라야 합니다.

Azure 배포 환경 프로젝트의 환경 유형에 매핑되는 개발, 테스트 및 Prod 환경을 만듭니다.

비고

환경, 환경 비밀 및 환경 보호 규칙은 모든 제품에 대한 공용 리포지토리에서 사용할 수 있습니다. 프라이빗 또는 내부 리포지토리의 환경, 환경 비밀 및 배포 분기에 액세스하려면 GitHub Pro, GitHub Team 또는 GitHub Enterprise를 사용해야 합니다. 프라이빗 또는 내부 리포지토리의 다른 환경 보호 규칙에 액세스하려면 GitHub Enterprise를 사용해야 합니다. 자세한 내용은 GitHub 계획을 참조하세요.

6.1 개발 환경 만들기

GitHub에서 리포지토리의 기본 페이지로 이동합니다.
리포지토리 이름 아래에서 설정을 선택합니다. 설정 탭이 보이지 않으면 ... 드롭다운 메뉴를 선택한 다음 설정을 선택합니다.
왼쪽 사이드바에서 환경을 선택합니다.
새 환경을 선택하고 환경 이름에 대한 Dev를 입력한 다음, 환경 구성을 선택합니다.
환경 비밀에서 환경 비밀 추가를 선택한 다음 이름 상자에 AZURE_CLIENT_ID 입력합니다.
값 상자에 이전에 만든 appId Microsoft Entra 앱의 클라이언트 ID()를 입력합니다(환경 변수로 $DEV_AZURE_CLIENT_ID 저장됨).
비밀 추가를 선택합니다.

6.2 테스트 환경 만들기

왼쪽 사이드바에서 환경을 선택하여 기본 환경 페이지로 돌아갑니다.

새 환경을 선택하고 환경 이름에 대한 테스트를 입력한 다음 환경 구성을 선택합니다.
환경 비밀에서 환경 비밀 추가를 선택한 다음 이름 상자에 AZURE_CLIENT_ID 입력합니다.
값 상자에 이전에 만든 appId Microsoft Entra 앱의 클라이언트 ID()를 입력합니다(환경 변수로 $TEST_AZURE_CLIENT_ID 저장됨).
비밀 추가를 선택합니다.

6.3 Prod 환경 만들기

다시 한 번 왼쪽 사이드바에서 환경을 선택하여 기본 환경 페이지로 돌아갑니다.

새 환경을 선택하고 환경 이름에 대해 Prod를 입력한 다음 환경 구성을 선택합니다.
환경 비밀에서 환경 비밀 추가를 선택한 다음 이름 상자에 AZURE_CLIENT_ID 입력합니다.
값 상자에 이전에 만든 appId Microsoft Entra 앱의 클라이언트 ID()를 입력합니다(환경 변수로 $PROD_AZURE_CLIENT_ID 저장됨).
비밀 추가를 선택합니다.

다음으로, 이 환경에 필요한 검토자로 자신을 설정합니다. Prod에 배포하려고 하면 GitHub Actions는 시작하기 전에 승인을 기다립니다. 작업이 승인을 기다리는 동안 대기 중 상태가 됩니다. 작업이 30일 이내에 승인되지 않으면 자동으로 실패합니다.

환경 및 필수 승인에 대한 자세한 내용은 배포에 환경 사용을 참조하세요.

필수 검토자를 선택합니다.
GitHub 사용자 이름을 검색하여 선택합니다. 최대 6명 또는 팀을 입력할 수 있습니다. 작업을 계속하려면 필수 검토자 중 한 명만 작업을 승인하면 됩니다.
보호 규칙 저장을 선택합니다.

마지막으로 main을(를) 배포 분기로 설정합니다.

배포 분기 및 태그 목록에서 선택한 분기 및 태그를 선택합니다.
배포 분기 또는 태그 규칙 추가를 선택하고 Ref 유형: 분기가 선택되어 있는지 확인하고 이름 패턴 상자에 기본을 입력합니다.
규칙 추가를 선택합니다.

7. CI/CD 파이프라인 테스트

이 섹션에서는 리포지토리를 몇 가지 변경하고 CI/CD 파이프라인을 테스트합니다.

7.1 리포지토리 복제

Git Bash에서 리포지토리를 로컬로 복제하려는 폴더로 전환하는 데 사용합니다 cd .
리포지토리를 복제합니다. 다음 명령에서 GitHub 조직 및 리포지토리 이름으로 < Organization/Repository >를 바꾸세요.
```
git clone https://github.com/< Organization/Repository >.git
```
복제된 디렉터리로 이동합니다.
```
cd <repository>
```
새 분기를 만들고 원격으로 게시합니다.
```
git checkout -b feature1
```
```
git push -u origin feature1
```
이 분기와 관련된 새 환경이 Azure에서 만들어집니다.
GitHub에서 새로 만든 리포지토리의 기본 페이지로 이동합니다.
리포지토리 이름 아래에서 액션을 선택합니다.

실행 중인 새 환경 만들기 워크플로가 표시됩니다.

7.2 코드를 변경합니다.

Visual Studio Code에서 로컬로 복제된 리포지토리를 엽니다.
ADE에서 . 자습서 폴더에서 파일을 변경합니다.
변경 내용을 저장합니다.

변경 내용을 푸시하여 환경을 업데이트하십시오

변경 내용을 스테이징하고 feature1 분기로 푸시하세요.
```
git add .
git commit -m '<commit message>'
git push
```
리포지토리의 작업 페이지에 새 업데이트 환경 워크플로가 실행 중인 것을 볼 수 있습니다.

7.4 끌어오기 요청 만들기

GitHub 끌어오기 요청을 main <- feature1만듭니다.
리포지토리의 작업 페이지에서 새 워크플로가 끌어오기 요청과 관련된 환경을 만들기 시작했음을 알 수 있습니다. 테스트 환경 유형이 사용됩니다.

7.5 끌어오기 요청 병합

GitHub에서 만든 끌어오기 요청으로 이동합니다.
끌어오기 요청을 병합합니다.

변경 내용이 프로덕션 환경에 게시되고 분기 및 끌어오기 요청 환경이 삭제됩니다.

자원을 정리하세요

만든 리소스를 사용할 계획이 없다면 추가 요금이 발생하지 않도록 삭제합니다. 다른 리소스 그룹에 샘플 애플리케이션을 배포한 경우 다음 단계를 반복할 수 있습니다.

Azure Portal을 사용하여 리소스를 삭제하려면 다음을 수행합니다.

왼쪽 상단 모서리에 있는 메뉴 단추를 선택한 다음, 리소스 그룹을 선택합니다.
목록에서 만든 리소스 그룹을 선택합니다.
리소스 그룹 삭제를 선택합니다.
리소스 그룹 이름을 입력합니다. 그런 다음 삭제를 선택합니다.

Azure CLI를 사용하여 리소스를 삭제하려면 다음 명령을 입력합니다.

az group delete --name <my-dev-center-rg>

리소스 그룹을 삭제하면 그 안에 있는 모든 리소스도 함께 삭제됩니다.

Azure CLI를 사용하여 환경 만들기 및 액세스
전체 명령 목록은 Microsoft Dev Box 및 Azure 배포 환경 Azure CLI 설명서를 참조하세요.

피드백

이 페이지가 도움이 되었나요?

Last updated on 2025-11-26