연습 - 주 분기 보호

5분

팀은 이미 웹 사이트 및 데이터베이스가 포함된 Bicep 템플릿을 작업하고 있습니다. 구성 요소를 프로덕션 환경에 배포했습니다. 이제 주문 처리 큐를 추가하려면 Bicep 템플릿을 업데이트해야 합니다.

이 연습에서는 변경에 대한 기능 분기를 만듭니다. 또한 메인 브랜치를 보호하고 변경 사항을 검토한 후에만 메인 브랜치에 병합하도록 허용합니다. 하지만 그 전에 이 모듈의 나머지 부분을 완료하도록 환경이 설정되어 있는지 확인해야 합니다.

프로세스 중에 다음을 수행합니다.

이 모듈에 대한 GitHub 리포지토리를 설정합니다.
컴퓨터에 리포지토리를 복제합니다.
리포지토리의 메인 브랜치에 브랜치 보호를 추가합니다.
변경에 대한 로컬 기능 분기를 만듭니다.
기능 브랜치를 메인에 병합해 보세요.

이 모듈의 Azure DevOps 프로젝트를 설정합니다.
프로젝트의 리포지토리를 컴퓨터에 복제합니다.
리포지토리의 메인 브랜치에 브랜치 정책을 추가합니다.
변경에 대한 로컬 기능 분기를 만듭니다.
기능 브랜치를 메인에 병합해 보세요.

GitHub 리포지토리 가져오기

여기서 GitHub 리포지토리가 이 모듈의 나머지 부분을 완료하도록 설정되었는지 확인합니다. 템플릿 리포지토리를 기준으로 새 리포지토리를 만들어 설정합니다. 템플릿 리포지토리에는 이 모듈을 시작하는 데 필요한 파일이 포함되어 있습니다.

템플릿 리포지토리에서 시작

GitHub 리포지토리를 설정하는 템플릿을 실행합니다.

템플릿 실행

GitHub 사이트에서 다음 단계를 수행하여 템플릿에서 리포지토리를 만듭니다.

이 템플릿> 사용을 선택하여새 리포지토리 만들기를 선택합니다.
새 프로젝트의 이름(예: toy-website-review)을 입력합니다.
공용 옵션을 선택합니다.

사용자 고유의 리포지토리를 만들 때 프라이빗으로 설정할 수 있습니다. 이 모듈에서는 공용 리포지토리 및 GitHub Enterprise 계정에서만 작동하는 GitHub의 기능을 사용합니다.
템플릿에서 리포지토리 만들기를 선택합니다.

Azure DevOps 프로젝트 가져오기

여기서는 Azure DevOps 조직이 이 모듈의 나머지 부분을 완료하도록 설정되어 있는지 확인합니다. Azure DevOps 조직을 설정하는 템플릿을 실행합니다.

Visual Studio 또는 선택한 IDE에서 ADOGenerator 프로젝트를 가져와 실행합니다.
템플릿 목록에서 템플릿 번호를 입력하라는 메시지가 표시되면 Bicep 및 끌어오기 요청을 사용하여 Azure 인프라 변경 내용 검토를 위해 44를 입력한 다음 Enter 키를 누릅니다.
인증 방법을 선택합니다. PAT(개인 액세스 토큰)를 설정하고 사용하거나 디바이스 로그인을 사용할 수 있습니다.

비고

