분기 이해

8분

Bicep 템플릿을 빌드하고 Git 리포지토리 내에서 작업하는 경우 팀의 모든 변경 내용은 결국 리포지토리의 기본 분기에 병합됩니다. 프로덕션 환경에 원치 않는 변경 내용이 배포되지 않도록 기본 분기를 보호하는 것이 중요합니다. 그러나 기여자가 유연하게 작업하고, 팀과 협업하고, 아이디어를 쉽게 시험해 볼 수 있기도 원합니다.

이 단원에서는 분기 전략 및 기본 분기를 보호하는 방법에 관해 알아봅니다. 분기에 대한 검토 프로세스를 설정하는 방법도 알아봅니다.

기본 분기를 보호하려는 이유는 무엇인가요?

기본 분기는 Azure 환경에 배포되는 항목의 데이터 소스입니다. 대다수의 솔루션에는 개발, QA(품질 보증), 프로덕션과 같은 여러 환경이 있습니다. 다른 시나리오에서는 프로덕션 환경만 있을 수 있습니다. 사용하는 환경 수와 관계없이 기본 분기는 팀 구성원이 기여하는 분기입니다. 그 변화는 결국 기본 분기에 도달합니다.

일반적인 프로세스는 다음과 같습니다.

팀 구성원이 공유 리포지토리를 복제합니다.
리포지토리의 자체 로컬 복사본에 있는 분기에서 로컬 변경을 수행합니다.
변경 내용이 완료되면 로컬 리포지토리의 기본 분기에서 이러한 변경 내용을 병합합니다.
이러한 변경 내용을 원격 리포지토리의 기본 분기로 푸시합니다.
일부 시나리오에서는 원격 리포지토리의 푸시가 자동화된 파이프라인을 트리거하여 코드를 확인, 테스트, 배포합니다. 다른 Microsoft Learn 모듈의 파이프라인에 대해 자세히 알아봅니다.

다음 다이어그램은 이 프로세스를 보여 줍니다.

로컬 변경을 수행하고, 원격 기본 분기에 변경 내용을 푸시하고, 파이프라인을 트리거하는 과정을 보여주는 다이어그램

팀 구성원의 변경 내용에 미묘한 버그가 있다고 가정하겠습니다. 전체 프로세스가 실행된 후 버그는 이제 프로젝트의 기본 분기에 있으며 프로덕션에 배포됩니다. 배포를 시도하고 오류가 발생할 때까지 검색되지 않을 수도 있습니다. 또는 다른 유형의 버그의 경우 배포가 성공할 수도 있지만, 나중에 미묘한 문제가 발생할 수 있습니다.

또 다른 시나리오에서는 팀의 한 구성원이 하나의 기능을 작업하는 중이고 완료된 기능 작업의 절반을 공유 리포지토리의 기본 분기로 푸시한다고 가정합니다. 이제 완료되지 않았거나 테스트되지 않은 기본 분기에 대한 변경 내용이 있습니다. 이러한 변경 내용은 프로덕션 환경에 배포하면 안 됩니다. 기능이 완료될 때까지 프로덕션에 대한 배포를 차단해야 할 수 있습니다. 새로 완성된 기능이 기본 분기에 있는 경우 고객에게 배포하지 못할 수 있습니다.

팁

이러한 문제는 특히 코드에 기여하는 사람이 여럿이 있는 대규모 팀에서 까다롭지만, 이 모듈의 지침은 둘 이상의 사용자와 공동 작업을 하게 되는 즉시 유용할 수 있습니다. 이 지침은 혼자서 프로젝트에서 작업하지만 동시에 여러 기능을 작업하는 경우에도 유용합니다.

더 나은 작업 방법은 작업하는 동안 변경 내용을 별도로 유지하는 것입니다. 그런 다음 다른 팀 구성원이 변경 내용을 검토한 후 팀의 공유 리포지토리의 기본 분기에 병합할 수 있습니다. 이 프로세스를 통해 팀에서는 사용자가 병합을 승인하기 전에 변경 내용을 정보에 따라 결정할 수 있습니다.

기능 분기

기능 분기는 개발자가 시작하는 새 작업을 나타냅니다. 작업은 Bicep 파일에 정의된 리소스 구성의 변경이거나 배포해야 하는 새 리소스 집합일 수 있습니다. 새 작업을 시작할 때마다 새 기능 분기를 만듭니다.

기본 분기에서 기능 분기를 만듭니다. 분기를 만들 때 Azure 환경의 현재 상태에서 시작하는지 확인합니다. 그런 다음 필요한 모든 변경 내용을 적용합니다.

