전략적으로 분기

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

소스 코드는 개발 노력에서 중요한 자산입니다. 그러나 여러 개발자가 파일 업데이트에 대해 동시에 작업하는 경우 원본 파일을 효과적으로 관리하고 발전하는 것이 어려울 수 있습니다. 버전 제어 시스템을 사용하여 소스 코드를 공유 리포지토리에 저장하고, 병렬 개발 작업을 격리하고, 코드 변경 내용을 통합하고, 이전 파일 버전을 복구할 수 있습니다. 버전 제어의 핵심 요소는 동시 개발을 가능하게 하는 분기입니다. 전략적으로 분기하는 경우 기본 소프트웨어의 여러 버전의 순서와 일관성을 확인할 수 있습니다.

Team Foundation은 유연하고 안정적인 버전 제어 시스템을 제공합니다. Team Foundation 버전 제어를 사용하여 팀에서 작업하는 소스 코드, 문서, 작업 항목 및 기타 중요한 정보를 개발하는 동안 여러 수정 버전을 관리할 수 있습니다.

팀이 여러 프로젝트 릴리스를 통해 동시에 여러 변경 내용을 도입하는 동안 코드를 어떻게 관리하나요?

버전 제어 시스템을 사용하는 경우 분기 구조를 설정하는 방법을 고려해야 합니다. 소스 코드 파일을 미러 분기를 만들 수 있습니다. 그런 다음 원본에 영향을 주지 않고 분기를 변경할 수 있습니다. 예를 들어 다음 그림의 분기 구조에서 보여 주듯이 MAIN 분기는 통합 테스트를 통과한 완료된 기능을 포함하고 DEVELOPMENT 분기는 생성 중인 코드를 포함합니다. DEVELOPMENT 분기의 새 기능이 완료되고 통합 테스트를 통과할 수 있는 경우 개발 분기에서 MAIN 분기로 코드를 승격할 수 있습니다. 이 프로세스를 역방향 통합이라고 합니다. 반대로 MAIN 분기에서 DEVELOPMENT 분기로 코드를 병합하는 경우 프로세스를 정방향 통합이라고 합니다.

코드 분기를 만들고 병합하는 방법에 대한 자세한 내용은 CodePlex 웹 사이트의 다음 페이지를 참조하세요. Team Foundation Server Branching Guide 2.0.

분기 및 병합에는 다음 원칙이 수반됩니다.

1. 각 분기에는 코드를 이 분기에 통합하는 방법에 대한 정의된 정책이 있어야 합니다. 예를 들어 이전 그림의 분기 구조에서 MAIN 분기를 소유하고 관리할 팀 구성원을 할당할 수 있습니다. 이 멤버는 초기 분기 작업을 수행하고, DEVELOPMENT 분기에서 MAIN 분기로 변경 내용을 역방향으로 통합하고, MAIN 분기에서 DEVELOPMENT 분기로 변경 내용을 통합하는 작업을 담당합니다. MAIN 분기가 다른 분기의 변경 내용도 통합하는 경우 정방향 통합이 중요합니다.

2. MAIN 분기는 항상 릴리스할 준비가 되도록 통합 테스트를 통과한 코드를 포함해야 합니다.

3. 개발(또는 작업) 분기는 팀 구성원이 정기적으로 변경 내용을 검사 때문에 지속적으로 진화합니다.

4. 레이블은 특정 시간에 분기에 있는 파일의 스냅샷.

   자세한 내용은 레이블을 사용하여 파일 스냅샷 가져옵니다.

Team Foundation Build를 사용하면 분기용 빌드 유형(수동, 연속, 제어, 롤링 및 예약)을 선택할 수 있습니다. MAIN 분기에는 제어된 검사 빌드 유형이 있는 것이 좋습니다. 즉, 개발 분기는 역방향 통합을 커밋하기 전에 MAIN 분기에 대한 모든 요구 사항을 통과해야 합니다. 개발 분기는 팀이 새 검사 개발 분기에 영향을 줄 때 가능한 한 빨리 알고 있어야 하므로 연속 빌드 유형을 실행해야 합니다.

팀이 얼마나 자주 역방향 통합 및 전달 통합을 해야 하나요?

