장기 프로젝트의 제품 버전 관리 및 분기를 처리하는 가장 좋은 방법은 무엇입니까?

일반적으로 제품 수명주기 동안 여러 릴리스가있을 수 있고 이전 제품의 지원이 필요한 장기 프로젝트의 경우 제품 버전 및 코드 기반 분기를 처리하는 가장 좋은 방법은 무엇입니까?

좀 더 구체적으로 말하면, 적절한 분산 버전 관리 (git)가 있고 팀 규모가 크거나 크며 개발자가 한 번에 여러 프로젝트를 수행하고 있다고 가정하십시오. 현재 직면하고있는 주요 문제는 당시에 존재하던 이전 버전을 지원해야하는 계약상의 의무가 있다는 것인데, 이는 새로운 개발로 기존 코드를 패치 할 수 없다는 것을 의미합니다 (Microsoft Office 제품은 이에 대한 예일 수 있습니다. 소유 한 기능 연도).

결과적으로 현재 제품 버전 관리는 각 주 제품에 여러 버전의 종속성이 있으며 각 버전마다 연례 릴리스간에 변경 될 수있는 고유 한 버전이 있습니다. 마찬가지로, 각 제품에는 자체 저장소가 있지만 대부분의 작업은 기본 소스 트렁크에서 수행되는 것이 아니라 제품이 릴리스 될 때 새 분기가 만들어지면서 지원 될 수 있도록 해당 분기의 제품 릴리스에서 수행됩니다. 이는 제품의 코드베이스를 얻는 것이 버전 관리를 사용할 때 생각할 수있는 단순한 문제가 아님을 의미합니다.

얼마나 많은 (그리고 어떤 종류의) 구조가 필요한지 당신이 할 수있는 것에 달려 있습니다. 없이는 살 수없는 것, 갖고 싶은 것, 원하지 않는 것을 파악하십시오.

의사 결정의 좋은 예는 다음과 같습니다.

우리가 없이는 살 수없는 것들 :

• 언제든지 과거 릴리스를 재구성 할 수 있습니다
• 여러 개의 지원되는 주요 버전의 제품을 언제든지 유지할 ​​수 있습니다

우리가 갖고 싶은 것들 :

• 지점 병합에 대해 걱정하지 않고 진행중인 주요 기능 개발 (다음 주요 릴리스 용)
• 이전 릴리스에 대한 유지 보수 업데이트를 수행 할 수 있음

우리가없이 살 수있는 것 :

• 현재 작업에서 이전 릴리스로의 변경 사항 자동 백 포트
• 며칠 또는 일주일 동안 주요 기능 개발을 중단하지 마십시오

위의 목표가 목표라면 다음과 같은 프로세스를 채택 할 수 있습니다.

1. VCS 트렁크에서 모든 개발 작업을 수행하십시오 (git의 "마스터")
2. 주 릴리스에 가까워지면 주 기능 개발을 중단하고 일주일 정도 시스템 안정성에 중점을 둡니다.
3. 트렁크가 안정적인 것처럼 보이면이 주요 릴리스에 대한 분기를 만듭니다.
4. 트렁크에서 주요 기능 개발을 진행할 수 있으며 지점에서는 버그 수정 및 릴리스 준비 만 허용됩니다.
5. 그러나 지점에 대한 모든 버그 수정은 먼저 트렁크에서 테스트해야합니다. 이를 통해 향후 모든 릴리스에도 발표 될 예정입니다.
6. 릴리스 할 준비가되면 지점에 (VCS) 태그를 작성하십시오. 이 태그는 동일한 브랜치에서 추가 작업을 수행 한 후에도 언제든지 릴리스를 다시 작성하는 데 사용할 수 있습니다
7. 이제이 주요 릴리스 (부 릴리스)에 대한 추가 유지 보수 릴리스를 지사에서 준비 할 수 있습니다. 각각은 출시 전에 태그됩니다
8. 한편, 다음 주요 릴리스에 맞춰진 주요 기능 개발은 트렁크에서 계속 될 수 있습니다.
9. 해당 릴리스에 가까워지면 위 단계를 반복하여 해당 릴리스에 대한 새 릴리스 분기를 작성 하십시오 . 이를 통해 각각 자체 지점에 여러 개의 주요 릴리스를 동시에 지원되는 상태로 제공 할 수 있으며 각각에 대해 별도의 부 릴리스를 릴리스 할 수 있습니다.