코드의 모든 변경 내용이 기능 분기에 커밋되므로 리포지토리의 기본 분기를 방해하지 않습니다. 팀의 다른 누군가가 기본 분기를 긴급하게 변경해야 한다면 다른 기능 분기에서 독립적으로 변경할 수 있습니다.

기능 분기에서도 협업을 할 수 있습니다. 기능 분기를 공유 리포지토리에 게시하고 푸시하면 사용자와 팀 구성원이 함께 변경 작업을 수행할 수 있습니다. 또한 휴가 때 다른 사람에게 기능을 넘겨서 완료할 수도 있습니다.

기능 분기 업데이트

기능 분기가 진행되는 동안 다른 기능이 리포지토리의 기본 분기에 병합되는 경우도 있습니다. 그렇게 되면 기능 분기와 프로젝트의 기본 분기가 분리됩니다. 두 분기가 멀어질수록 나중에 두 분기를 다시 병합하는 것이 더 어려워지고 병합 충돌이 더 많이 발생할 수 있습니다.

리포지토리의 기본 분기에 적용한 모든 변경 내용을 통합할 수 있도록 기능 분기를 정기적으로 업데이트해야 합니다. 기능 분기를 기본 분기에 다시 병합하기 전에 기능 분기를 업데이트하는 것도 좋습니다. 이렇게 하면 새 변경 내용을 기본 분기에 쉽게 병합할 수 있습니다.

팁

기본 분기를 기능 분기에 자주 병합합니다.

수명이 짧은 작은 분기 사용

수명이 짧은 기능 분기를 목표로 합니다. 이러한 방식은 분기가 동기화되어 있지 않은 시간을 줄여 병합 충돌을 방지해 줍니다. 또한 변경한 내용을 동료들이 쉽게 이해할 수 있어 다른 누군가가 변경 내용을 검토해야 할 때 유용합니다.

대규모 작업을 소규모 작업으로 분할하고 각각 새로운 기능 분기를 만듭니다. 기능이 클수록 작업 시간이 길어지고 기능 분기의 수명도 길어집니다. 각 기능 분기를 병합할 때 프로덕션에 더 작은 규모의 변경 내용을 배포하면서 점진적으로 더 광범위한 작업을 빌드할 수 있습니다.

Bicep 코드 집합을 일부 변경한다고 가정해 보겠습니다. 일부 리소스 정의를 모듈로 이동하고 있습니다. Bicep 파일에 새 리소스도 추가해야 합니다. 먼저 자체 분기에서 모든 모듈 리팩터링을 수행하는 것이 좋습니다. 모듈이 병합된 후에는 Bicep 파일에 추가 작업을 시작할 수 있습니다. 변경 내용을 분리함으로써 각 변경 내용과 분기를 작고 이해하기 쉽게 유지할 수 있습니다.

이러한 방식으로 작업하는 경우 if 키워드를 사용하여 리소스가 준비될 때까지 리소스 배포를 비활성화하는 것이 도움이 될 수 있습니다. 다음 예제 코드에서는 if 키워드를 사용하여 스토리지 계정을 정의하지만 모든 변경 내용이 완료될 때까지 스토리지 계정 배포를 비활성화하는 Bicep 파일을 만드는 방법을 보여 줍니다.

@description('Specifies whether the storage account is ready to be deployed.')
param storageAccountReady bool = false

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-05-01' = if (storageAccountReady) {
  name: storageAccountName
  location: location
  kind: 'StorageV2'
  sku: {
    name: 'Premium_LRS'
  }
}

매개 변수를 사용하여 다른 환경에서 storageAccountReady 변수에 대해 서로 다른 값을 지정할 수 있습니다. 예를 들어 매개 변수 값을 테스트 환경에서는 true로 설정하고 프로덕션 환경에서는 false로 설정할 수 있습니다. 이렇게 하면 테스트 환경에서 새 스토리지 계정을 사용해 볼 수 있습니다.

참고

프로덕션에서 기능을 사용해야 하는 때가 되면 다음 단계를 모두 수행해야 변경 내용이 적용됩니다.

매개 변수 값을 변경합니다.
Bicep 파일을 다시 배포합니다.

기능 분기 병합

기능 분기 작업을 완료한 후에는 이를 리포지토리의 기본 분기에 병합해야 합니다. 병합하기 전에 기능 분기에서 변경한 내용을 검토하는 것이 좋습니다. 끌어오기 요청을 사용하면 코드를 검토할 수 있습니다. 이 모듈의 뒷부분에서 끌어오기 요청에 대해 좀 더 자세히 알아봅니다.

