Azure DevOps 브랜치 전략 가이드

효과적인 Git 브랜치 관리와 Azure DevOps 통합

Azure DevOps에서 GitFlow, GitHub Flow 등 다양한 브랜치 전략을 적용하는 방법을 알아본다. Branch Policy, Pull Request, CI/CD 파이프라인과의 통합을 통해 안전하고 효율적인 코드 관리 방법을 제시한다.

Engineering
DevOps
Git
저자

Kwangmin Kim

공개

2024년 01월 02일

1 브랜치 전략 개요

브랜치 전략은 팀이 Git을 사용하여 협업할 때 브랜치를 어떻게 생성, 관리, 병합할 것인지에 대한 규칙과 워크플로우를 정의한다. Azure DevOps는 다양한 브랜치 전략을 지원하며, 각 전략에 맞는 자동화 도구를 제공한다.

1.1 브랜치 전략 선택 기준

1.1.1 팀 규모별 추천 전략

팀 규모 추천 전략 이유
1-3명 GitHub Flow 단순함, 빠른 배포
4-10명 GitLab Flow 환경별 브랜치 관리
10명 이상 GitFlow 체계적인 릴리스 관리

1.1.2 프로젝트 특성별 고려사항

  • 웹 서비스: 빈번한 배포 → GitHub Flow
  • 패키지/라이브러리: 안정적인 릴리스 → GitFlow
  • 엔터프라이즈: 복잡한 승인 프로세스 → GitFlow + 커스텀 정책

2 GitFlow 전략

GitFlow는 Vincent Driessen이 제안한 브랜치 모델로, 대규모 프로젝트에서 안정적인 릴리스 관리를 위해 설계되었다.

2.1 GitFlow 브랜치 구조

2.2 브랜치 유형별 역할

2.2.1 Main Branch (운영)

  • 목적: 프로덕션 배포용 안정적인 코드
  • 특징: 항상 배포 가능한 상태 유지
  • 보호 정책: 직접 커밋 금지, Pull Request만 허용

2.2.2 Develop Branch (개발)

  • 목적: 다음 릴리스를 위한 통합 브랜치
  • 특징: 새로운 기능들이 통합되는 곳
  • 관리: 정기적인 통합 테스트 실행

2.2.3 Feature Branches (기능)

  • 명명 규칙: feature/기능명 또는 feature/이슈번호-기능명
  • 생성 기준: develop 브랜치에서 분기
  • 병합 대상: develop 브랜치로 병합
# Feature 브랜치 생성 및 작업  
git checkout develop  
git pull origin develop  
git checkout -b feature/user-authentication  
# 개발 작업 수행  
git add .  
git commit -m "Add user login functionality"  
git push origin feature/user-authentication

2.2.4 Release Branches (릴리스)

  • 명명 규칙: release/버전명 (예: release/v1.2.0)
  • 목적: 릴리스 준비 및 버그 수정
  • 생명주기: 릴리스 완료 후 main과 develop에 병합

2.2.5 Hotfix Branches (핫픽스)

  • 명명 규칙: hotfix/이슈명 (예: hotfix/security-patch)
  • 목적: 프로덕션 긴급 수정
  • 특징: main에서 분기, main과 develop에 병합

2.3 Azure DevOps에서 GitFlow 구현

2.3.1 Branch Policy 설정

{  
  "type": "GitFlow",  
  "mainBranch": "main",  
  "developBranch": "develop",  
  "policies": {  
    "main": {  
      "requirePullRequest": true,  
      "minimumApproverCount": 2,  
      "requireBuildValidation": true,  
      "requireWorkItemLinking": true  
    },  
    "develop": {  
      "requirePullRequest": true,  
      "minimumApproverCount": 1,  
      "requireBuildValidation": true  
    }  
  }  
}

2.3.2 파이프라인 구성

