릴리스에 적합한 분기 전략 선택

새 프로젝트에서 새 개발 팀으로 시작하여 소스 리포지토리 ( 예 : Microsoft Team Foundation Server 2010 )에 대한 분기 전략을 정의해야합니다 . 우리는 할 것인지 아닌지에 대해 끈끈한 토론을 시작했습니다 ...

. 프로덕션 빌드를 수행하는 하나의 릴리스 브랜치가 있고 실제로 릴리스 될 때 레이블을 지정하십시오.

또는

B . 프로덕션으로의 각 새 릴리스에 대한 새 릴리스 분기를 갖습니다 ( 예 : 버전 1, 2, 3 등 ).

옵션 A 는 매우 간단 해 보이지만 장기적으로 문제가 발생할지 확실하지 않습니다. 옵션 B 는 시간이 지남에 따라 쌓여있는 한 번 오래 지속되는 가지를 많이 만드는 것처럼 보입니다.

누구나 결정에 도움이 될만한 경험이 있습니까? 구체적으로, 나는 어떤 선택의 고통 지점이 있는지 듣고 싶습니다. TFS 및 / 또는 릴리스 관리 시사점과 관련하여 특정 경험을 제공하십시오.

옵션 A. 출시를 위해 메인 라인과 태깅 만 사용

장점 :

• 당신은 병합 지옥을 피하십시오.
• 메인 라인을 유지하면 적절한 릴리스 계획, 많은 WIP를 도입하지 않고 추상화로 분기를 사용하여 대역 외 장기 작업을 처리하고 개방형 시스템 및 작업 관리를 위해 구성 가능한 기능을 사용하는 모범 사례를 장려합니다. 진행 중일 수 있습니다. 그렇지 않을 수도 있습니다. 전체 롤백을 해제하거나 방지하려면 현재 또는 미래에 비활성화해야합니다.

단점 :

• 진행중인 작품을 다루는 것이 문제가되고 릴리스 시점이되면 잠재적 인 표면 공격 영역에 추가됩니다. 그러나 개발자가 훈련을 받으면 새로운 기능을 구성 및 모듈화 할 수 있으므로 쉽게 비활성화 / 활성화해야합니다. 또는 WIP가없고 각 릴리스 지점에서 모든 작업이 완료되었거나 아직 시작되지 않았습니다 (예 : Scrum).
• 대규모 / 대역 외 변경은 구현하기 전에 미리 더 많은 사고가 필요합니다 (예 : 추상화에 의한 분기).

개인적으로 저는이 방법을 선호합니다. 코드 적용 범위 및 단위 테스트는 출입 할 준비가되지 않은 코드를 식별해야하며 사람들은 현재 반복 중에 릴리스되지 않는 코드에 대해 작업하지 않아야합니다. 추상화 또는 다른 메커니즘에 의한 분기는 장기적인 변화를 처리하고 진행중인 작업에 사용될 수 있습니다.

이 작업을 수행하지 않으면 병합 문제, 오래된 코드, 출시되지 않은 기능 등을 다루는 자신을 찾기 시작합니다.

옵션 B. 릴리스 별 분기

장점 :

• 현재 반복이 승인 테스트 라운드를 마치는 동안 다음 반복에 대한 작업을 시작할 수 있습니다.
• 다른 것들도 확실합니다.

단점 :

• 가지 톤.
• 릴리스 지점에서 분기에 태그를 추가해야합니다.
• WIP를 처리하지 않고 이전 릴리스 분기에서 다음 릴리스 분기로 WIP를 병합해야하지만 릴리스 분기에서이를 비활성화하거나 비활성화하고 승인 테스트를 다시 실행해야하는 경우
• 더 많은 지점에 핫픽스를 적용해야합니다 (릴리스 지점 + 핫픽스 + 새 태그 + 핫픽스를 vnext 지점으로 병합하고 핫픽스가있는 위치에 따라 vnextnext로 가능).

나는이 해결책을 좋아하지 않는다 ^ _ ^.

