지점이나 트렁크에서 개발을 계속합니까? [닫은]

주기적으로 릴리스되는 소프트웨어 제품을 개발한다고 가정하십시오. 분기 및 병합과 관련된 모범 사례는 무엇입니까? 정기 릴리스 브랜치를 공개 (또는 고객이 누구든지)에게 분리 한 다음 트렁크에서 개발을 계속하거나 트렁크를 안정적인 버전으로 간주하고 정기적으로 릴리스로 태그를 지정하고 브랜치에서 실험 작업을 수행합니다. 사람들은 트렁크가 "금"으로 간주되거나 "모래 상자"로 간주된다고 어떻게 생각합니까?

큰 상용 응용 프로그램으로 두 가지 방법을 모두 시도했습니다.

어떤 방법이 더 좋은지에 대한 답은 정확한 상황에 따라 크게 다르지만, 지금까지의 전반적인 경험이 보여준 내용을 쓰겠습니다.

전반적으로 더 나은 방법 (내 경험상) : 트렁크는 항상 안정적이어야합니다.

이 방법의 지침과 장점은 다음과 같습니다.

• 각 작업 (또는 관련 작업 집합)을 자체 분기에 코딩하면 이러한 작업을 병합하고 릴리스를 수행 할 수있는 유연성이 있습니다.
• QA는 트렁크에 병합되기 전에 각 브랜치에서 수행해야합니다.
• 각 개별 지점에서 QA를 수행하면 버그의 원인을 정확히 알 수 있습니다.
• 이 솔루션은 여러 개발자로 확장 할 수 있습니다.
• 이 방법은 SVN에서 분기가 거의 즉각적인 작업이므로 작동합니다.
• 수행하는 각 릴리스에 태그를 지정하십시오.
• 한동안 릴리스하지 않을 기능을 개발하고 정확히 병합 할시기를 결정할 수 있습니다.
• 모든 작업에 대해 코드를 커밋 할 수 있습니다. 트렁크 외부에서만 작업하는 경우 코드가 커밋되지 않은 상태로 유지되므로 보호되지 않고 자동 기록이 유지되지 않을 수 있습니다.

트렁크에서 반대로하고 모든 개발을 시도하면 다음과 같은 문제가 발생합니다.

• 일일 빌드에 대한 지속적인 빌드 문제
• 개발자가 프로젝트의 다른 모든 사람들에게 문제를 범했을 때 생산성 손실
• 최종적으로 안정적인 버전을 확보해야하기 때문에 더 긴 릴리스주기
• 덜 안정적인 릴리스

브랜치를 안정적으로 유지하고 트렁크를 개발 샌드 박스로 사용하려는 경우 필요한 유연성을 갖지 못할 것입니다. 그 이유는 안정적인 릴리스에 넣을 항목을 트렁크에서 선택하고 선택할 수 없기 때문입니다. 트렁크에 이미 함께 혼합되어있을 것입니다.

특히 트렁크에서 모든 개발을 수행하려는 경우는 새 프로젝트를 시작할 때입니다. 상황에 따라 다른 경우도있을 수 있습니다.

그런데 분산 버전 제어 시스템은 훨씬 더 많은 유연성을 제공하므로 hg 또는 git으로 전환하는 것이 좋습니다.

나는 두 가지 기술을 모두 사용했으며 트렁크에서 개발하고 릴리스로 안정 지점을 분기하는 것이 가장 좋은 방법이라고 말합니다.

위의 사람들은 당신이 가질 것이라고 말하는 것을 반대합니다.

• 일일 빌드에 대한 지속적인 빌드 문제
• 개발자가 프로젝트의 다른 모든 사람들에게 문제를 범했을 때 생산성 손실

아마도 지속적인 통합 기술을 사용하지 않았을 것입니다.

하루에 여러 번 테스트 빌드를 수행하지 않는 경우 (예 : 1 시간마다 한 번씩) 이러한 문제에 직면하게되면 개발 속도가 빠르게 저하 될 수 있습니다.

주간에 여러 테스트 빌드를 수행하면 다른 사람이이를 사용할 수 있도록 주 코드베이스에 대한 업데이트가 빠르게 접 히고 누군가가 빌드를 중단 한 경우 집에 가기 전에 수정할 수 있도록 주간에 경고합니다.

