저는 몇 년 동안 기능을 분기하고 많은 브랜치로 어려움을 겪고 악몽을 합병 한 후에 브랜치 전략에 대한 훌륭한 자료를 찾고있었습니다. Feature 브랜치는 어느 기능이 출시되어야하는지에 관해 꽤 세분화 된 방식으로 릴리스를 관리 할 수있는 좋은 격리를 제공했습니다. 그러나 그들이 제기 한 문제 (많은 지점, 병합)는 그들이 제공 한 이점보다 훨씬 길었습니다.트렁크 기반 개발 제안 필요
우리는 백엔드에서 Oracle 데이터베이스 (5000 개 오브젝트 포함)로 작업합니다. 또한 동일한 제품의 여러 영역에서 여러 팀이 작업하고 있습니다. 우리는 TFS (DVCS 없음)와 Visual Studio를 사용하고 있습니다.
우리가 만드는 지점이 많을수록 더 많은 데이터베이스 인스턴스가 문제의 또 다른 세트 인 해당 분기 (각 분기 - 하나의 db 인스턴스)에서 기능 테스트에서 올바르게 격리해야합니다.
우리는 스크럼을 채택하고 있으며 출시주기 (1 년에 4 회)와 CI 빌드에 적합한 분기 모델을 찾고 있습니다. 우리는 각 릴리스에 대해 5 회의 일반 스프린트와 1 회의 강화 스프린트를 수행 할 계획입니다.
개발 지점은 우리의 "트렁크"(트렁크을위한 기반 개발)로 작동하고 모든 개발자 - 모델 분기 기능에서
, 우리는 같은 아래 분기 매우 간단한 우리의 분기 모델을 재 (모든 팀)가이 지사 (분기 별 릴리스)에 커밋하고 테스터는이 지사에서 테스트를 진행하며 CI 서버 (Jenkins)는 매일이 지점을 구축하고 있습니다. 우리는 몇 가지 이유로 자주 사용되는 "최종 출시 진실의 단일 출처"로서 안전을 위해 언제든지 깨끗한 MAIN이 필요합니다.유지 관리 지점은 버그 수정 지점 (핫픽스)으로, 연중 무휴로 여러 번 릴리스됩니다 (분기 별 릴리스와 관계 없음). 우리는 "깨끗한"메인 브랜치를 갖고 싶어하는 것처럼 메인 브랜치에서 직접 작업하지 않는 것을 선호합니다. "수동"/ 기능 테스트를 수행하지 않고도 코드를 Main으로 보내지 않기를 바랍니다. 버그 수정 릴리즈가 완료되면 코드가 Maintenance -> Main -> Development에서 병합되어 버그 수정 사항을 Development에 통합합니다.
유지 관리 분기에서 계속 버그 수정을 수행하고 유지 관리에서 해제 한 다음 변경 사항을 주 (및 개발)에 병합 할 예정이므로 일반적으로 TBD에서 제안 된대로 "릴리스 지점"이 필요하지 않습니다. "Last release"만 유지하고 이전 릴리스 수정이 필요한 경우 Main의 Labels에서 이전 릴리스 분기를 만듭니다.
트렁크 기반 개발을 향후 문제가 될 정도로 수정 했습니까? 당신의 제안은 무엇입니까?
은 참조 :
http://paulhammant.com/2013/12/04/what_is_your_branching_model
http://paulhammant.com/2013/04/05/what-is-trunk-based-development/#comment-2765204723