일반적으로 메인 라인을 고수하는 것이 좋습니다. 개발자가 WIP를 작성하지 못하는 데 문제가있는 경우 (잘라 내지 못하거나 다음 릴리스에서 조기에 확인했을 때 쉽게 k 수있는 경우) 코드 완료 및 분기 지점에서 코드에 태그를 지정하는 것에 대해 이야기 할 수 있습니다. 개발자 단위 테스트에서 발견하지 못한 간과 된 결함 및 버그를 해결하기 위해 필요한 경우 여기에서

이상적으로는 규칙이 아니라 예외 프로세스가되기를 원한다고 생각합니다.

옵션 C. 크레이지 보너스 옵션

멋지게 만들고 싶다면 사용자 별 스토리 / 피처 별 분기 모델을 고려할 수도 있습니다. ( 자식이나 수은 같은 DVCS를 사용하는 경우 TFS 또는 비 DVCS의 끔찍한 아이디어 구현하는 매우 사소한하는 동시에 ).

과거에는 svn에서 수은으로 쉽게 포팅 할 수없는 레거시 코드베이스로 작업 한 이전 고용주 유지 관리 팀에 대해 아래를 구현했습니다. 릴리스를 더 잘 조정하는 것이 아니라 항상 릴리스 가능한 메인 라인의 비즈니스 요구 사항을 충족시키기 위해 많은 불필요한 작업이 필요했습니다. . .

1. 팀 개발 부서의 개발자가 기능을 개발했습니다.
2. 기능을 피어 검토 할 준비가되면 개발자 번들이이를 Dev 브랜치에서 CR 브랜치로 단일 병합으로 묶고 기능 ID / 사용자 스토리를 제목에 포함시킵니다. * 미리 커밋 후크로 적용 *
3. CR을 통과 한 후에는 관리 도구를 사용하여 기능을 QA 분기로 승격시킵니다. (저는 다양한 수용 단계에있는 사용자 스토리를 나열한 작은 터미널 응용 프로그램을 작성했으며 운영자가 이러한 수용 단계 사이에서이를 홍보하거나 강등 할 수있었습니다)
4. QA는 자동화 및 수동 유용성 테스트를 실행합니다. 기능이 양호하면 릴리스 분기 (기본)로 푸시됩니다. 이 기능이 거부되면 개발자가 테스트 중에 발생한 문제를 해결하고 CR 지점에 패치를 추가 할 수있을 때까지 QA 지점에서 강등 / 복귀됩니다.
5. 코드가 QA 지점에서 되돌려지고 수정 사항이 적용된 경우 터미널 도구는 기능을 CR 지점에서 QA 지점으로 다시 가져 오기 위해 필요한 변경 사항을 다시 적용하므로 QA는 코드를 다시 검토하고 승격 시키거나 다시 강등하십시오.
6. 어느 시점에서나 릴리스 브랜치는 안정적인 릴리스 가능 상태에 있어야합니다.
7. 출시 후 새로운 Dev, QA 및 CR이 메인 라인에서 분리되었습니다.

우리는 우리가 내놓는 각 릴리즈마다 별도의 지점을 가지고 있습니다 (1 년에 4 번). 특정 릴리스를 가져와야 할 때 매우 편리합니다.

몇 가지 이전 릴리스를 유지해야하는 경우 레이블링이 필요하지 않다고 생각합니다. 특정 릴리스 브랜치를 사용하면 다른 릴리스에 대해 걱정하지 않고 각 브랜치에 개별적으로 (또는 선택에) 핫픽스를 적용 할 수 있습니다.

또한 버그 나 기능이 도입 된 시점을 찾고있을 때 릴리스를 훨씬 쉽게 비교할 수 있습니다.

지점 수나 변경없이가는 시간에 대해 걱정하지 마십시오. 버전 관리 시스템은 프로젝트 개발 내역을 제어하고 제공하는 것입니다. 역사는 변하지 않는 경향이 있습니다 ... 그리고 이력서가 대처할 수없는 것에 대해 걱정하지 마십시오. 우리는 개발 브랜치에서 9000+ 파일 인 Perforce를 사용하고 있으며, 개발중인 릴리즈에 대해 최대 50 개의 개발 브랜치를 사용합니다. Perforce는 더 이상 심호흡을하지 않습니다.

한마디로 : 개발자 / 유지 보수 자 / 버그 수정 자 / 문제점 사냥꾼으로서의 삶을 더 편하게 만들고 분기 수 또는 파일 수에 대해 걱정하지 마십시오. 자존심이 강한 이력서에 대처할 수 있습니다.