분기 보호

GitHub에서는 공유 리포지토리의 기본 분기에 대한 분기 보호를 구성할 수 있습니다. 분기 보호는 다음과 같은 규칙을 적용합니다.

끌어오기 요청을 제외하고는 변경 사항을 기본 분기에 병합할 수 없습니다.
적어도 두 명 이상의 다른 사용자가 변경 내용을 검토해야 합니다.

누군가가 커밋을 보호된 분기에 직접 푸시하려고 하면 푸시는 실패하게 됩니다. 다음 단원에서는 분기 보호를 적용하는 방법을 알아봅니다.

분기 정책

Azure DevOps에서는 공유 리포지토리의 기본 분기에 대한 분기 정책을 구성할 수 있습니다. 분기 정책은 다음과 같은 규칙을 적용합니다.

끌어오기 요청을 제외하고는 변경 사항을 기본 분기에 병합할 수 없습니다.
적어도 두 명 이상의 다른 사용자가 변경 내용을 검토해야 합니다.

누군가가 커밋을 보호된 분기에 직접 푸시하려고 하면 푸시는 실패하게 됩니다. 다음 단원에서 분기 정책을 적용하는 방법을 알아봅니다.

기타 분기 전략

Bicep 코드에서 협업할 때 다양한 분기 전략을 사용할 수 있습니다. 각 분기 전략에는 장단점이 있습니다.

지금까지 배운 프로세스는 트렁크 기반 개발 전략의 버전입니다. 이 분기 전략에서는 수명이 짧은 기능 분기에서 작업이 수행된 다음 단일 기본 분기에 병합됩니다. 변경 내용이 병합될 때마다 공유 리포지토리의 기본 분기 콘텐츠를 프로덕션에 자동으로 배포하거나, 일정을 잡아(예: 매주) 변경 내용을 일괄 처리하여 릴리스할 수 있습니다. 트렁크 기반 개발은 이해하기 쉽고 많은 오버헤드 없이 협업을 가능하게 합니다.

일부 팀은 완료한 작업과 프로덕션에 배포한 작업을 분리합니다. 기능 분기를 병합하기 위한 대상으로 수명이 긴 개발 분기를 사용합니다. 프로덕션에 변경 내용을 릴리스할 때 개발 분기를 기본 분기에 병합합니다.

다른 분기 전략을 사용하려면 릴리스 분기를 만들어야 합니다. 프로덕션에 배포할 준비가 된 변경 내용 집합이 있으면 배포할 변경 내용이 포함된 릴리스 분기를 만듭니다. 이러한 전략은 Azure 인프라를 정기적으로 배포하거나 변경 내용을 다른 여러 팀과 통합할 때 의미가 있습니다.

다른 분기 전략에는 Gitflow, GitHub Flow, GitLab Flow가 있습니다. GitHub Flow 또는 GitLab Flow를 사용하는 팀도 있습니다. 이는 다른 팀과 작업을 분리할 수 있을 뿐만 아니라 긴급 버그 수정과 다른 변경 내용을 분리할 수 있기 때문입니다. 이러한 프로세스를 통해 체리 따기라고 불리는 솔루션의 다른 릴리스로 커밋을 분리할 수도 있습니다. 그러나 변경 내용이 서로 호환되도록 하려면 더 많은 관리가 필요합니다. 이 모듈의 요약 섹션에서 이러한 분기 전략에 관한 자세한 정보 링크를 제공합니다.

팀에 적합한 분기 전략은 팀의 작업, 협업 및 변경 내용 릴리스 방식에 따라 달라집니다. 트렁크 기반 개발과 같은 간단한 프로세스에서 시작하는 것이 좋습니다. 팀이 이 프로세스를 사용하여 효과적으로 작업할 수 없는 경우 점진적으로 분기의 다른 계층을 도입하거나 분기 전략을 채택합니다. 하지만 분기를 추가할수록 리포지토리 관리는 더 복잡해진다는 사실에 유념해야 합니다.

팁

어떤 분기 전략을 사용하든, 분기 정책을 사용하여 기본 분기를 보호하고 끌어오기 요청을 통해 변경 내용을 검토하는 것이 좋습니다. 다른 분기 전략에서는 보호해야 하는 중요한 분기도 도입됩니다.

이 모듈에서는 쉽게 사용할 수 있으므로 기능 분기와 함께 트렁크 기반 개발을 사용합니다.