PAT를 설정하는 경우 필요한 범위에 권한을 부여 해야 합니다. 이 모듈의 경우 모든 권한을 사용할 수 있지만 실제 상황에서는 필요한 범위만 부여해야 합니다.
Azure DevOps 조직 이름을 입력한 다음 Enter 키를 누릅니다.
메시지가 표시되면 Azure DevOps PAT를 입력한 다음 Enter 키를 누릅니다.
toy-website-review와 같은 프로젝트 이름을 입력한 다음 Enter 키를 누릅니다.
프로젝트가 만들어지면 브라우저에서 Azure DevOps 조직(있는 https://dev.azure.com/<your-organization-name>/)으로 이동하여 프로젝트를 선택합니다.

리포지토리 복제

이제 사용자 계정에 템플릿 리포지토리의 복사본이 있습니다. 이 리포지토리를 로컬로 복제하여 작업을 시작할 수 있습니다.

코드를 선택한 다음 복사 아이콘을 선택합니다.
Visual Studio Code를 엽니다.
터미널>새 터미널을 선택하여 Visual Studio Code 터미널 창을 엽니다. 이 창은 일반적으로 화면 하단에 열립니다.
터미널에서 GitHub 리포지토리를 복제하려는 로컬 컴퓨터의 디렉터리로 이동합니다. 예를 들어 toy-website-review 폴더에 리포지토리를 복제하려면 다음 명령을 실행합니다.
```
cd toy-website-review
```
이전에 복사한 URL을 입력 git clone 하고 붙여넣은 다음 명령을 실행합니다. 이 명령은 다음과 같습니다.
```
git clone https://github.com/mygithubuser/toy-website-review.git
```
Visual Studio Code 터미널에서 다음 명령을 실행하여 리포지토리 폴더에서 Visual Studio Code를 다시 엽니다.
```
code -r toy-website-review
```

이제 고유한 계정에 프로젝트가 있습니다. 이 리포지토리를 로컬로 복제하여 작업을 시작할 수 있습니다.

저장소>파일을 선택합니다.
복제를 선택합니다.
macOS를 사용하는 경우 Git 리포지토리를 복제하려면 특별한 암호가 필요합니다. Git 자격 증명 생성을 선택하고 표시되는 사용자 이름 및 암호를 다른 안전한 곳에 복사합니다.
VS Code 복제를 선택하세요. Visual Studio Code를 열 수 있도록 허용하라는 메시지가 표시되면 열기를 선택합니다.
리포지토리에 사용할 폴더를 만들고 리포지토리 위치 선택을 선택합니다.
처음으로 이 리포지토리를 사용하는 것이므로 로그인하라는 메시지가 표시됩니다.
- Windows를 사용하는 경우 이 연습의 앞부분에서 Azure DevOps 로그인할 때 사용한 것과 동일한 자격 증명을 입력합니다.
- macOS를 사용하는 경우 방금 전에 생성한 Git 사용자 이름 및 암호를 입력합니다.
Visual Studio Code가 리포지토리를 열라는 메시지를 표시합니다. 열기를 선택합니다.

브랜치 보호 기능 추가

기본 분기에 대한 직접 푸시를 방지하도록 Git 리포지토리를 구성합니다.

브라우저에서 설정을 선택합니다.
브랜치를 선택합니다.
분기 보호 규칙 추가를 선택합니다.
분기 이름 패턴 텍스트 상자에 main을 입력합니다.
병합하기 전에 끌어오기 요청 필요를 선택합니다.

승인 요구를 해제하십시오. 일반적으로 이 옵션을 선택합니다. 그러나 이 예제에서는 자신의 끌어오기 요청을 병합하려고 하지만 승인 필요 옵션이 이를 차단하므로 이 작업을 수행할 수 없습니다.
위의 설정을 무시할 수 없음을 선택합니다.

이 설정을 이 연습의 뒷부분에서 git push에서 main로 전환하는 것이 실패하는 방법을 보여주는 예제로 선택합니다. 프로덕션 환경에서는 관리자 또는 리포지토리 소유자에 대한 직접 병합을 제한하지 않는 것이 좋을 수 있습니다.
페이지 아래쪽에서 만들기를 선택합니다.

GitHub에서 ID를 확인하기 위해 다시 로그인하도록 요청할 수 있습니다.

브랜치 정책 추가

기본 분기에 대한 직접 푸시를 방지하도록 Git 리포지토리를 구성합니다.

브라우저에서 Repos>브랜치로 이동합니다.
메인 브랜치 위에 마우스를 올리고 세 점 아이콘을 선택합니다.
분기 정책을 선택합니다.
분기 정책 창에서 최소 검토자 수 필요 설정을 켜기로 변경합니다.
최소 검토자 수를 1로 변경하고 요청자가 자신의 변경 내용을 승인하도록 허용 옵션을 선택합니다.

비고

여기서는 요청자가 자신의 변경 내용을 승인하도록 허용 옵션을 사용하도록 설정합니다. 이러한 연습에서는 직접 작업하므로 변경 내용을 만들고 승인해야 합니다. 그러나 실제 팀 환경에서는 이 옵션을 사용하지 않을 수 있습니다.

로컬 기능 분기 만들기

Visual Studio Code 터미널에서 다음 문을 실행합니다.
```
git checkout -b add-orders-queue
```
이 명령은 작업할 새 기능 분기를 만듭니다.
‘deploy’ 폴더에서 ‘main.bicep’ 파일을 엽니다.

매개 변수 아래에 큐 이름에 대한 새 변수를 추가합니다.

var storageAccountSkuName = (environmentType == 'prod') ? 'Standard_GRS' : 'Standard_LRS'
var processOrderQueueName = 'processorder'

스토리지 계정 리소스 내에서 큐를 중첩된 자식 리소스로 추가합니다.

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  name: storageAccountName
  location: location
  sku: {
    name: storageAccountSkuName
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
  }

  resource queueServices 'queueServices' existing = {
    name: 'default'

    resource processOrderQueue 'queues' = {
      name: processOrderQueueName
    }
  }
}

appService 모듈 정의에서 스토리지 계정 및 큐 이름을 매개 변수로 추가합니다.

