분기 소스 코드 및 응용 프로그램 수명주기 모범 사례

10

우리는 작은 ISV 상점이며 일반적으로 매달 새로운 버전의 제품을 배송합니다. 우리는 Subversion을 코드 저장소로, Visual Studio 2010을 IDE로 사용합니다. 많은 사람들이 Mercurial 및 기타 분산 소스 제어 시스템을 옹호하고 있음을 알고 있지만 현재로서는 이러한 이점을 어떻게 활용할 수 있는지 알지 못하지만 잘못되었을 수 있습니다.

우리의 주요 문제는 가지와 기본 트렁크를 동기화하는 방법입니다.

오늘 우리가하는 일은 다음과 같습니다.

새 버전 출시 (Subversion에서 자동으로 태그 생성)
다음 달에 출시 될 메인 트렁크에 대한 작업을 계속하십시오

그리고주기는 매달 반복되며 완벽하게 작동합니다. 긴급 서비스 릴리스를 해제해야 할 때 문제가 발생합니다. 우리는 주 개발 트렁크 (2)가 심하게 개발되어 긴급하게 풀릴만큼 안정적이지 않기 때문에 주 트렁크에서 분리 할 수 없습니다.

이 경우 다음을 수행합니다.

1 단계에서 만든 태그에서 분기를 만듭니다.
버그 수정
테스트 및 출시
변경 사항을 기본 트렁크로 다시 푸시하십시오 (해당되는 경우).

우리의 가장 큰 문제는이 두 가지 (메인과 브랜치)를 병합하는 것입니다. 대부분의 경우 다음과 같은 이유로 자동 병합에 의존 할 수 없습니다.

주요 트렁크에 많은 변화가있었습니다
복잡한 파일 (Visual Studio XML 파일 등)을 병합하면 제대로 작동하지 않습니다.
다른 개발자 / 팀이 이해하지 못하는 변경을가했으며 병합 할 수는 없습니다.

따라서 두 가지 버전 (분기 및 기본)을 동기화하는 것이 가장 좋습니다. 너 뭐하니?

.net visual-studio-2010 svn

— 토니 프랭 콜라
소스

1

tfsbranchingguideiii.codeplex.com을 확인하십시오 (질문을 직접 다루지 않으므로 답변으로 게시하지는 않지만 TFS 지점을 개선하려는 사람들에게 항상 추천합니다). 아마도 지점 계획 중 하나에서 설정을 개선하는 방법에 대한 아이디어를 얻을 수 있습니다.

— nlawalker

2

분기 및 병합에 대한 귀하의 접근 방식은 괜찮다고 생각하지만 주요 문제가 코드베이스가 매우 불안정하다는 것이라면 집중하고 최소화해야합니다.

가장 중요한 것은 코드베이스 에 대한 우려 가 잘 분리되어 있다는 것 입니다. 다양한 구성 요소 간의 종속성을 격리하고 줄여야합니다. 이것은 대부분의 문제를 해결해야합니다. 또한 단일 책임 원칙과 같은 관행이 도움이 될 것입니다.

주요 아키텍처 변경이 필요한 경우 자체 지사에서 발생한 다음 완전히 테스트되고 '안정된'(이유 내에서) 한 번 메인으로 다시 병합됩니다. 이것은 고통스럽고 도전적이지만 드 물어야합니다. 적절한 테스트 관행이 있다면 위험이 최소화됩니다.

또한 분산 버전 제어 시스템으로 변경하는 데 도움이 될 수 있습니다. 이렇게하면 준비가되면 다른 지점에서 다른 기능이 병합 된 안정적인 트렁크가 제공됩니다. 코드가 너무 상호 의존적이라면 여전히 병합 병합이 가능하지만 더 많은 제어권을 가지게됩니다.

