전략적 분기

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

Team Foundation에서는 융통성 있고 안정적인 버전 제어 시스템을 제공합니다. 팀에서 작업 중인 소스 코드, 문서, 작업 항목 및 기타 중요한 정보를 개발하는 동안 Team Foundation 버전 제어를 사용하여 여러 수정 버전을 관리할 수 있습니다. Visual Studio Team Foundation Server의 버전 제어에 대한 자세한 내용은 버전 제어 사용을 참조하십시오.

여러 프로젝트 릴리스를 통해 여러 변경 내용을 동시에 전달하는 경우 팀에서 코드를 관리하는 방법

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

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

분기 및 병합 시에는 다음 원칙을 따라야 합니다.

1. 각 분기에는 코드를 해당 분기로 통합하는 방법에 대한 정책이 정의되어 있어야 합니다. 예를 들어 앞에 나온 그림의 분기 구조에서는 MAIN 분기를 담당하고 관리할 팀 멤버를 할당할 수 있습니다. 이 멤버는 초기 분기 작업과 DEVELOPMENT 분기의 변경 내용을 MAIN 분기로 역방향 통합하고 MAIN 분기의 변경 내용을 DEVELOPMENT 분기로 정방향 통합하는 작업을 담당합니다. 정방향 통합은 MAIN 분기가 다른 분기에서의 변경 내용도 통합하는 경우에 중요합니다.

2. MAIN 분기는 언제든지 릴리스할 수 있도록 통합 테스트를 통과한 코드를 포함해야 합니다.

3. 팀 멤버가 변경 내용을 정기적으로 체크 인하므로 DEVELOPMENT(또는 작업) 분기는 지속적으로 발전합니다.

4. 레이블은 특정 시점에 분기에 포함되어 있는 파일의 스냅숏입니다.

   자세한 내용은 레이블을 사용하여 파일의 스냅숏 만들기를 참조하십시오.

Team Foundation Build에서는 수동 빌드, 연속 빌드, 제어된 빌드, 롤링 빌드 및 예약된 빌드와 같은 여러 빌드 형식 중에서 분기에 사용할 형식을 선택할 수 있습니다. MAIN 분기에는 제어된 체크 인 빌드 형식을 선택하는 것이 좋습니다. 이 경우 DEVELOPMENT 분기가 MAIN 분기에 대한 모든 요구 사항을 만족해야 사용자가 역방향 통합을 커밋할 수 있습니다. 새 체크 인이 DEVELOPMENT 분기에 영향을 주는 경우 팀에서 가능한 한 빨리 확인해야 하므로 DEVELOPMENT 분기에서는 연속 빌드 형식을 실행해야 합니다.

팀의 역방향 통합 및 정방향 통합 실행 빈도

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

작업(DEVELOPMENT) 분기가 두 개 이상 있는 경우 MAIN 분기에 통합되는 분가기 있으면 그 즉시 모든 작업 분기로 정방향 통합이 수행되어야 합니다. MAIN 분기는 안정적으로 유지되므로 정방향 통합은 안전합니다. 그러나 작업 분기는 안정적이지 않을 수 있으므로 작업 분기에서 충돌 또는 오류가 발생할 수도 있습니다.

모든 충돌은 가능한 한 빨리 해결해야 합니다. 품질 게이트는 MAIN 분기에서 충돌 또는 오류를 방지하는 데 도움이 되므로 MAIN 분기에 제어된 체크 인을 사용하면 역방향 통합을 훨씬 쉽게 실행할 수 있습니다. 자세한 내용은 제어된 체크 인 빌드에 의해 제어되는 보류 중인 변경 내용 체크 인을 참조하십시오.

팀에서 서로 다른 사용자 스토리를 구현하는 소스를 관리하는 방법

다음 그림에 표시된 것과 같이 변경 내용을 정기적으로 작업 분기에 체크 인하여 사용자 스토리를 완료할 수 있습니다. 여러 사용자 스토리를 동일한 분기에서 동시에 구현할 수 있습니다. 그러나 진행 중인 모든 작업을 완료한 경우에만 MAIN 분기로 역방향 통합을 수행할 수 있습니다. 큰 사용자 스토리가 여러 개의 작은 사용자 스토리를 통합하는 데 방해가 되지 않도록 유사한 크기별로 사용자 스토리를 그룹화하는 것이 좋습니다. 두 개의 사용자 스토리 집합을 두 개의 분기로 분할할 수 있습니다.

팀에서 분기를 추가해야 하는 경우

다음과 같은 경우 분기를 만들어야 합니다.

• 기존 분기와 다른 일정 및 주기로 코드를 릴리스해야 하는 경우

• 코드에 다른 분기 정책이 필요한 경우. 새 정책을 적용하여 새 분기를 만들면 프로젝트의 전략적 가치를 높일 수 있습니다.

• 기능이 고객에게 릴리스되며, 팀에서 계획된 릴리스 주기에 영향을 주지 않는 변경 작업을 수행하려는 경우

사용자 스토리의 경우 통합에 많은 비용이 소모되므로 각 사용자 스토리에 대해 분기를 만들면 안 됩니다. Team Foundation Server 2010에서는 분기를 쉽게 만들 수 있지만 분기가 많을 경우에는 분기를 관리하기 위한 비용이 많이 들 수 있습니다.

버전 제어와 관련하여 팀에서 릴리스를 관리하는 방법

팀에서는 스프린트가 종료될 때 코드를 릴리스할 수 있어야 합니다. Team Foundation Server를 사용하면 분기에 레이블을 지정하여 특정 시점의 코드 스냅숏을 만들 수 있습니다. 다음 그림과 같이 릴리스용으로 MAIN 분기에 레이블을 지정할 수 있습니다. 이렇게 하면 분기를 특정 시점의 상태로 되돌릴 수 있습니다.

릴리스에 대한 업데이트를 구현해야 하므로 릴리스에 대한 분기를 만들면 팀에서 이후 릴리스와의 충돌 문제 없이 다음 스프린트에 대해 개별적으로 작업을 계속할 수 있습니다. 다음 그림에서는 업데이트를 위한 코드를 포함하고, 두 번째 스프린트의 끝에서 릴리스가 수행된 후 역방향으로 MAIN 분기에 통합되는 분기를 보여 줍니다.

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