# azure-pipelines-gitflow.yml  
trigger:  
  branches:  
    include:  
    - main  
    - develop  
    - release/*  
    - hotfix/*  
  paths:  
    exclude:  
    - README.md  

variables:  
  - group: GitFlow-Variables  

stages:  
- stage: Build  
  jobs:  
  - job: BuildJob  
    pool:  
      vmImage: 'ubuntu-latest'  
    steps:  
    - task: NodeTool@0  
      inputs:  
        versionSpec: '16.x'  
    - script: |  
        npm install  
        npm run build  
      displayName: 'Build Application'  

- stage: Test  
  dependsOn: Build  
  jobs:  
  - job: UnitTest  
    steps:  
    - script: npm run test:unit  
      displayName: 'Run Unit Tests'  
  - job: IntegrationTest  
    condition: or(eq(variables['Build.SourceBranch'], 'refs/heads/develop'), startsWith(variables['Build.SourceBranch'], 'refs/heads/release/'))  
    steps:  
    - script: npm run test:integration  
      displayName: 'Run Integration Tests'  

- stage: Deploy  
  condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))  
  jobs:  
  - deployment: Production  
    environment: 'production'  
    strategy:  
      runOnce:  
        deploy:  
          steps:  
          - task: AzureWebApp@1  
            inputs:  
              azureSubscription: 'Azure-Connection'  
              appName: 'my-production-app'

3 GitHub Flow 전략

GitHub Flow는 단순하고 빠른 배포를 위한 경량 브랜치 전략이다.

3.1 GitHub Flow 워크플로우

3.2 핵심 원칙

  1. Main 브랜치는 항상 배포 가능
  2. 새 기능은 브랜치에서 개발
  3. Pull Request를 통한 코드 리뷰
  4. 병합 즉시 배포

3.3 Azure DevOps에서 GitHub Flow 구현

3.3.1 단순화된 Branch Policy

# Branch Policy for GitHub Flow  
branches:  
  main:  
    protection:  
      required_status_checks:  
        strict: true  
        contexts:  
          - "Build"  
          - "Test"  
      required_pull_request_reviews:  
        required_approving_review_count: 1  
      restrictions:  
        users: []  
        teams: ["developers"]

3.3.2 연속 배포 파이프라인

# azure-pipelines-github-flow.yml  
trigger:  
  branches:  
    include:  
    - main  

pool:  
  vmImage: 'ubuntu-latest'  

stages:  
- stage: BuildAndTest  
  jobs:  
  - job: BuildTest  
    steps:  
    - task: NodeTool@0  
      inputs:  
        versionSpec: '16.x'  
    - script: |  
        npm install  
        npm run build  
        npm run test  
      displayName: 'Build and Test'  

- stage: Deploy  
  dependsOn: BuildAndTest  
  condition: succeeded()  
  jobs:  
  - deployment: Production  
    environment: 'production'  
    strategy:  
      runOnce:  
        deploy:  
          steps:  
          - task: AzureWebApp@1  
            inputs:  
              azureSubscription: 'Azure-Connection'  
              appName: 'my-app'  
              package: '$(Pipeline.Workspace)/**/*.zip'

4 GitLab Flow 전략

GitLab Flow는 GitHub Flow의 단순함과 GitFlow의 환경 관리를 결합한 전략이다.

4.1 환경별 브랜치 구조

4.2 브랜치 구성

  • Main: 개발 완료된 기능
  • Staging: 스테이징 환경 배포
  • Production: 프로덕션 환경 배포

4.3 Azure DevOps 구현

# azure-pipelines-gitlab-flow.yml  
trigger:  
  branches:  
    include:  
    - main  
    - staging  
    - production  

variables:  
  - name: environment  
    value: $[  
      switch(  
        variables['Build.SourceBranch'],  
        'refs/heads/main', 'development',  
        'refs/heads/staging', 'staging',  
        'refs/heads/production', 'production',  
        'development'  
      )  
    ]  

stages:  
- stage: Build  
  jobs:  
  - job: BuildJob  
    steps:  
    - script: |  
        echo "Building for $(environment)"  
        npm install  
        npm run build  
      displayName: 'Build Application'  

- stage: Deploy  
  jobs:  
  - deployment: DeployToEnvironment  
    environment: $(environment)  
    strategy:  
      runOnce:  
        deploy:  
          steps:  
          - task: AzureWebApp@1  
            inputs:  
              azureSubscription: 'Azure-Connection'  
              appName: 'my-app-$(environment)'

5 Branch Policy 상세 설정

Azure DevOps의 Branch Policy는 브랜치 보호와 품질 관리를 자동화한다.

5.1 필수 정책 구성

5.1.1 Pull Request 필수

{  
  "type": "RequirePullRequest",  
  "settings": {  
    "minimumApproverCount": 2,  
    "creatorVoteCounts": false,  
    "allowDownvotes": true,  
    "resetOnSourcePush": true,  
    "requireVoteOnLastIteration": true  
  }  
}

5.1.2 빌드 검증 필수

{  
  "type": "RequireBuildValidation",  
  "settings": {  
    "buildDefinitionId": 123,  
    "queueOnSourceUpdateOnly": true,  
    "manualQueueOnly": false,  
    "displayName": "CI Build",  
    "validDuration": 720  
  }  
}

5.1.3 Work Item 연결 필수

{  
  "type": "RequireWorkItemLinking",  
  "settings": {  
    "isEnabled": true  
  }  
}