지적했듯이 회귀 테스트를 실행하기위한 야간 빌드가 실패 할 때 깨진 빌드에 대해 알아내는 것은 어리석은 일이며 빠르게 속도를 늦출 것입니다.

지속적인 통합 에 관한 Martin Fowler의 논문을 읽으십시오 . 우리는 약 2,000 줄의 Posix sh에서 주요 프로젝트 (3,000kSLOC)를 위해 자체 시스템을 구축했습니다.

나는 "릴리스 지점"접근 방식을 취하는 경향이 있습니다. 트렁크는 휘발성입니다. 릴리스 시간이 다가 오면 릴리스 브랜치를 만들고 더 신중하게 다룰 것입니다. 이것이 끝나면 저장소의 상태에 레이블을 지정하고 태그를 지정하여 "공식"릴리스 버전을 알 수 있습니다.

나는 다른 방법이 있다는 것을 알고 있습니다. 이것은 내가 과거에했던 방식 일뿐입니다.

양자 모두.

트렁크는 대부분의 개발에 사용됩니다. 그러나 트렁크에 체크인 할 때 고장이 발생하지 않도록 최선의 노력을 기울일 것으로 예상됩니다. (자동 빌드 및 테스트 시스템에 의해 부분적으로 검증 됨)

릴리스는 자체 디렉토리에 유지 보수되며 버그 수정 만 수행되고 트렁크로 병합됩니다.

트렁크를 불안정하거나 작동하지 않는 상태로 두는 새로운 기능은 별도의 분기에서 수행 된 다음 완료시 트렁크에 병합됩니다.

여러 민첩한 팀을위한 버전 관리 에서 Henrik Kniberg가 설명한 접근 방식을 좋아하고 사용합니다 . Henrik은 여러 팀이있는 민첩한 환경에서 버전 제어를 처리하는 방법 (전통적인 환경의 단일 팀에서도 작동)을 설명 하는 데 큰 역할을 했으며,이를 조작 할 필요가 없으므로 "치트 시트"를 게시합니다. 아래에 자체 설명입니다.

난 그게 좋아 왜냐하면:

• 간단합니다. 그림에서 얻을 수 있습니다.
• 너무 많은 병합 및 충돌 문제없이 잘 작동하고 확장됩니다.
• "애자일 정신"으로 언제든지 "작동 소프트웨어"를 릴리스 할 수 있습니다.

그리고 명시 적으로 충분하지 않은 경우를 대비하여 : "작업 분기 (work branch)"에서 개발이 완료되고 트렁크는 DONE (릴리스 가능) 코드에 사용됩니다. 자세한 내용 은 여러 민첩한 팀의 버전 관리를 확인 하십시오.

트렁크를 안정적으로 유지하고 지점에서 모든 작업을 수행하는 개발 프로세스에 대한 좋은 참고 자료는 Divmod의 Ultimate Quality Development System 입니다. 빠른 요약 :

• 모든 작업에는 티켓이 연결되어 있어야합니다
• 해당 티켓에 대한 작업이 완료된 각 티켓에 대해 새 지점이 작성됩니다.
• 해당 지점의 변경 사항은 다른 프로젝트 멤버가 검토하지 않고 기본 트렁크로 다시 병합되지 않습니다.

그들은 이것을 위해 SVN을 사용하지만 이것은 모든 분산 버전 제어 시스템으로 쉽게 수행 할 수 있습니다.

두 번째 접근 방식 (예 : 릴리스 태그 지정 및 분기에서 실험적인 작업 수행, 트렁크 안정성 고려)이 가장 좋은 접근 방식이라고 생각합니다.

브랜치는 브랜치 시점에 시스템의 모든 버그를 상속 받는다는 점을 분명히해야합니다. 수정 프로그램이 트렁크에 적용되는 경우 브랜치를 일종의 릴리즈 사이클 터미네이터. 이미 20 개의 릴리스가 있고 첫 번째 릴리스까지 거슬러 올라간 버그를 발견 한 경우 수정 사항을 20 번 다시 적용해야합니다.

트렁크도이 역할을 수행해야하지만 분기는 실제 샌드 박스로 간주됩니다. 태그는 해당 시점에서 코드가 "골드"인지 여부를 나타내며 릴리스에 적합합니다.

