효과적인 분기 전략 선택

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

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

• 그룹에는 몇 가지(또는 여러 개의) 서로 다른 기능 팀이 있으며, 각 팀은 합리적으로 불연속적인 기능 집합을 작업합니다. 그러나 각 팀은 다른 팀에서 빌드한 기능에 따라 달라집니다. 이러한 각 팀에서 수행된 작업에 의해 도입된 변경의 위험을 격리해야 하지만 결국에는 모든 노력을 하나의 제품으로 병합해야 합니다.

• 테스트 팀은 테스트할 안정적인 버전의 코드가 필요하지만 동시에 개발자는 때때로 제품을 불안정하게 만드는 새로운 기능을 계속 진행해야 합니다.

• 이 소프트웨어에는 이전 버전 2개와 현재 버전 1개가 진행 중입니다. 대부분의 개발 노력이 현재 버전에 투자되어 있더라도, 이전 버전은 서비스 팩의 간헐적인 릴리스, 중요한 수정 및 보안 패치 및 기타 변경 내용으로 계속 지원되어야 합니다.

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

리포지토리 범위가 지정된 Git 분기와 달리 TFVC 분기는 경로 범위가 지정되며 경량이 아닙니다. 코드 또는 릴리스 격리가 필요한 경우 높은 분기와 분기만 만들기 위한 막대를 설정합니다.

주 전용

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

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

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

개발 격리

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

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

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

기능 격리

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

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

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

릴리스 격리

릴리스 격리는 기본 하나 이상의 릴리스 분기를 도입합니다. 이 전략을 통해 동시 릴리스 관리, 여러 병렬 릴리스 및 코드베이스 스냅샷 릴리스 시 가능합니다.

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

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

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

서비스 및 릴리스 격리

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

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

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

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

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

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

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

Q&A

분기가 수명이 짧아야 하는 이유는 무엇인가요?

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

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

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

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

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

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

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

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

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

dev를 기본 분기로 병합할 때 변경 내용이 검색되지 않는 이유는 무엇인가요?

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

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

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

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

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

이 문서는 어떠한 Microsoft 제품에 포함된 어떠한 지적 자산에 대한 법적 권한도 귀하에게 제공하지 않습니다. 이 문서는 내부 참조용으로 복사 및 사용할 수 있습니다.