이를 다른 관점에서 살펴보면 팀 간의 의사 소통이 증가하는 것도 고려하십시오. 정기적으로 민첩한 스탠드 업 회의를 운영하십시오. 팀원의 위치와 그것이 도움이 될 수있는 방법을 고려하십시오. 복잡한 합병이 발생해야한다면 그렇게 나쁘지 않을 수도 있습니다. 쌍 당사자에게 이해를 제공하는 쌍 프로그래밍 방식을 사용하십시오.

— 알렉스 앙 가스
소스

2

나는 거의 반대 방향에서 그것을 보는 경향이 있습니다.

트렁크는 항상 프로덕션 용 코드 여야합니다 (첫 번째 최초 릴리스 이후).
월간 개발이 발생하는 트렁크와 병렬로 실행되는 개발 유형 분기가 있어야합니다. 릴리스 시간이되면 매달 트렁크로 병합되고 테스트 된 다음 릴리스됩니다.
그러면 핫픽스를 트렁크에서 쉽게 만들고 체크인 할 수 있으며 항상 성공적으로 배포 할 수 있습니다. 그런 다음 핫픽스에서 패치를 작성하여 개발 브랜치에 적용하십시오.

물론이 워크 플로는 SVN이 아닌 대상에 훨씬 더 적합합니다. 좋은 분기 및 병합은 워크 플로에 관계없이 SVN에서 상당히 고통스러운 작업이기 때문입니다. 내 경험상 SVN에서의 병합은 거의 항상 수동으로 수행해야합니다. 왜냐하면 작동하지 않으며 실제 방법이 없기 때문입니다.

— 일곱 바다 고양이
소스

1

최근에는 마지막 결과로 "분기 및 병합"이라는 철학을지지 해 왔습니다. 브랜치에서 코드 병합을 처리하는 것은 기술적 인 문제가 아니라는 것이 불행한 사실이라고 생각하지만,인지 적으로 어려운 작업입니다. 인간의 두뇌가 쉽게 세부 사항을 추적하지 않아 쉽게 이해할 수 없다고 생각합니다. 또한, 브랜치 및 병합이 실제로 실제로 작동하는 것을 아직 보지 못했습니다. 코드가 분기되면 경험에 따르면 코드를 다시 병합하는 데 어려움이 없다는 것입니다.

— 스미스 코
소스

2

어떤 VCS를 사용해 보셨습니까? 병합의 용이성은 사용중인 VCS에 크게 좌우 됩니다.

— 대안

많은 최신 VCS가 실제로 병합을 잘 처리합니다. 때로는 갈등이 여전히 발생하지만, 실제 갈등 인 경향이 있지만, SVN이 가짜로 많은 시간을보고 한 것은 아닙니다.

— sevenseacat

여러 SCM 시스템을 시도했습니다. 대부분의 병합 도구는 다양한 양의 성공으로 두 개의 텍스트 조각을 함께 넣을 수 있습니다. 그러나 올바른 결과를 얻었는지 병합 도구로는 알 수 없습니다. 일부 프로그래머가 병합 도구를 신뢰하기로 결정했기 때문에 너무 많은 버그가 사라지는 것을 보았습니다.

— smithco

1

병합 도구는 두 개의 텍스트 조각을 함께 깎아서는 안됩니다. 부모 커밋의 변경 사항을 병합해야합니다. 큰 차이.

— 대안

병합 도구는 코드를 이해하지 못합니다. 그들이 할 수있는 것은 두 개의 서로 다른 텍스트 조각을 가져 와서 현명하게 화해하려고 노력하는 것입니다. 병합이 잘못되어 빌드 실패와 버그가 발생하는 것을 몇 번이나 강조 할 수는 없습니다. 모든 병합은 위험한 것으로 간주되고 사람이 결과를 검토하고 병합 된 변경 사항을 커밋하기 전에 수많은 테스트를 통과해야합니다. 복잡한 과정이므로 드물게 수행해야합니다.

— smithco

1

훈련 된 주요 출시 접근 방식이 효과적입니다.

SVN 분기는 유연하게 설계되지 않았습니다. 첫 번째 문제는 SVN에 있습니다. 그로부터 이동하면 새로운 옵션이 열립니다.

— 폴 나단
소스