필자는 도덕적 인 딜레마 (delealma)를 가지고 있는데, 우리 회사 내에서 우리는 전체 제품 그룹을 메인 지점에두고 프로젝트는 메인 (트렁크) 지점에서 분기 할 것입니다. 나는 배달 될 스프린트 (오래 8 주)가 지연되어 2 주 동안 전개 될 수는 없지만 개발은 다음 스프린트로 계속 진행되어야한다는 점에서 문제가있다.릴리스가 지연되고 개발이 계속되는 TFS 분기 전략.
문제는 스프린트 1에서 수정해야하는 버그가 있고 기존 분기에서 개발이 계속되면 버그 수정과 스프린트 2의 파트가 함께 혼합되어 스프린트 1을 해제하기가 매우 어렵다는 것입니다.
반면에 기존 분기에서 새 분기를 만들면 모든 작업과 버그가 느슨해집니다.
코드 브랜치가 하나의 팀 프로젝트를 공유 할 수있는 방법이 있습니까?
이 상황을 어떻게 처리하겠습니까? 제가 누락 된 것이 있습니까?
새로운 스프린트가 나올 때마다 새로운 팀 프로젝트로 분기하면 잘못 처리하는 것입니다. 한 제품의 모든 지사는 동일한 팀 프로젝트에 있어야합니다.
스프린트는 팀 프로젝트가 아닌 반복과 일치해야합니다. 그렇게하면 문제없이 스프린트에서 다른 스프린트로 자유롭게 작업 항목을 재 할당 할 수 있습니다.
버그가 중요한 경우 스프린트 1 분기에서 수정하고 스프린트 2에 병합하십시오. 그러면 스프린트 2 코드없이 해제 할 수 있습니다. 이것이 초기 스프린트 1 릴리스 또는 향후 릴리스의 일부인지 여부에 관계없이
버그가 중요하지 않은 경우 스프린트 2 지점에서 해결하고 스프린트 1을 버그로 릴리스 할 수 있습니다.
스프린트와 분기가 일대일로 정렬되어야하는 이유는 없습니다. 단 3 번의 스프린트 만 릴리스하면 3 번 스프린트 만 분기해도 쉽게 벗어날 수 있습니다. 만약 당신이 릴리즈 관리에 능숙하고, 어떤 스프린트 결과를 수정해야한다면 릴리스 이후 몇 주에 걸쳐 심지어 변경 세트가 출시되었는지를 정확히 알 수 있습니다.
지속적인 배포를 정말로 진지하게 생각하고 싶다면 트렁크 지점과 기능 지점을 가지고 있어야합니다. 기능이 완료되면 트렁크에만 병합됩니다. 스프린트마다 여러 개의 기능 지점이있을 수 있습니다. 또는 새로운 코드를 배포 할 수 있지만 사용자가 아무 것도 알아 차리지 못하게 해제 한 기능 토글을 살펴보십시오.