변경 사항이 너무 크거나 불안정하거나 제품 중 하나의 주요 릴리스에 가까워지지 않는 한 트렁크에서 개발합니다.이 경우 임시 지점을 만듭니다. 또한 모든 개별 제품 릴리스에 대한 영구 지점을 만듭니다. Branching Guidance 에 대한 Microsoft의 문서가 매우 유용 하다는 것을 알았습니다 . 분기에 대한 Eric Sink의 튜토리얼 도 흥미롭고 Microsoft에 적용되는 것이 우리 중 일부에게는 너무 무거울 수 있다고 지적합니다. 우리의 경우에는 실제로 Eric이 그의 팀이 말하는 방식을 사용합니다.

상황에 따라 다릅니다. Perforce를 사용하며 일반적으로 몇 가지 개발 라인이 있습니다. 트렁크는 "골드"로 간주되며 모든 개발은 통합하기에 안정적 일 때 메인 라인으로 다시 병합되는 브랜치에서 발생합니다. 이를 통해 자르지 않는 기능을 거부 할 수 있으며 시간이 지남에 따라 독립적 인 프로젝트 / 기능이 선택할 수있는 확실한 증분 기능을 제공 할 수 있습니다.

병합에 통합 비용이 있으며 트렁크에 롤링 된 새로운 기능을 따라 잡는 데는 어려움이 있습니다. 모든 사람이 트렁크에서 함께 개발하게되면 서부 상황이 발생할 수 있으며, 분기를 통해 쓴 통합 약을 복용 할 지점을 확장하고 선택할 수 있습니다. 현재 동일한 핵심 구성 요소를 사용하는 여러 릴리스가있는 수십 개의 프로젝트에서 100 명 이상의 개발자로 확장되고 있으며 꽤 잘 작동합니다.

이것의 장점은이 작업을 재귀 적으로 수행 할 수 있다는 것입니다. 큰 기능 분기는 다른 분기가있는 자체 트렁크 일 수 있습니다. 또한 최종 릴리스는 새로운 지점을 확보하여 안정적인 유지 보수를 수행 할 수있는 장소를 제공합니다.

새로운 개발에 따라 현재 생산 코드의 유지 관리를 시도하는 것은 최선의 문제입니다. 이러한 문제를 완화하기 위해 테스트 노력이 완료되고 코드를 제공 할 준비가되면 코드가 유지 보수 라인으로 분기되어야합니다. 또한 릴리스 안정화를 지원하거나 실험 개발 노력을 포함 시키거나 수명주기가 여러 릴리스로 확장되는 개발 노력을 수용하기 위해 메인 라인을 분기해야합니다.

비 유지 보수 브랜치는 코드간에 충돌 가능성이 있거나 다른 방법으로는 관리하기 어려운 경우에만 작성해야합니다. 지점이 물류 문제를 해결하지 못하면 문제가 발생합니다.

일반 릴리스 개발은 메인 라인에서 발생합니다. 개발자는 일반 릴리스 작업을 위해 메인 라인을 체크인 및 체크 아웃합니다. 현재 프로덕션 코드에 대한 패치의 개발 작업은 해당 릴리스의 분기에 있어야하며 패치가 테스트를 통과하고 배포되면 기본과 병합됩니다. 비 유지 보수 지점의 작업은 사례별로 조정해야합니다.

개발 노력의 규모에 따라 다릅니다. 여러 팀이 동시에 작업하면 동일한 코드 (트렁크)에서 모두 효과적으로 작업 할 수 없습니다. 소수의 사람들이 일하고 있고 주요 관심사가 지점을 절단하는 경우 현재 작업 코드에 버그 수정을하기 위해 지점으로 돌아가는 동안 계속 작업 할 수 있습니다. 이것은 분기의 사소한 사용이며 너무 부담스럽지 않습니다.

병렬 개발이 많은 경우 각 노력에 대해 지점을 만들고 싶지만 더 많은 규율이 필요합니다. 지점을 테스트하고 병합 할 준비가되었는지 확인하십시오. 두 그룹이 동시에 병합하지 않도록 병합 예약

일부 브랜치가 너무 오래 개발되어 트렁크로 다시 병합 할 때 놀라움의 횟수를 줄이기 위해 트렁크에서 브랜치로의 병합을 허용해야합니다.