편집하다:

우리는 우리가 가진 가지의 수와 관련하여 전혀 혼란을 겪지 않습니다. 릴리스 브랜치의 이름 지정 체계와 개발 (또는 작업) 브랜치의 1 이슈 1 브랜치 정책은 이와 관련이있을 수 있습니다.

릴리즈 브랜치에는 릴리즈 2011 서비스 팩 1 용 R2011SP1의 이름이 지정됩니다. 우리의 작업 브랜치에는 덜 지능적인 이름이 있습니다 : sub01, sub02, sub03 등. "sub"는 모든 작업 브랜치가 서브 브랜치라는 사실에서 비롯됩니다. 수락 지점의 승인 지점은 모든 이슈가 수집되고 릴리스 준비가 된 지점입니다.

1 이슈 1 워크 브랜치 정책과 이슈 추적 시스템이 "지점"필드로 커스터마이즈되었다는 사실과 결합하여 어떤 브랜치에서 어떤 이슈가 개발되었는지 항상 알 수 있습니다. 수락 분기에 이슈가 통합되면이 필드가 업데이트됩니다. 즉, 승인 테스트가 완료되면 릴리스 할 준비가 된 문제를 항상 알 수 있습니다. 마찬가지로 릴리스 브랜치를 생성 할 때이 필드를 업데이트하면이 릴리스를 통해 릴리스 된 이슈를 항상 추적 할 수 있습니다.

컨텍스트에 관한 모든 것 : 얼마나 자주 릴리스하고 릴리스에 포함되어 있습니까?

다음은 B 방법을 사용하여 이전 작업에서 얻은 약간의 사례 연구입니다 (우리는 목적으로 분기 라고 부릅니다 ).

이야기를 맥락에 담기 위해

• 릴리스는 새로운 게임 모드, 새로운 기능, 새로운 구성 옵션 등 소프트웨어의 새로운 기능으로 구성되었습니다.
• 릴리스주기는 상당히 길었습니다. 고객은 보통 1 년 동안 하나의 기능 세트 만 사용하는 대학이었습니다.

특정 릴리스의 기능이 완료된 상태에 도달 할 때까지 주요 개발이 트렁크로 이루어졌습니다. 이때 projectname-january2012 와 같은 브랜치를 만들고 해당 브랜치에서 품질 테스트 및 버그 수정을 수행합니다. 공개 릴리스 준비가되면 해당 분기의 코드에 태그를 지정하고 릴리스합니다.

그러나 릴리스 개발은 해당 태그에서 끝나지 않았습니다. 필연적으로 릴리스와 관련된 버그 나 작은 문제를 발견 한 클라이언트가있었습니다. 따라서이 경우에는 해당 분기로 돌아가서 코드를 패치하고 릴리스 할 january2012 분기 의 새 태그 버전을 작성 하고 수정 사항을 트렁크에 다시 병합하기 만하면 됩니다.

우리의 경우,이 접근 방식은 일부 사용자가 제한된 기능 세트로 이전 릴리스를 유지하는 것을 선호했거나 단순히 인프라 대신 핫픽스가 아닌 완전히 새로운 버전의 배포 비용으로 인해 일부 문제가 발생했기 때문에 유리했습니다.

따라서 스스로에게 물어봐야 할 질문은 다음과 같습니다.

• 얼마나 자주 해제합니까?
• 내 릴리스는 100 % 이전 버전과 호환됩니까?
• 버그를 수정하기 위해 클라이언트를 완전히 업그레이드해도 괜찮습니까?

자주 풀면 각각에 대해 가지를 가질 가치가 없습니다. 그러나 릴리스주기가 이전 사용 사례와 상당히 길고 배포, 이전 버전과의 호환성 및 이전 릴리스에 집착하는 클라이언트가 위험 할 수있는 경우 옵션 B 는 확실히 많은 고통을 덜어주고 지원하기가 훨씬 쉬워집니다. 지점 혼란을 처리하는 최소한의 비용으로 고객.