이 프로세스는 모든 질문에 답변하지는 않습니다. 특히 릴리스 브랜치에 대한 수정 사항을 결정하고 릴리스 브랜치에서 버그가 먼저 수정되지 않도록하는 프로세스가 필요합니다 (이러한 수정 사항). 가능한 경우 항상 트렁크에서 테스트해야합니다. 그러나 그러한 결정을 내릴 수있는 틀을 제공 할 것입니다.

"장기"는 버전 관리 가 필요하다는 지표 이지만 특정 버전 관리 및 분기 전략과 관련이 없습니다. 더 흥미로운 질문은 지원하고자하는 제품 라인 또는 주요 버전 라인의 수입니다 (고객과의 계약에 따라 다름). 유지 관리 계약이있는 모든 제품 라인 / 주요 버전 라인에 대해 최소한 하나의 지점이 필요합니다.

반면, 팀 규모에 따라 다릅니다. 대규모 개발 팀이 있고 다른 사람들이 서로 다른 기능을 동시에 작업하는 경우 한 두 사람으로 구성된 팀보다 더 많은 기능 분기가 필요합니다. 더 큰 팀과 함께 작업하는 경우 분산 버전 제어를 사용하여 다른 브랜치에서 병렬 작업을 수행하고 나중에 트렁크로 다시 통합하는 것이 훨씬 효율적입니다.

Git은 버전 관리 도구이며 파일 버전을 관리합니다. 당신이 따르는 것은 구성 관리 도구입니다. 이 가용 한 것들이 유쾌하지만 대부분 IBM과 같은 높은 $$$입니다.

버전 제어 도구는 분기 및 태깅을 제공하므로 추가 도구 지원없이 꼼꼼한 구성 관리가 가능하므로 개발자는 그 차이를 이해할 수 없습니다. GIT가 의도 한 것 이상으로 요구가 확장 될 수 있습니다.

나는 Git에 대한 CM 도구 추가를 알지 못하지만 그것이 존재할 것이라고 확신한다.

이 질문은 내가 최근에 대답 한 다른 질문 과 매우 유사한 것 같습니다 .

간단히 말해 이것은 버전 관리 / 분기 문제보다 제품 설계 및 배포 문제와 비슷합니다. 물론, 내가 이미 문제에 깊이 빠져 있다면 그 말을하기가 더 쉽고 고치기 어렵다.

특정 문제의 세부 사항을 자세히 알지 못하면 그러나 일반적으로 제품간에 많은 양의 공유 코드가있는 코드베이스를 기반으로 여러 버전의 제품을 사용하는 경우 가능한 경우 제품을보다 모듈 방식으로 만드는 리팩토링을 원합니다. 모듈 자체에 추가 코드 분기가 필요하지 않도록하십시오. 또한 많은 코드 기반을 통일하면서도 고객을 지원하는 더 좋은 방법이 있는지 확인하기 위해 배포 모델을 살펴볼 것입니다. 특정 고객 사용자 정의가 필요한 경우 시스템에서 중복 된 코드의 양을 줄이기 위해 더 세분화 된 모듈이 필요할 수 있습니다.

쉬운 작업은 아니지만 작업을 잘 관리하고 모든 작업을 한 번에 "업그레이드"할 필요가 없도록 작업을 예약 할 수 있으면 단계별로 해결할 수 있습니다.