많은 개발자 그룹이 있고 실험 상황에 맞는 느낌을 얻으려면 실험해야합니다. 다음은 다소 유용 할 수있는 Microsoft의 페이지입니다. http://msdn.microsoft.com/en-us/library/aa730834(VS.80).aspx

우리는 주요 개발에 트렁크를 사용하고 릴리스 유지 보수 작업에 분기를 사용하고 있습니다. 잘 작동합니다. 그러나 브랜치는 버그 수정에만 사용되어야하며, 특히 데이터베이스 측면에서는 주요 변경 사항이 없어야합니다. 우리는 기본 트렁크에서 스키마 변경 만 발생할 수 있고 브랜치에서는 절대로 스키마 변경이 발생할 수 없다는 규칙을 가지고 있습니다.

릴리스주기, 큰 기능을 통해 작업하려는 경우 지점에 적갈색이됩니다. 그렇지 않으면 우리는 트렁크에서 일하고 우리가 구축하는 순간 모든 생산 릴리스마다 분기합니다.

이전 프로덕션 빌드는 당시 old_production_로 이동했으며 현재 prod 릴리스는 항상 프로덕션입니다. 우리의 모든 빌드 서버는 프로덕션에 대해 프로덕션 브랜치를 배포하는 방법을 알고 있으며 강제 트리거로 빌드를 시작합니다.

우리는 trunk = 현재 개발 스트림, branch = release (s) 접근 방식을 따릅니다. 고객에게 릴리스되면 트렁크를 분기하고 트렁크를 계속 앞으로 돌립니다. 지원할 릴리스 수를 결정해야합니다. 버그 수정시 더 많은 병합을 지원할수록 더 많이 지원할 수 있습니다. 우리는 고객을 트렁크 뒤에서 2 번 이상 릴리스하려고 노력합니다. (예 : Dev = 1.3, 지원되는 릴리스 1.2 및 1.1).

트렁크는 일반적으로 주요 개발 라인입니다.

릴리스가 분기되고 종종 주요 개발 라인과 통합 될 준비가되면 분기에서 실험 또는 주요 작업이 수행 된 후 트렁크로 다시 병합됩니다.

트렁크는 일반적으로 주요 개발 소스가되어야합니다. 그렇지 않으면 새로운 기능을 병합하는 데 많은 시간이 소요됩니다. 나는 그것이 다른 방식으로 수행되는 것을 보았으며 보통 많은 마지막 순간 통합 두통을 유발합니다.

릴리스에 레이블을 지정하여 적극적인 개발을 방해하지 않고 프로덕션 긴급 상황에 신속하게 대응할 수 있습니다.

나를 위해, 그것은 내가 사용하는 소프트웨어에 달려 있습니다.

CVS에서는 "트렁크"로 작업하고 태그 / 분기를 사용하지 않을 것입니다. 왜냐하면 그렇지 않으면 실제로 고통스럽기 때문입니다.

SVN에서는 트렁크에서 "최첨단"작업을 수행하지만 서버 푸시를 수행해야 할 때 적절하게 태그를 지정했습니다.

최근에 git으로 전환했습니다. 이제 나는 트렁크에서 일하지 않는다는 것을 알게되었습니다. 대신 이름이 "new-featurename"샌드 박스 분기를 사용하고 고정 된 "현재 프로덕션"분기로 병합합니다. 이제 그것에 대해 생각 했으므로 실제로 "current-production"으로 다시 병합하기 전에 "release-VERSIONNUMBER"분기를 만들어야하므로 이전의 안정적인 버전으로 돌아갈 수 있습니다 ...

조직 / 팀이 버전을 얼마나 잘 관리하고 어떤 SCM을 사용하는지에 따라 다릅니다.