다음 그림과 같이 사용자 스토리를 완료할 때는 최소한 역방향 통합 및 전달 통합이 발생해야 합니다. 각 팀이 완전성을 다르게 정의할 수 있지만 일반적으로 사용자 스토리의 완성은 기능과 해당 단위 테스트를 모두 완료한다는 것을 의미합니다. 단위 테스트가 DEVELOPMENT 분기의 안정성을 확인한 후에만 MAIN 분기에 역방향 통합할 수 있습니다.

둘 이상의 작업(DEVELOPMENT) 분기가 있는 경우 모든 분기가 MAIN 분기에 통합되는 즉시 모든 작업 분기에 전달 통합이 수행되어야 합니다. MAIN 분기는 안정적으로 유지되므로 정방향 통합이 안전합니다. 작업 분기가 안정적이라고 보장할 수 없기 때문에 작업 분기에서 충돌 또는 오류가 발생할 수 있습니다.

가능한 한 빨리 모든 충돌을 해결하는 것이 중요합니다. MAIN 분기에 대해 제어된 검사 사용하면 품질 게이트가 MAIN 분기의 충돌 또는 오류를 방지하는 데 도움이 되므로 역방향 통합을 훨씬 쉽게 만들 수 있습니다. 자세한 내용은 제어된 검사 빌드 프로세스로 제어되는 폴더에 체크 인을 참조하세요.

팀은 다양한 사용자 스토리를 구현하는 원본을 어떻게 관리하나요?

다음 그림에서 볼 수 있듯이 정기적으로 작업 분기의 변경 내용을 검사 사용자 스토리를 완료할 수 있습니다. 동일한 분기에 동시에 여러 사용자 스토리를 구현할 수 있습니다. 그러나 진행 중인 모든 작업을 완료하는 경우에만 MAIN 분기에 다시 통합할 수 있습니다. 대규모 사용자 스토리가 많은 작은 스토리의 통합을 차단하지 않도록 하려면 사용자 스토리를 비슷한 크기로 그룹화하는 것이 좋습니다. 두 개의 사용자 스토리 집합을 두 개의 분기로 분할할 수 있습니다.

팀은 언제 분기를 추가해야 하나요?

다음과 같은 상황에서 분기를 만들어야 합니다.

• 기존 분기와 다른 일정/주기로 코드를 해제해야 하는 경우

• 코드에 다른 분기 정책이 필요한 경우 새 정책이 있는 새 분기를 만드는 경우 프로젝트에 전략적 가치를 추가할 수 있습니다.

• 고객에게 기능이 릴리스되는 경우 팀은 계획된 릴리스 주기에 영향을 미치지 않는 변경을 계획합니다.

높은 통합 비용이 발생하므로 각 사용자 스토리에 대한 분기를 만들면 안 됩니다. TFVC는 분기를 쉽게 만들지만 분기가 많은 경우 분기 관리 오버헤드가 클 수 있습니다.

팀은 버전 제어 관점에서 릴리스를 어떻게 관리하나요?

팀은 스프린트가 끝날 때 코드를 릴리스할 수 있어야 합니다. Team Foundation Server를 사용하면 특정 시점에 코드의 스냅샷 수 있도록 분기에 레이블을 지정할 수 있습니다. 다음 그림과 같이 릴리스에 대한 MAIN 분기에 레이블을 지정할 수 있습니다. 이렇게 하면 이 시점에서 분기를 해당 상태로 되돌릴 수 있습니다.

릴리스에서 업데이트를 구현해야 하므로 릴리스에 대한 분기를 만들면 팀이 향후 릴리스와 충돌하지 않고도 다음 스프린트에서 독립적으로 작업할 수 있습니다. 다음 그림에서는 업데이트에 대한 코드를 포함하고 두 번째 스프린트가 끝날 때 릴리스된 후 MAIN 분기에 역순으로 통합되는 분기를 보여 줍니다.

릴리스에 대한 분기를 만들 때 가장 안정적인 MAIN 분기에서 해당 분기를 만들어야 합니다. 작업 분기에서 릴리스를 위해 분기하는 경우 작업 분기의 안정성이 보장되지 않으므로 통합 문제가 발생할 수 있습니다.

관련된 문서

• 효과적인 분기 전략 선택