전략적 분기

 

게시: 2016년 4월

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

Team Foundation에서는 유연하고 신뢰할 수 있는 버전 제어 시스템을 제공합니다. Team Foundation バージョン管理를 사용하면 소스 코드, 문서, 작업 항목 및 팀에서 사용되는 기타 중요 정보를 개발하는 동안 여러 번에 걸친 개정 작업을 관리할 수 있습니다. Visual Studio Team Foundation Server의 버전 제어에 대한 자세한 내용은 버전 제어 사용을 참조하세요.

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

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

코드 분기를 만들고 병합하는 방법에 대한 자세한 내용은 CodePlex 웹 사이트에서 Team Foundation Server 분기 설명서 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는 분기를 용이하게 하지만 많은 분기가 있을 경우 분기 관리 오버헤드가 상당히 커질 수 있습니다.

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

팀은 각 스프린트의 끝에서 코드를 릴리스할 수 있어야 합니다. Team Foundation Server를 사용하면 특정 시점에 코드의 스냅숏을 작성할 분기에 레이블을 지정할 수 있습니다. 다음 그림과 같이 릴리스에 대해 MAIN 분기에 레이블을 지정할 수 있습니다. 그러면 이 시점의 상태로 분기를 되돌릴 수 있습니다.

릴리스 업데이트를 구현해야 하기 때문에 릴리스 분기를 만들면 팀이 이후 릴리스와의 충돌을 만들지 않고 다음 스프린트에서 독립적으로 계속 작업하는 데 도움이 됩니다. 다음 그림에서는 업데이트 코드를 포함하며 두 번째 스프린트의 끝에서 릴리스된 후 MAIN 분기에 역방향 통합되는 분기를 보여 줍니다.

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