트렁크 기반 개발

한 줄 요약#

개발자가 '트렁크'*라는 단일 분기에서 코드에 대해 공동 작업하는 소스 제어 분기 모델은 문서화된 기술을 사용하여 다른 장기 개발 분기를 생성해야 한다는 압력에 저항합니다. 따라서 그들은 병합 지옥을 피하고 빌드를 깨지 않고 행복하게 산다.

* 2020년부터 Git 커뮤니티의 메인master ( 이전에는 불미스러운 의미 포함)

메인라인/메인/트렁크의 공유 분기는 모든 릴리스 주기에서 좋지 않습니다.#

소규모 팀을 위한 트렁크 기반 개발:#

확장 트렁크 기반 개발:#

정교화, 주장 및 주의 사항#

트렁크 기반 개발은 지속적인 통합 및 확장 된 지속적인 전달 의 핵심 인에이블러입니다 . 팀의 개인이 변경 사항을 하루에 여러 번 트렁크에 커밋하면 모든 팀 구성원이 적어도 24시간마다 트렁크에 커밋해야 하는 지속적인 통합의 핵심 요구 사항을 쉽게 충족할 수 있습니다. 이를 통해 코드베이스는 항상 온디맨드로 릴리스할 수 있으며 지속적인 전달을 실현하는 데 도움이 됩니다.

소규모 팀 트렁크 기반 개발과 확장된 트렁크 기반 개발 사이의 구분선은 팀 규모와 커밋 속도 고려 대상입니다. 개발 팀이 더 이상 "소규모"가 아니라 "확장"으로 전환한 정확한 순간은 실무자 토론의 대상입니다. 그럼에도 불구하고 팀은 다른 사람(또는 봇)이 볼 수 있도록 커밋/푸시하기 전에 개발 워크스테이션에서 전체 "사전 통합" 빌드(컴파일, 단위 테스트, 통합 테스트)를 수행합니다.

클레임#

• GitFlow 및 여러 장기 실행 분기를 특징으로 하는 기타 분기 모델 대신 트렁크 기반 개발을 수행해야 합니다.
• 이러한 기능 분기가 수명이 짧고 한 사람의 제품인 경우 트렁크 커밋/푸시(v 소규모 팀) 또는 풀 요청 워크플로에 직접 수행할 수 있습니다.

주의 사항#

• 팀 규모와 커밋 속도에 따라 코드 검토 및 빌드 확인(CI)에는 수명이 짧은 기능 분기가 사용되지만 커밋이 다른 개발자가 의존할 수 있도록 트렁크에 저장되기 전에 발생하는 아티팩트 생성 또는 게시에는 사용되지 않습니다. 에. 이러한 분기를 통해 개발자는 코드가 트렁크에 통합되기 전에 열심히 지속적으로 기여 코드 검토 에 참여할 수 있습니다 . 매우 작은 팀은 트렁크에 직접 커밋 할 수 있습니다 .

• 의도한 릴리스 주기에 따라 적시에 트렁크에서 잘라내어 릴리스 전에 '강화'되고(팀 활동 없이) 해당 분기가 언젠가 삭제되는 릴리스 분기가 있을 수 있습니다. 릴리스 후. 또는 팀이 Trunk 에서 릴리스 하고 버그 수정을 위해 "앞으로 수정" 전략을 선택하는 경우 릴리스 분기가 없을 수도 있습니다 . 트렁크에서 해제하는 것도 처리량이 많은 팀을 위한 것입니다.

• 팀은 변경 사항을 더 오래 달성하기 위해 추상화 기술을 통해 관련 분기에 익숙해져야 하며 일상적인 개발에서 기능 플래그를 사용하여 릴리스 순서를 헤지할 수 있도록 해야 합니다(및 기타 좋은 점 - 연속 릴리스의 동시 개발 참조 ) .

• 프로젝트에 2명 이상의 개발자가 있는 경우 빌드 서버를 연결하여 그들의 커밋이 트렁크에 도착한 후 그리고 병합할 준비가 되었을 때 빌드를 손상시키지 않았는지 확인 해야 합니다. 수명이 짧은 기능 분기에서 트렁크로 다시 돌아갑니다.

• 개발 팀은 처리량이나 품질에 영향을 주지 않고 자연스럽게 크기를 늘리거나 줄일 수 있습니다(트렁크에서). 증거? Google은 트렁크 기반 개발을 수행 하고 해당 단일 단일 리포지토리 트렁크에 35000명의 개발자와 QA 자동화를 보유하고 있으며 , 이들의 경우 문제의 개발자에 맞게 확장하거나 축소 할 수 있습니다.

• GitHub 흐름 분기 모델을 실행하는 사람들은 이것이 매우 유사하다고 느낄 것입니다. 그러나 릴리스 위치에는 작은 차이가 있습니다.

• Gitflow 분기 모델을 연습하는 사람들은 과거의 인기 있는 ClearCase, Subversion, Perforce, StarTeam, VCS 분기 모델에 익숙한 많은 개발자들이 그러하듯이 이것이 매우 다르다는 것을 알게 될 것입니다 .

• 여기에서 설명하는 것처럼 많은 간행물에서 트렁크 기반 개발을 홍보합니다. 여기에는 베스트 셀러인 'Continuous Delivery' 및 'DevOps 핸드북'이 포함됩니다. 이것은 더 이상 논쟁의 여지가 없어야 합니다!

역사#

트렁크 기반 개발은 새로운 분기 모델이 아닙니다. '트렁크'라는 단어는 성장하는 나무의 개념과 관련이 있으며, 여기서 가장 뚱뚱하고 가장 긴 범위는 트렁크에서 방사되고 더 제한된 길이의 가지가 아니라 트렁크입니다.

90년대 중반 이후로 덜 알려진 분기 모델이었으며 80년대 이후 전술적으로 고려되었습니다. Google(언급한 대로) 및 Facebook과 같은 가장 큰 개발 조직은 이를 대규모로 실행합니다.

소스 제어 기술 및 관련 도구/기술에 대한 30년 이상의 다양한 발전 으로 인해 Trunk-Based Development가 더 많이(때로는 덜) 보급되었지만 많은 사람들이 수년 동안 고수해 온 분기 모델이었습니다.

이 장소#

이 사이트는 트렁크 기반 개발에 대한 모든 관련 사실, 이론적 근거 및 기술을 한 곳에서 함께 수집하려고 시도하며, 이를 설명하는 데 도움이 되는 25개의 다이어그램을 완성합니다. TBD를 약어로 사용하지 않고 모두~한 번~두 배.

https://trunkbaseddevelopment.com/