효과적인 분기 전략 선택

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

TFVC(Team Foundation 버전 제어) 리포지토리에 대한 분기를 만드는 것은 위험을 격리하는 데 유용합니다. 5~10명 이상의 팀 멤버가 참여하는 소프트웨어 프로젝트에 대해 작업할 때는 다음과 같이 일반적으로 직면하는 몇 가지 문제를 고려해야 합니다.

• 그룹은 몇 개의 서로 다른 기능 팀으로 나뉘며 각 팀은 적절하게 분리된 일련의 기능을 처리합니다. 그러나 각 팀은 다른 팀에서 담당하는 기능에도 의존합니다. 이러한 각 팀에서 수행한 작업으로 인한 변경의 영향을 받지 않도록 팀 작업을 격리해야 하지만 최종적으로는 모든 작업 결과를 한 제품에 병합해야 합니다.

• 테스트 팀에서는 안정적인 버전의 코드를 테스트해야 하지만 동시에 개발자는 지속적으로 새 기능을 개발해야 하며 이러한 새 기능은 경우에 따라 제품의 안정성을 해치기도 합니다.

• 소프트웨어에는 두 개의 이전 버전과 진행 중인 한 개의 현재 버전이 있습니다. 대부분의 개발 작업은 현재 버전에 집중되지만 때때로 서비스 팩, 주요 수정 프로그램, 보안 패치 및 기타 변경 내용을 제공하여 이전 버전도 지원해야 합니다.

이 문서에서는 올바른 결정을 내리는 데 도움이 되는 몇 가지 일반적인 분기 전략을 살펴봅니다.

리포지토리 범위가 지정된 Git 분기와 달리 TFVC 분기는 경로 범위가 간단하지 않고 경로 범위가 지정됩니다. 코드 또는 릴리스 격리가 필요한 경우 분기를 높게 만들고 분기만 만들기 위한 막대를 설정합니다.

주 전용

기본 전용 전략은 추가 표시 기능을 사용하도록 설정하기 위해 폴더 기반 또는 분기로 변환된기본 폴더를 사용할 수 있습니다. 변경 내용을 주 분기에 커밋하고 필요에 따라 레이블이 있는 개발 및 릴리스 중요 시점을 나타냅니다.

위험: TFVC 레이블의 변경 가능성 및 기록 부족으로 변경 제어의 위험이 추가될 수 있습니다.

주요 유일한 분기 전략부터 시작하여 전략적으로 분기 하고 필요에 따라 더 복잡한 전략으로 발전하기 위한 다른 전략을 채택합니다.

개발 격리

안정적인 주 분기를 유지 관리하고 보호해야 하는 경우 주 분기에서 하나 이상의 개발 분기를 분기할 수 있습니다. 격리 및 동시 개발을 가능하게 합니다. 기능은 기능, 조직 또는 임시 공동 작업을 통해 개발 분기에서 격리될 수 있습니다.

주 분기에 변경 내용이 있을 수 있습니다. 항상 FI(통합)를 개발 분기에 전달 하고 병합 충돌을 해결합니다. 그런 다음 RI(역방향 통합)가 기본으로 다시 변경됩니다. 분기 간에 동일한 품질 표시줄을 유지 관리합니다. 기본에서 수행하는 것과 동일한 방식으로 개발 시 빌드 확인 테스트(BVT)를 빌드하고 실행합니다.

참고: 이 전략을 통해 팀은 개발 분기를 영원히 유지하여 잠재적으로 큰 병합 티켓 기록을 작성할 수 있습니다.

기능 격리

기능 격리는 개발 격리의 특별한 파생으로, 표시된 것처럼 주 분기 또는 개발 분기에서 하나 이상의 기능 분기를 분기할 수 있습니다.

특정 기능에서 작업해야 하는 경우 기능 분기를 만드는 것이 좋습니다.

기능 작업 수명 및 관련 기능 분기 수명을 짧게 유지합니다. 부모 분기에서 FI(전달 통합) 변경 내용을 자주 변경합니다. RI(역방향 통합)는 일부 합의된 팀 조건(예: 완료 정의)이 충족되는 경우에만 부모에 다시 통합됩니다. 주 기능 롤백은 비용이 많이 들 수 있으며 테스트를 다시 설정할 수 있습니다.

릴리스 격리

릴리스 격리는 주에서 하나 이상의 릴리스 분기를 도입합니다. 이 전략을 사용하면 릴리스 시 동시 릴리스 관리, 여러 병렬 릴리스 및 코드베이스 스냅샷을 허용합니다.

릴리스를 잠글 준비가 되면 릴리스에 대한 새 분기를 만들어야 합니다.

