Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
TFVC(Team Foundation 버전 제어) 리포지토리에 대한 분기를 만드는 것은 위험을 격리하는 데 유용합니다. 5명 또는 10명 이상의 직원이 근무하는 소프트웨어 프로젝트에서 작업할 때 팀 구성원이 일반적으로 직면하는 몇 가지 문제를 고려합니다.
그룹에는 몇 가지(또는 여러 개의) 서로 다른 기능 팀이 있으며, 각 팀은 합리적으로 불연속적인 기능 집합을 작업합니다. 그러나 각 팀은 다른 팀에서 빌드한 기능에 따라 달라집니다. 이러한 각 팀에서 수행된 작업에 의해 도입된 변경의 위험을 격리해야 하지만 결국에는 모든 노력을 하나의 제품으로 병합해야 합니다.
테스트 팀은 테스트할 안정적인 버전의 코드가 필요하지만 동시에 개발자는 때때로 제품을 불안정하게 만드는 새로운 기능을 계속 진행해야 합니다.
이 소프트웨어에는 이전 버전 2개와 현재 버전 1개가 진행 중입니다. 대부분의 개발 노력이 현재 버전에 투자되어 있더라도, 이전 버전은 서비스 팩의 간헐적인 릴리스, 중요한 수정 및 보안 패치 및 기타 변경 내용으로 계속 지원되어야 합니다.
이 문서에서는 올바른 결정을 내리는 데 도움이 되는 몇 가지 일반적인 분기 전략을 살펴봅니다.
리포지토리 범위가 지정된 Git 분기와 달리 TFVC 분기는 경로 범위가 지정되며 경량이 아닙니다. 코드 또는 릴리스 격리를 위해 확실한 필요가 있을 때만 분기하도록 높은 기준을 설정하세요.
주 전용
Main Only 전략은 폴더 기반으로 할 수도 있고, 기본 폴더 를분기로 변환하여 추가 표시 기능을 사용할 수 있습니다. 메인 브랜치에 변경 사항을 커밋하고 선택적으로 레이블을 사용해 개발 및 릴리스 마일스톤을 표시할 수 있습니다.
위험: TFVC 레이블의 변경 가능성 및 기록 부족으로 변경 제어의 위험이 추가될 수 있습니다.
주요 단일 분기 전략으로 시작하고 에서 전략적으로 분기하여 필요에 따라 더 복잡한 전략으로 발전하기 위해 다른 전략을 채택합니다.
개발 격리
안정적인 메인 분기를 유지 관리하고 보호해야 하는 경우, 메인에서 하나 이상의 개발 분기를 생성할 수 있습니다. 격리 및 동시 개발을 가능하게 합니다. 작업은 기능, 조직, 임시 공동 작업 등 다양한 기준에 따라 개발 분기에서 격리될 수 있습니다.
기본 분기에 변경 내용이 있을 수 있습니다. 항상 FI(전방 통합) 기본을 개발 분기로 통합하고 병합 충돌을 해결합니다. 그런 다음 변경 사항을 메인로 다시 통합(RI)하세요. 분기 간에 동일한 품질 표시줄을 유지 관리합니다. 개발 환경에서 메인 과 동일한 방식으로 빌드 확인 테스트(BVT)를 빌드하고 실행합니다.
참고: 이 전략을 통해 팀은 개발 분기를 영구적으로 유지하여 결과적으로 큰 병합 티켓 이력을 쌓을 수 있습니다.
특성 격리
기능 격리는 개발 격리의 특별한 파생으로, 표시된 대로 주또는 개발 분기에서 하나 이상의 기능 분기를 분기할 수 있습니다.
특정 기능에서 작업해야 하는 경우 기능 분기를 만드는 것이 좋습니다.
기능 작업 및 관련 기능 분기의 수명을 짧게 유지합니다. 상위 브랜치에서 FI(앞으로 통합) 변경 사항을 자주 통합합니다. RI(역방향 통합)는 일부 합의된 팀 조건(예: 완료 정의)이 충족되는 경우에만 부모로 다시 연결됩니다. 주 기능 롤백은 비용이 많이 들 수 있으며 테스트를 다시 설정할 수 있습니다.
격리 해제
릴리스 격리는 메인에서 하나 이상의 릴리스 분기를 도입합니다. 이 전략을 통해 동시 릴리스 관리, 다중 및 병렬 릴리스 및 코드베이스 스냅샷을 릴리스 시간에 지정할 수 있습니다.
릴리스를 최종 확정할 준비가 되면 릴리스용 새 분기를 만들어야 합니다.
메인에서 절대 앞으로 통합(FI)하지 마십시오. 액세스 권한을 사용하여 릴리스 분기를 잠그고 릴리스의도하지 않은 수정을 방지합니다. 릴리스 분기에 대한 패치 및 핫 픽스는 역방향 통합(RI)을 통해 메인 분기로 되돌릴 수 있습니다.
참고: 분기 시나리오는 변경할 수 없으므로 릴리스 분기에서 응급 핫픽스가 수행되는 것을 알 수 있습니다. 복잡성 및 관련 비용을 놓치지 않고 요구 사항에 맞게 각 전략을 진화합니다.
서비스 및 릴리스 격리
서비스 및 릴리스 격리 전략은 유지 관리 분기를 도입합니다. 이 전략을 사용하면 릴리스 시 서비스 팩 및 코드베이스 스냅샷을 동시에 관리할 수 있습니다.
고객이 다음 주 릴리스 및 릴리스당 추가 서비스 팩으로 업그레이드하기 위한 서비스 모델이 필요한 경우 이 전략을 사용합니다.
릴리스 격리와 마찬가지로 릴리스를 잠글 준비가 되면 서비스 격리 및 릴리스 분기가 만들어집니다. 기본에서 서비스로 절대 앞으로 통합하지 마세요, 또는 서비스에서 릴리스로 통합하지 마세요. 수정이 이루어지지 않도록 릴리스 분기를 잠그십시오. 향후 서비스 변경은 서비스 분기에서 수행할 수 있습니다.
해당 수준의 격리가 필요한 경우 후속 릴리스에 대한 새 서비스 및 릴리스 분기를 만듭니다.
서비스, 핫픽스, 릴리스 분리
권장되지는 않지만, 추가 핫픽스 분기 및 관련 릴리스 시나리오를 도입하여 전략을 계속 발전시킬 수 있습니다.
이 시점에서 몇 가지 일반적인 TFVC 분기 시나리오를 살펴보는 데 성공했습니다. 이러한 기능을 개선하거나 기능 토글, 기능 설정/해제와 같은 다른 전략을 조사하여 런타임에 기능을 사용할 수 있는지 여부를 확인할 수 있습니다.
Q&A
분기가 수명이 짧아야 하는 이유는 무엇인가요?
브랜치를 짧게 유지하면 병합 충돌을 가능한 한 최소화할 수 있습니다.
필요한 경우에만 분기하는 이유는 무엇인가요?
DevOps수용하려면 빌드, 테스트 및 배포의 자동화에 의존해야 합니다. 변경은 계속일어나며, 자주 발생하는 병합 작업은 충돌이 잦아 수동 개입이 필요해 더 어렵습니다. 따라서 분기를 피하고 대신 이와 같은 기능 토글과 같은 다른 전략에 의존하는 것이 좋습니다.
가지를 제거하는 이유는 무엇인가요?
가능한 한 빨리 변경 내용을 다시 메인 에 가져와 장기적인 병합 결과를 완화하는 것이 목표입니다. 임시, 사용되지 않거나 불필요하게 많은 분기는 팀에 혼란과 부담을 초래합니다.
코드베이스를 프로젝트 간에 분기할 수 있나요?
예. 팀이 원본을 공유해야 하고 공통 프로세스를 공유할 수 없는 한 권장되지 않습니다.
코드 승격 전략은 어떻습니까?
코드 승격 전략은 폭포 개발 시대의 유물처럼 느껴집니다. 일반적으로 긴 테스트 주기와 별도의 개발 및 테스트 팀이 있습니다. 전략은 더 이상 권장되지 않습니다. 이 전략에 대한 자세한 내용은 분기 지침을 참조하세요.
개발 브랜치를 메인 브랜치에 합칠 때, 왜 변경 사항이 검출되지 않나요?
예를 들어 keep source 충돌 해결 옵션을 사용하여 이전 병합의 변경 내용을 무시했을 수 있습니다. 개발 분기를 기본으로 병합하는 을 참조하세요. 자세한 내용은 병합에서 변경사항이 없었습니다.
TFVC와 Git 분기 전략 간에 유사점이 있나요?
TFVC 기능 격리 분기 전략은 Git 의 토픽 분기와 유사합니다.
저자: 제시 후윙, 마커스 페르난데스, 마이크 푸리, 그리고 ALM의 윌리 쇼브 | DevOps 레인저스. 여기에서 연락할 수 있습니다.
(c) 2015 Microsoft Corporation. 모든 권리 보유. 이 문서는 "as-is"으로 제공됩니다. URL 및 기타 인터넷 웹 사이트 참조를 포함하여 이 문서에 표현된 정보 및 보기는 예고 없이 변경될 수 있습니다. 이 문서의 사용으로 발생하는 위험은 귀하의 책임입니다.
이 문서는 Microsoft 제품의 지적 재산권에 대한 법적 권리를 제공하지 않습니다. 이 문서는 내부 참조용으로 복사 및 사용할 수 있습니다.