지속적인 통합을 원할 때 가장 좋은 분기 전략은 무엇입니까?
- 릴리스 분기 : 트렁크에서 개발하고 각 릴리스에 대해 분기를 유지합니다.
- 기능 분기 : 각 기능을 별도의 분기에서 개발하고 안정된 경우에만 병합합니다.
이 두 가지 전략을 함께 사용하는 것이 합리적입니까? 에서와 같이 각 릴리스에 대해 분기하지만 큰 기능에 대해서도 분기합니까? 이러한 전략 중 하나가 지속적인 통합과 더 잘 맞을까요? 불안정한 트렁크를 사용할 때 지속적인 통합을 사용하는 것이 합리적일까요?
답변
나는 일상 업무에서 지사에 크게 의존하기 때문에 주제가 정말 흥미로워 요.
- Mark Shuttleworth가 기존 CI를 넘어서면서 메인 브랜치를 깨끗하게 유지하는 모델을 제안한 것을 기억합니다. 여기 에 그것에 대해 게시했습니다 .
- Cruise Control에 익숙하기 때문에 여기에서 작업 분기 및 CI에 대한 블로그도 게시 했습니다 . Plastic SCM 으로 수행하는 방법을 설명하는 단계별 자습서 입니다.
- 마지막으로, CI에 대한 Duvall의 책에서 CI에 대한 일부 주제 (그리고 잠재적으로 분기에 대해 이야기 할 수 있음) 도 매우 흥미로 웠습니다 .
흥미로운 링크를 찾으시기 바랍니다.
답변
대답은 팀의 규모와 소스 제어의 품질, 복잡한 변경 세트를 올바르게 병합하는 능력에 따라 다릅니다. 예를 들어 CVS 또는 SVN과 같은 전체 분기 소스 제어에서는 병합이 어려울 수 있으며 첫 번째 모델을 사용하는 것이 더 나을 수 있지만 IBM ClearCase와 같은 더 복잡한 시스템을 사용하고 팀 규모가 더 큰 경우 두 번째 모델이 더 나을 수 있습니다. 모델 또는 둘의 조합.
저는 개인적으로 각 주요 기능이 개별 개발자가 수행 한 각 변경 사항에 대한 작업 하위 분기와 함께 별도의 분기에서 개발되는 기능 분기 모델을 분리합니다. 기능이 안정화되면 트렁크에 병합되어 합리적으로 안정적으로 유지되고 항상 모든 회귀 테스트를 통과합니다. 릴리스주기가 거의 끝 나가고 모든 기능 분기가 병합되면 안정성 버그 수정 및 필요한 백 포트만 수행하는 릴리스 시스템 분기를 안정화하고 분기하는 반면 트렁크는 다음 릴리스의 개발과 다시 사용하는 데 사용됩니다. 새로운 기능 분기를 위해 분기합니다. 등등.
이러한 방식으로 트렁크에는 항상 최신 코드가 포함되지만,이를 합리적으로 안정적으로 유지하여 주요 변경 및 기능 병합에 대해 안정적인 레이블 (태그)을 생성 할 수 있습니다. 기능 분기는 지속적인 통합을 통해 빠르게 진행되는 개발이며 개별 작업 하위 분기가 자주 발생할 수 있습니다. 기능 브랜치에서 새로 고침을 통해 모든 사람이 동일한 기능에 대해 동기화 상태를 유지하면서 동시에 다른 기능을 작업하는 다른 팀에 영향을주지 않습니다.
동시에 역사를 통틀어 일련의 릴리스 브랜치가 있으며, 여기서는 어떤 이유로 든 제품의 이전 버전 또는 최신 릴리스 버전을 유지하는 고객에게 백 포트, 지원 및 버그 수정을 제공 할 수 있습니다. 트렁크와 마찬가지로 릴리스 분기에서 지속적인 통합을 설정하지 않고 모든 회귀 테스트 및 기타 릴리스 품질 관리를 통과 할 때 신중하게 통합됩니다.
어떤 이유로 두 기능이 상호 의존적이며 서로 변경해야하는 경우 동일한 기능 브랜치에서 둘 다 개발하거나 기능이 코드의 안정적인 부분을 트렁크에 정기적으로 병합 한 다음 변경 사항을 새로 고치는 것을 고려할 수 있습니다. 트렁크 분기간에 코드를 교환하기위한 트렁크. 또는 이러한 두 기능을 다른 기능과 분리해야하는 경우 해당 기능 분기를 분기하고 기능간에 코드를 교환하는 데 사용할 수있는 공통 분기를 만들 수 있습니다.
위의 모델은 50 명 미만의 개발자와 부족한 분기 및 CVS 또는 SVN과 같은 적절한 병합 기능이없는 소스 제어 시스템에서는별로 의미가 없습니다. 이로 인해 전체 모델을 설정, 관리 및 통합하는 데 악몽이 될 것입니다.
답변
저는 개인적으로 안정적인 트렁크를 갖고 기능 분기를 수행하는 것이 훨씬 더 깔끔하다는 것을 알았습니다. 이렇게하면 테스터 등이 단일 “버전”을 유지하고 트렁크에서 업데이트하여 코드가 완성 된 모든 기능을 테스트 할 수 있습니다.
또한 여러 개발자가 서로 다른 기능에 대해 작업하는 경우 모두 고유 한 분기를 갖고 완료되면 트렁크에 병합하고 테스터가 여러 가지 기능을 테스트하기 위해 여러 분기로 전환 할 필요없이 테스트 할 기능을 보낼 수 있습니다.
추가 보너스로 자동으로 제공되는 통합 테스트 수준이 있습니다.
답변
각 개발자가 매일 트렁크 / 메인 라인에 투입하는 핵심 원칙 중 하나를 기억한다면 두 전략 모두 지속적인 개발과 함께 사용할 수 있다고 생각합니다.
http://martinfowler.com/articles/continuousIntegration.html#EveryoneCommitsToTheMainlineEveryDay
편집하다
나는 CI에 대한 이 책 을 읽고 있었고 저자들은 릴리스별로 분기하는 것이 선호하는 분기 전략이라고 제안합니다. 동의해야합니다. CI를 사용할 때 기능별로 분기하는 것은 의미가 없습니다.
내가 왜 이런 식으로 생각하는지 설명하려고 노력할 것입니다. 세 명의 개발자가 각각 한 가지 기능을 사용하여 작업한다고 가정합니다. 각 기능은 완료하는 데 며칠 또는 몇 주가 걸립니다. 팀이 지속적으로 통합되도록하려면 최소한 하루에 한 번 메인 브랜치에 전념해야합니다. 이 작업을 시작하자마자 기능 브랜치를 만드는 이점을 잃게됩니다. 그들의 변경 사항은 더 이상 다른 모든 개발자의 변경 사항과 분리되지 않습니다. 그렇기 때문에 애초에 기능 브랜치를 생성해야하는 이유는 무엇입니까?
릴리스 별 분기를 사용하면 분기 간의 병합이 훨씬 적고 (항상 좋은 일입니다) 모든 변경 사항이 최대한 빨리 통합되고 (올바르게 수행 된 경우) 항상 릴리스 준비가 된 코드 기반을 보장합니다. 릴리스 별 분기의 단점은 변경 사항에 대해 훨씬 더주의해야한다는 것입니다. 예를 들어 대규모 리팩토링은 점진적으로 수행되어야하며 다음 릴리스에서 원하지 않는 새 기능을 이미 통합 한 경우에는 일종의 기능 전환 메커니즘을 사용하여 숨겨야합니다 .
다른 편집
이 주제에 대해 하나 이상의 의견이 있습니다. 다음은 CI로 분기되는 프로 기능인 블로그 게시물입니다.
http://jamesmckay.net/2011/07/why-does-martin-fowler-not-understand-feature-branches/
답변
릴리스 브랜치는 매우 유용하며 앱의 여러 버전을 유지해야하는 경우 절대적으로 필요합니다.
기능 브랜치는 매우 편리합니다. 특히 한 개발자가 큰 변경 작업을해야하고 다른 개발자는 여전히 새 버전을 출시해야하는 경우에 그렇습니다.
그래서 두 가지 메커니즘을 모두 사용하는 것은 매우 좋은 전략입니다.
Book of SVN 에서 흥미로운 링크 .
답변
저는 최근에 git 을 사용할 때이 모델 을 좋아하게되었습니다 . 질문에 “svn”태그가 지정되어 있어도 여전히 사용할 수 있습니다.
지속적 통합은이 모델의 “develop”브랜치 (또는 당신이 부르는 무엇이든)에서 어느 정도 일어날 수 있지만, 향후 릴리스를 위해 기능 브랜치를 오래 실행한다고해서 어딘가에서 코드에 발생하는 모든 변경을 고려할만큼 엄격하지 않을 것입니다. 당신이 정말로 그것을 원하는지에 대한 질문은 남아 있습니다. Martin Fowler는 그렇습니다.
답변
지속적인 통합은 분기 전략을 결정하는 요소가되어서는 안됩니다. 분기 접근 방식은 팀, 개발중인 시스템 및 사용 가능한 도구를 기반으로 선택해야합니다.
라고 한 …
- 설명하는 두 가지 접근 방식 모두에서 CI를 사용할 수없는 이유가 없습니다.
- 이러한 접근 방식은 조합하여 매우 잘 작동합니다.
- 두 가지 모두 다른 것보다 “더 잘”작동하지 않습니다.
- CI는 불안정한 트렁크로 총체적으로 이해됩니다.
이 모든 내용은 다음 페이지에서 다이어그램을 가져온 페이지의 네 번째 질문에서 답변되었습니다. http://blogs.collab.net/subversion/2007/11/branching-strat/