5.1.4 경로별 리뷰어 지정

{  
  "type": "RequireReviewerByPath",  
  "settings": {  
    "requiredReviewers": [  
      {  
        "path": "/src/security/*",  
        "reviewers": ["security-team@company.com"]  
      },  
      {  
        "path": "/database/*",  
        "reviewers": ["dba-team@company.com"]  
      }  
    ]  
  }  
}

5.2 실제 Branch Policy 설정 예시

5.2.1 엔터프라이즈 환경

# Enterprise Branch Policy  
main:  
  protection:  
    - require_pull_request_reviews:  
        required_approving_review_count: 3  
        dismiss_stale_reviews: true  
        require_code_owner_reviews: true  
    - require_status_checks:  
        strict: true  
        contexts:  
          - "Build"  
          - "Security Scan"  
          - "Code Quality"  
          - "Integration Tests"  
    - require_signed_commits: true  
    - require_work_item_linking: true  
    - auto_merge_policies:  
        - require_up_to_date_before_merge: true  
        - delete_head_branch: true

5.2.2 스타트업 환경

# Startup Branch Policy  
main:  
  protection:  
    - require_pull_request_reviews:  
        required_approving_review_count: 1  
    - require_status_checks:  
        contexts:  
          - "Build"  
          - "Tests"  
    - auto_merge_policies:  
        - delete_head_branch: true

6 Pull Request 워크플로우

6.1 표준 PR 프로세스

6.1.1 PR 생성

# 기능 브랜치에서 작업 완료 후  
git push origin feature/user-profile  
# Azure DevOps에서 PR 생성

6.1.2 PR 템플릿

## 변경 사항 요약  
- [ ] 새로운 기능 추가  
- [ ] 버그 수정  
- [ ] 리팩토링  
- [ ] 문서 업데이트  

## 상세 설명  
이 PR에서 변경된 내용을 자세히 설명합니다.  

## 테스트 계획  
- [ ] 단위 테스트 추가/수정  
- [ ] 통합 테스트 확인  
- [ ] 수동 테스트 완료  

## 체크리스트  
- [ ] 코드 리뷰 요청  
- [ ] 빌드 성공 확인  
- [ ] 테스트 통과 확인  
- [ ] 문서 업데이트 완료  

## 관련 Work Item  
- Closes #123  
- Related to #456  

## 스크린샷 (UI 변경 시)  
[스크린샷 첨부]

6.1.3 자동화된 검증

# PR 검증 파이프라인  
pr:  
  branches:  
    include:  
    - main  
    - develop  
  paths:  
    exclude:  
    - docs/*  
    - '*.md'  

jobs:  
- job: PRValidation  
  displayName: 'Pull Request Validation'  
  pool:  
    vmImage: 'ubuntu-latest'  
  steps:  
  - task: NodeTool@0  
    inputs:  
      versionSpec: '16.x'  
  
  - script: |  
      npm install  
      npm run lint  
      npm run test:coverage  
    displayName: 'Code Quality Checks'  
  
  - task: PublishTestResults@2  
    inputs:  
      testResultsFormat: 'JUnit'  
      testResultsFiles: '**/test-results.xml'  
  
  - task: PublishCodeCoverageResults@1  
    inputs:  
      codeCoverageTool: 'Cobertura'  
      summaryFileLocation: '**/coverage.xml'

6.2 코드 리뷰 베스트 프랙티스

6.2.1 리뷰어 가이드라인

  1. 기능적 검토
    • 요구사항 충족 여부
    • 비즈니스 로직 정확성
    • 에러 처리 적절성
  2. 코드 품질 검토
    • 가독성 및 유지보수성
    • 성능 최적화
    • 보안 취약점
  3. 아키텍처 검토
    • 설계 원칙 준수
    • 의존성 관리
    • 확장성 고려

6.2.2 효과적인 피드백 방법

# 좋은 피드백 예시  
## 🔧 개선 제안  
이 부분에서 `Array.forEach` 대신 `Array.map`을 사용하면 더 함수형 프로그래밍 스타일에 맞을 것 같습니다.  

## ⚠️ 잠재적 이슈  
null 체크가 없어서 런타임 에러가 발생할 수 있습니다.   
`user?.profile?.email` 형태로 optional chaining을 사용해보세요.  

## 👍 잘한 점  
에러 처리가 매우 잘 되어 있네요! 사용자 경험을 많이 고려한 것 같습니다.

7 브랜치 전략별 실무 적용 사례

7.1 사례 1: E-commerce 플랫폼 (GitFlow)

7.1.1 팀 구성

  • 개발자 15명
  • QA 팀 3명
  • DevOps 엔지니어 2명