기본에서 FI(통합)를 전달하지 마세요. 릴리스에 대한 의도하지 않은 수정을 방지하기 위해 액세스 권한을 사용하여 릴리스 분기를 잠급니다. 릴리스 분기에 대한 패치 및 핫 픽스는 RI(역방향 통합)를 다시 주 분기로 되돌릴 수 있습니다.

참고: 분기 시나리오 중 어느 것도 변경할 수 없으므로 릴리스 분기에서 응급 핫픽스가 수행되는 것을 알 수 있습니다. 복잡성 및 관련 비용을 놓치지 않고 요구 사항에 맞게 각 전략을 개선합니다.

서비스 및 릴리스 격리

서비스 및 릴리스 격리 전략은 서비스 분기를 도입합니다 . 이 전략을 사용하면 릴리스 시 서비스 팩 및 코드베이스 스냅샷을 동시에 관리할 수 있습니다.

고객이 다음 주 릴리스 및 릴리스당 추가 서비스 팩으로 업그레이드하기 위한 서비스 모델이 필요한 경우 이 전략을 사용합니다.

릴리스 격리와 마찬가지로 릴리스를 잠글 준비가 되면 서비스 격리 및 릴리스 분기가 만들어집니다. 기본에서 서비스로 또는 서비스에서릴리스로 통합하지 마십시오. 수정을 방지하려면 릴리스 분기를 잠급니다. 향후 서비스 변경은 서비스 분기에서 수행할 수 있습니다.

해당 수준의 격리가 필요한 경우 후속 릴리스에 대한 새 서비스 및 릴리스 분기를 만듭니다.

서비스, 핫픽스, 릴리스 격리

권장되지는 않지만 추가 핫픽스 분기 및 관련 릴리스 시나리오를 도입하여 전략을 계속 발전할 수 있습니다.

이 시점에서 몇 가지 일반적인 TFVC 분기 시나리오를 살펴보는 데 성공했습니다. 기능을 개선하거나 기능 토글, 기능 설정/해제와 같은 다른 전략을 조사하여 런타임에 기능을 사용할 수 있는지 여부를 확인할 수 있습니다.

Q&A

분기는 왜 수명이 짧아야 하는가?

분기의 수명이 짧게 유지되면 병합 충돌이 가능한 한 적게 유지됩니다.

필요한 경우에만 분기하는 이유는 무엇인가요?

DevOps를 수용하려면 빌드, 테스트 및 배포 자동화에 의존해야 합니다. 병합 충돌 시 수동 개입이 필요한 경우가 많으므로 변경은 연속적이고 빈번하며 병합 작업이 더 어렵습니다. 따라서 분기를 피하고 기능 토글링과 같은 다른 전략에 의존하는 것이 좋습니다.

분기를 제거하는 이유는 무엇인가요?

장기적인 병합 결과를 완화하기 위해 가능한 한 빨리 변경 내용을 기본 으로 다시 가져오는 것이 목표입니다. 임시, 사용되지 않는, 풍부한 분기는 팀에 혼란과 오버헤드를 야기합니다.

프로젝트 간에 코드베이스를 분기할 수 있나요?

예. 팀이 원본을 공유해야 하고 공통 프로세스를 공유할 수 없는 경우 권장되지 않습니다.

코드 승격 전략은 어떻습니까?

코드 홍보 전략은 폭포 개발 시대의 유물처럼 느껴집니다. 일반적으로 긴 테스트 주기와 별도의 개발 및 테스트 팀이 있습니다. 이 전략은 더 이상 권장되지 않습니다. 이 전략에 대한 자세한 내용은 분기 지침을 참조하세요.

개발자를 주 분기에 병합할 때 변경 내용이 검색되지 않는 이유는 무엇인가요?

예를 들어 충돌 해결 옵션을 사용하여 이전 병합의 keep source 변경 내용을 무시했을 수 있습니다. 개발 분기를 main으로 병합하는 방법을 참조하세요. 자세한 내용은 병합할 변경 내용이 없습니다.

TFVC와 Git 분기 전략 간에 유사점이 있나요?

TFVC 기능 격리 분기 전략은 Git 토픽 분기와 유사합니다.

저자: ALM | 제시 후윙, 마커스 페르난데스, 마이크 푸리, 윌리 쇼브 DevOps 레인저스. 여기에서 연락할 수 있습니다.

(c) 2015 Microsoft Corporation. All rights reserved. 이 문서는 "있는 그대로" 제공됩니다. URL 및 기타 인터넷 웹 사이트 참조를 포함하여 이 문서에 표현된 정보 및 보기는 예고 없이 변경될 수 있습니다. 정보의 사용으로 발생하는 위험은 귀하의 책임입니다.

이 문서는 귀하에게 Microsoft 제품의 어떠한 지적 재산에 대한 법적 권리도 부여하지 않습니다. 귀하는 참조를 위해 내부적으로 이 문서를 복사하고 사용할 수 있습니다.