module appService 'modules/appService.bicep' = {
  name: 'appService'
  params: {
    location: location
    appServiceAppName: appServiceAppName
    storageAccountName: storageAccount.name
    processOrderQueueName: storageAccount::queueServices::processOrderQueue.name
    environmentType: environmentType
  }
}

이 코드를 사용하면 애플리케이션이 메시지를 보낼 큐를 찾을 수 있습니다.

main.bicep 파일을 저장합니다.
deploy/modules 폴더에서 appService.bicep 파일을 엽니다.

appService.bicep 파일의 맨 위에 스토리지 계정 및 큐 이름에 대한 새 매개 변수를 추가합니다.

@description('The Azure region into which the resources should be deployed.')
param location string

@description('The name of the App Service app to deploy. This name must be globally unique.')
param appServiceAppName string

@description('The name of the storage account to deploy. This name must be globally unique.')
param storageAccountName string

@description('The name of the queue to deploy for processing orders.')
param processOrderQueueName string

@description('The type of the environment. This must be nonprod or prod.')
@allowed([
  'nonprod'
  'prod'
])
param environmentType string

리소스를 appServiceApp 업데이트하여 스토리지 계정 및 큐 이름을 애플리케이션의 환경 변수에 전파합니다.

resource appServiceApp 'Microsoft.Web/sites@2024-04-01' = {
  name: appServiceAppName
  location: location
  properties: {
    serverFarmId: appServicePlan.id
    httpsOnly: true
    siteConfig: {
      appSettings: [
        {
          name: 'StorageAccountName'
          value: storageAccountName
        }
        {
          name: 'ProcessOrderQueueName'
          value: processOrderQueueName
        }
      ]
    }
  }
}

기능 브랜치를 커밋하고 푸시하십시오

Visual Studio Code 터미널에서 다음 명령을 실행하여 변경 내용을 커밋하고 GitHub 리포지토리에 푸시합니다.

Visual Studio Code 터미널에서 다음 명령을 실행하여 변경 내용을 커밋하고 Azure 리포지토리에 푸시합니다.

git add .
git commit -m "Add orders queue and associated configuration"
git push --set-upstream origin add-orders-queue

기능 분기는 원격 리포지토리의 추가 주문 큐라고도 하는 새 분기로 푸시됩니다.

기능 분기를 main에 병합해 보세요.

메인 브랜치에 직접 푸시하는 것이 바람직하지 않은 이유를 알아보았습니다. 여기서는 기본 분기의 보호 기능이 변경 내용이 보호된 분기에 실수로 푸시되는 것을 어떻게 막는지 확인하기 위해 해당 지침을 깨뜨려보려고 합니다.

Visual Studio Code 터미널에서 다음 명령문을 실행하여 메인 브랜치로 전환하고 add-orders-queue 브랜치를 병합합니다.
```
git checkout main
git merge add-orders-queue
```
명령이 성공적으로 작동했지만, 로컬 Git 리포지토리에서 add-orders-queue 브랜치를 주 브랜치에만 병합했습니다.

다음 문을 실행하여 변경 내용을 GitHub로 푸시합니다.

git push

다음과 같은 오류 메시지와 함께 푸시가 실패합니다.

Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Changes must be made through a pull request.
To https://github.com/mygithubuser/toy-website-review.git
 ! [remote rejected] main -> main (protected branch hook declined)
error: failed to push some refs to 'https://github.com/mygithubuser/toy-website-review.git'

오류 메시지는 주 분기에 대한 푸시가 허용되지 않으며 끌어오기 요청을 사용하여 분기를 업데이트해야 한다는 것을 알려줍니다.

다음 문을 실행하여 병합을 실행 취소합니다.
```
git reset --hard HEAD~1
```
이 명령은 로컬 Git 리포지토리에 주 분기의 상태를 마지막 커밋이 병합되기 전의 상태로 재설정하고 변경 내용을 저장하지 않도록 지시합니다. 추가 주문 큐 분기는 영향을 받지 않습니다.

메인 브랜치에 직접 푸시하는 것이 바람직하지 않은 이유를 알아보았습니다. 여기서는 이 지침을 일부러 위반하여 브랜치 정책이 어떻게 변경 내용을 보호된 브랜치에 실수로 푸시하는 것을 방지하는지 확인해 봅니다.

Visual Studio Code 터미널에서 다음 명령을 실행하여 주 분기로 전환한 후 add-orders-queue 분기를 주 분기에 병합합니다.
```
git checkout main
git merge add-orders-queue
```
명령이 작동했지만, 로컬 Git 리포지토리에서만 add-orders-queue 브랜치를 주 브랜치에 병합했습니다.

다음 문을 실행하여 변경 내용을 Azure Repos로 푸시합니다.

git push