• 다음 릴리스 (다음 릴리스)를 쉽게 계획 할 수 있다면 트렁크에서 개발하는 것이 좋습니다. 지점을 관리하는 데 더 많은 시간과 리소스가 필요합니다. 그러나 다음 계획을 쉽게 수립 할 수 없다면 (대규모 조직에서 항상 발생합니다) 아마도 지점 (수십 또는 수십)이 아닌 체리 따기 커밋 (수백 / 수천)을 끝내게 될 것입니다.
• Git 또는 Mercurial을 사용하면 분기 관리가 cvs 및 하위 버전보다 훨씬 쉽습니다. 안정적인 트렁크 / 토픽 브랜치 방법론을 사용합니다. 이것이 git.git 팀이 사용하는 것입니다. 읽기 : http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
• Subversion을 사용하여 먼저 트렁크에서 개발 방법론을 적용했습니다. 커밋을 체리해야 할 때마다 (내 회사는 계획에 능숙하지 않기 때문에) 출시 날짜가되었을 때 꽤 많은 작업이있었습니다. 이제 Subversion의 전문가이며 Subversion의 브랜치 관리에 대해 잘 알고 있으므로 안정적인 트렁크 / 주제 브랜치 방법론으로 나아가고 있습니다. 이전보다 훨씬 잘 작동합니다. 우리는 아마도 Subversion을 고수하지만 git.git 팀의 작동 방식을 시도하고 있습니다.

내가 선호하는 SVN 디자인은 다음과 같습니다.

• 뿌리
  • 개발
    • 가지
      • 특징 1
      • 특징 2
      • ...
    • 트렁크
  • 베타
    • 태그
    • 트렁크
  • 해제
    • 태그
    • 트렁크

자체 분기가 필요한 주요 기능을 제외하고 모든 작업은 개발 / 트렁크에서 수행됩니다. 작업을 개발 / 트렁크에 대해 테스트 한 후 테스트 된 문제를 베타 / 트렁크에 병합합니다. 필요한 경우 베타 서버에 대해 코드를 테스트합니다. 변경 사항을 배포 할 준비가되면 적절한 수정 버전을 릴리스 / 트렁크에 병합하고 배포하면됩니다.

베타 분기 또는 릴리스 분기에서 태그를 만들 수 있으므로 베타 및 릴리스에 대한 특정 릴리스를 추적 할 수 있습니다.

이 디자인은 많은 유연성을 허용합니다. 또한 일부 개정판이 베타 테스트를 통과하지 않은 경우 다른 개정판을 릴리스 / 트렁크에 병합하는 동시에 베타 / 트렁크에 개정판을 남겨 둘 수 있습니다.

우리가 사용하는 방법은 Perforce 접근법이며, 이는 Laura Wingerd의 위대한 책에서 자세히 논의되었습니다.

http://oreilly.com/catalog/9780596101855/index.html

이 책은 퍼포먼스 중심이지만 (Wingerd는 Perforce 제품 관리자 임)이 개념은 일부 또는 모든 VCS에 적용될 수 있습니다.

퍼 포스 접근 (및 플랫폼)은 우리에게 매우 도움이되었습니다. 많은 회사 (Google, Intuit 및 Microsoft Windows 자체)에서 사용됩니다.

이 책은 읽을 가치가 있습니다.

이것을 읽으십시오 : http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf

서브 버전 컨벤션 질문 IMHO에 대한 모든 답이 없습니다.

그것은 실제로 프로젝트와 그것을 사용하는 회사의 역학에 달려 있습니다. 매우 빠른 속도로 진행되는 환경에서 며칠마다 자주 릴리스가 발생할 수있는 경우 종교적으로 태그를 지정하고 분기하면 관리 할 수없는 저장소가 생깁니다. 이러한 환경에서 필요할 때 필요한 방식은 훨씬 더 유지 관리 가능한 환경을 만듭니다.

또한 내 경험상 순수한 관리 관점에서 볼 때 svn 방법론을 전환하는 것이 매우 쉽습니다.

내가 가장 잘 작동하는 것으로 알려진 두 가지 접근 방식은 필요할 때 필요한 지점과 지점별로하는 작업입니다. 물론 이것은 서로의 정반대입니다. 내가 말했듯이-프로젝트 역학에 관한 것입니다.

@Brian R. Bondy : 팀이 프로젝트에서 병렬로 처리되는 일정량의 ppl / 태스크에 도달하면 솔루션이 아닙니다.

QA 부서가 qa에 참여하면 진행중인 지점 당 하나의 설치를 제공하는 데 필요한 노력이 너무 많습니다. 지점 당 제공해야하는 SOA / 클라이언트 / 서버 / 웹 서비스 / 데이터베이스를 생각하십시오 .

이 솔루션은 통합 단계가 부족합니다.