옵션 A를 선호합니다. 트렁크 및 브랜치 릴리스가 안정적 일 때 개발하십시오. 이로 인해 프로덕션 릴리스에 적용된 핫픽스를 통합하는 작업이 크게 제한됩니다.

옵션 B를 시도한 팀이 제자리를 다시 찾도록 돕기 위해 계약을 체결했습니다.

고려해야 할 몇 가지.

• 모든 활성 코드 분기를 통해 핫픽스를 앞으로 마이그레이션하십시오. 병합, 패치 및 / 또는 재개발을 통해 수행 할 수 있습니다. 수정 프로그램이 모든 해당 릴리스에 적용되고 트렁크에 적용되도록 완벽하게 관리해야합니다.
• 기본 코드 스트림과 별도로 기능을 개발할 수 있도록 기능 분기를 고려하십시오. 이것들은 실험적인 변화에 권장됩니다. 기능이 작동하지 않으면 기능 분기를 자유롭게 포기하십시오.
• 병합 지점에 태그를 지정하고 추적하십시오.
• 필요한 경우 릴리스를 분기하십시오. 릴리스가 릴리스 후보 빌드 준비가 된 경우 일반적으로 발생합니다. 경우에 따라 트렁크에 호환되지 않는 변경 사항이 있으면 강제로 분기 할 수 있습니다. 기능 분기를 고려하십시오.

나는 당신이 묘사하는 두 가지 체계 사이에서 무언가를 사용하는 시스템에서 몇 년 동안 일했습니다. 핵심은 사용중인 다단계 번호 체계가 있다는 것입니다. 외부 레벨은 기본적으로 API 버전이며 브랜치에서 관리되며 (여러 브랜치에서 무언가를 수정해야 할 경우 적절한 교차 병합으로) 내부 레벨은 태그로 관리되는 정확한 릴리스입니다.

특히, 고객이 가지고있는 정확한 버전을 알고 있다면 코드가 작성된 소스를 정확히 알고 있으며 정확한 복제본을 만들어 정확히 무슨 일이 일어나고 있는지 확인할 수 있습니다. 이것은 지원에 매우 중요합니다! 그러나 현재 출시하고있는 API 버전 인 외부 수준의 브랜치는 시간이 지남에 따라 발전합니다 (주요 개발 트렁크가 대부분의 새로운 기능을 사용함). 또한 API의 새로운 주요 릴리스를 수행 할 때이를 지원하기위한 새로운 분기를 수행하므로 (트렁크는 항상 하드 코어 개발 지향적 일 수 있음) 현재 가장 오래된 지원을 수명 종료해야하는지 여부를 고려합니다 분기.

따라서 저는 실제로 A 와 B 가 혼합 된 것을 추천합니다 . 둘 다 좋은 측면을 가지고 있지만 그 자체로는 완전하지 않습니다. 두 세계를 모두 활용하십시오.

과거에 TFS를 사용하여 옵션 (B)를 효과적으로 구현했습니다.

분기 / 병합은 작은 조각으로 수행 될 때 유용한 도구입니다. 어려움은 멍청한 지점을 만드는 데 있지 않고 (멍청한 일이지만) 일주일 분량의 작업을 트리로 백업하는 것 (보통 쉽다) ... 소스 컨트롤 뒤에 CI 시스템을 자동으로 작동시키는 데 있습니다. 당신.

시스템이 지점에 대한 테스트를 자동으로 구축하고 실행하지 않는 경우 분기가 불분명하기 때문입니다.

우리는 변경 세트의 상대 경로를 인식하기 위해 TFS의 기본 빌드 워크 플로우를 사용자 정의했으며, 일부 개발 루트에서 단순히 새로운 하위 폴더가 아닌 새로운 분기를 사용자 정의 할 수있는 규칙을 설정했습니다. 매끄럽고 분기하기 쉽고 분기를 죽일 수 있었고 컴파일 및 테스트를 위해 시스템에서 지속적인 피드백을 받았습니다.

많은 사람들이 이러한 전략이 TFS 하에서 얼마나 불가능한지를 선언하는 것을 보았으며, XAML 기반 빌드 엔진의 가능성에 대한 지식이 부족하기 때문이라고 생각합니다. TFS는 단순한 소스 제어가 아니라 전체 솔루션이므로 그대로 사용해야합니다.