병렬 개발/테스트 환경에서 릴리스 관리 -Deadlock

Question

교착 상태에 있습니다. 우리는 건강 관리와 관련된 제품 개발 회사입니다. 우리는 SVN 버전 제어 시스템을 사용하고 있습니다. 우리는 여러 고객을 보유하고 있으며 각각은 전용 개발 지점을 가지고 있습니다. 고객 지점은 항상 트렁크에서 분기됩니다. 우리는 프리미엄 고객 중 한 곳인 트렁크를 개발 지점으로 사용합니다. PC1이라고합시다.

지금 우리는 PDT_5.0이라는 이름의 제품 버전을 PC1에 출시했습니다. 릴리스는 PDT_5.0 릴리스 지점에서 발생했습니다. 원래 트렁크에서 분기되었습니다.

PDT_5.0 릴리스와 관련된 버그 수정이 이미 시작되었습니다. 고객이 한 달 내에 제공하겠다고 약속 한 일부 사소한 기능을 요청했습니다. 새로운 기능은 트렁크에서 개발되었습니다. 그러나 라이브로 이동하기 전에 새로운 기능을 품질 보증에 의해 테스트해야하며 고객 측의 승인을 받아야합니다.

이제 데드 록 : PDT_5.0이 이미 사용 중입니다. PDT_5.0 릴리스 지점에서 버그 수정이 진행 중입니다. 기능 개발이 완료되었습니다. 품질 보증 테스트를 거쳐야합니다. 그러나 우리는 QA가 테스트를 완료하고 나서 릴리스 할 때까지 기다릴 수 없습니다. 라이브에서 긴급한 버그 수정이 가능한 한 빨리 릴리스되어야하기 때문입니다. 나는 완전히 여기에서 길을 잃는다.

문제는 기능이 너무 작기 때문에 트렁크에서 분기를 원하지 않습니다.

Answer 1

설명 된 프로세스가 있어도 트렁크에서 필요한 기능과 수정 사항을 선택적으로 병합 (AKA 체리 피킹)하고 고객 지점으로 분기를 릴리스하는 것 외에 다른 방법은 없습니다.

앞으로 고객 별 기능 및 지점을 기반으로하는 비즈니스 모델이있는 경우 변경 사항을 제공하는 방법을 변경해야합니다.

첫 번째 옵션은 영업 담당자에게 공식 출시 전에 기능을 제공하겠다고 약속하지 않는 것입니다. 진지하게. "사람들, 우리가 아직 가지고 있지 않은 기능을 판매 해 주셔서 감사합니다. 그러나 추가 배포 약정을하지 마십시오."라고 말하십시오. 이렇게하면 릴리즈를 간단하게 유지할 수 있습니다 : trunk -> release branch -> customer branch. 그 후 dev 팀은 특정 변경 사항을 하나의 이전 분기에서 새로운 분기로 마이그레이션합니다.

그렇지 않으면 버그 수정을 통합 할 때까지 델타에서 막을 때까지이 새로운 현실에 맞게 프로세스를 조정해야합니다.

도움이 되었기를 바랍니다 ...