7.1.2 브랜치 구조

main (프로덕션)  
├── develop (개발 통합)  
├── release/v2.1.0 (릴리스 준비)  
├── feature/payment-gateway (결제 시스템)  
├── feature/recommendation-engine (추천 엔진)  
└── hotfix/checkout-bug (체크아웃 버그 수정)

7.1.3 릴리스 프로세스

  1. 스프린트 시작: develop에서 feature 브랜치 생성
  2. 기능 개발: 2주간 개발 후 PR을 통해 develop에 병합
  3. 릴리스 준비: develop에서 release 브랜치 생성
  4. QA 테스트: release 브랜치에서 버그 수정
  5. 프로덕션 배포: release를 main에 병합 후 배포

7.2 사례 2: SaaS 스타트업 (GitHub Flow)

7.2.1 팀 구성

  • 개발자 5명
  • 제품 매니저 1명

7.2.2 워크플로우

main (항상 배포 가능)  
├── feature/user-dashboard (사용자 대시보드)  
├── feature/api-integration (API 통합)  
└── feature/mobile-responsive (모바일 대응)

7.2.3 배포 프로세스

  1. 기능 개발: main에서 feature 브랜치 생성
  2. 개발 완료: PR 생성 및 리뷰 요청
  3. 자동 배포: PR 병합 시 자동으로 프로덕션 배포

7.3 사례 3: 금융 서비스 (GitLab Flow)

7.3.1 규제 요구사항

  • 모든 변경사항 승인 필요
  • 단계별 배포 검증 필수
  • 롤백 계획 수립

7.3.2 환경별 브랜치

main (개발 완료)  
├── staging (스테이징 환경)  
└── production (프로덕션 환경)

7.3.3 승인 프로세스

  1. 개발 완료: main 브랜치에 병합
  2. 스테이징 배포: 승인 후 staging 브랜치에 병합
  3. 프로덕션 배포: 최종 승인 후 production 브랜치에 병합

8 브랜치 전략 마이그레이션

8.1 기존 전략에서 새 전략으로 전환

8.1.1 GitFlow → GitHub Flow 전환

# 1. 기존 브랜치 정리  
git branch -d develop  
git push origin --delete develop  

# 2. 새로운 정책 적용  
# Branch Policy를 GitHub Flow에 맞게 수정  

# 3. 팀 교육 및 가이드라인 업데이트

8.1.2 전환 시 고려사항

  1. 팀 규모 변화: 팀이 커지면 더 체계적인 전략 필요
  2. 배포 빈도: 빈번한 배포가 필요하면 단순한 전략 선택
  3. 규제 요구사항: 승인 프로세스가 복잡하면 GitFlow 적합
  4. 기술 부채: 기존 코드베이스의 안정성 고려

9 모니터링 및 메트릭

9.1 브랜치 전략 효과성 측정

9.1.1 핵심 지표

  1. Lead Time: 코드 작성부터 배포까지 시간
  2. Deployment Frequency: 배포 빈도
  3. Mean Time to Recovery: 장애 복구 시간
  4. Change Failure Rate: 배포 실패율

9.1.2 Azure DevOps Analytics 활용

-- Work Item 완료 시간 분석  
SELECT   
    WorkItemType,  
    AVG(DATEDIFF(day, CreatedDate, ClosedDate)) as AvgLeadTime  
FROM WorkItems   
WHERE State = 'Closed'  
GROUP BY WorkItemType

9.1.3 대시보드 구성

# Azure DevOps Dashboard Widget  
widgets:  
  - type: "velocity-chart"  
    title: "Team Velocity"  
    configuration:  
      iterations: 6  
  
  - type: "lead-time-widget"  
    title: "Lead Time Trend"  
    configuration:  
      workItemTypes: ["User Story", "Bug"]  
  
  - type: "deployment-frequency"  
    title: "Deployment Frequency"  
    configuration:  
      environment: "production"

10 결론

효과적인 브랜치 전략은 팀의 생산성과 코드 품질에 직접적인 영향을 미친다. Azure DevOps는 다양한 브랜치 전략을 지원하며, Branch Policy, Pull Request, CI/CD 파이프라인을 통해 각 전략을 효과적으로 구현할 수 있다.

중요한 것은 팀의 규모, 프로젝트 특성, 배포 요구사항에 맞는 전략을 선택하고, 지속적으로 개선해나가는 것이다. Azure DevOps의 통합 환경을 활용하면 브랜치 전략을 단순한 규칙이 아닌 자동화된 워크플로우로 구현할 수 있다.

Subscribe

Enjoy this blog? Get notified of new posts by email: