브랜치 기반 버전에서는 구성 관리 프로세스의 전형을 완벽하게 보여주는 다음 다이어그램에 대해 이야기해야 합니다. 우선, 이 다이어그램은 Git 모델을 기반으로 작성되었지만, 사실 Git과 Subversion이 버전 관리 개념을 파악했으며, Git은 분기 관리와 분산 성능 면에서 Subversion보다 질적으로 도약했습니다(하지만 이 글의 초점은 아닙니다).
이 그래프의 원리를 소개하기 전에, 일반적인 버전 관리를 위한 두 가지 전략에 대해 이야기해 보겠습니다. 하나는 '개척자 백본, 안정 분기'이고, 다른 하나는 '안정 백본, 개척 분기'입니다. 이름에서 알 수 있듯이, 안정 버전(생산 버전)으로, 트렁크 또는 브랜치에 설치됩니다. VSS를 사용하는 전통적인 프로젝트 팀의 경우, VSS 자체에는 브랜치 관리 전략이 없기 때문에 어느 모드에 속하는지 말하기 어렵습니다. 많은 프로젝트 팀이 각각 프로덕션 환경과 개발 환경에 대응하는 두 개(또는 세 개)의 버전 라이브러리를 구축하기 때문입니다. 물론 이것도 일종의 브랜치 관리의 위장입니다. 하지만 버전 관리 도구로 Subversion이나 Git으로 전환하면 대부분의 팀은 안정 트렁크 모드를 사용합니다. 즉, 트렁크(트럭 또는 마스터)는 안정적인 운영 환경에 해당하며, 다양한 릴리스를 태그하여 생산 버전을 표시합니다. 개인적으로는 안정적인 백본 코드 패턴이 현재 절대적인 주류 코드 버전 관리 솔루션이어야 한다고 생각합니다. 위 사진은 표준 '안정 백본' 관리 모델입니다.
마스터: 대응하는 서브버전은 트럭입니다。 생산 버전에 따라 매 릴리스마다 한 번씩 태그가 붙습니다.
릴리스 브랜치(통합 브랜치라고도 함): 프로덕션이 업데이트되는 한, 먼저 릴리스 브랜치(통합 브랜치)로 병합해야 합니다. 이는 프로젝트 팀이 현재 '프리프로덕션'과 '시뮬레이션 환경' 개념이라고 부르는 것과 다소 유사합니다.
개발 지점 (개발 지점 또는 개발 지점): 개발 환경이 직면한 환경입니다.
특징 분기(특징 분기): 일부 독립 함수는 별도의 개발 분기와 분리될 수 있습니다. 이는 일부 기능이 업데이트에 상대적으로 오랜 시간이 걸릴 수 있다는 점을 해결하기 위함으로, 릴리스와 별도의 분기들이 지장을 끌지 않도록 하기 위함입니다.
핫픽스 브랜치(버그 픽스 브랜치): 여기서 버그는 주로 제작 문제입니다.
줄기와 가지를 소개한 후에, 이 가지들의 생성과 합쳐지는 방향도 소개해야 합니다.
마스터는 운영 버전이며, 트렁크는 두 개의 브랜치만 합병을 허용합니다. 하나는 릴리스 브랜치(통합 브랜치)이고 다른 하나는 핫픽스 브랜치입니다. 다른 분기는 생산 분기로 통합될 수 없습니다.
릴리스 브랜치는 프로덕션과 동시에 처음에 생성되며, 프로덕션과 정확히 동일합니다. 그는 오직 개발 분기와 합병하는 것만 받아들입니다. 즉, 그는 기능 브랜치나 버그픽스 브랜치에서 직접 병합하는 것을 받아들이지 않습니다.
개발 브랜치, 개발 브랜치는 통합 브랜치와 마찬가지로 특정 시점에서는 프로덕션 환경과 동일합니다. 하지만 개발이 진행됨에 따라 개발 브랜치에서 새로운 기능들이 계속 추가될 것입니다. 개발 이론은 두 개의 브랜치 병합만 허용하는데, 하나는 핫픽스이고 다른 하나는 기능 브랜치입니다.
기능 브랜치는 특정 시점(버전)부터 개발자 브랜치와 함께 시작되며, 결국 기능 브랜치가 개발 브랜치와 병합됩니다.
버전 관리 방법을 시나리오 형식으로 간단히 소개해 보겠습니다
예를 들어, 프로덕션 버전이 분기(개발, 핫픽스, 릴리스)로 나뉘고, 이때 개발팀은 총 열 개의 함수 개발을 시작합니다. 10개 기능 중 8개가 개발되자, 테스트 팀이 내부 테스트를 위해 개입하기 시작했고, 구성 관리자는 개발 브랜치를 개발 환경에 배포하여 지속적 통합 도구를 통해 테스트했습니다(별도의 주제입니다). 테스트 검증 결과 두 가지 기능(예를 들어 단순 보험 보험과 청구 신고)이 완전히 허용되지 않고 재작업이 필요하다고 판단되자, 개발에서 분리된 두 가지 기능 분기가 분리되었는데, 이는 단순 보험 보험과 청구 환불에 해당하며, 개발 분기에서는 해당 코드도 롤백해야 했습니다(수동 조작은 여기서). 테스트 팀이 개발 브랜치 테스트에 문제가 없음을 확인하면 UAT 조건을 충족하고, 구성 관리자는 개발 브랜치를 릴리스 브랜치에 병합한 후 지속적 통합 도구를 사용해 이 브랜치를 사전 운영 환경에 게시하고 사용자에게 테스트용으로 넘깁니다. 사용자 검증 과정에서 문제가 발견되면, 개발자는 개발 브랜치를 수정한 뒤 릴리스 브랜치로 병합합니다(여기 원본 사진에서는 릴리스 브랜치에서 직접 수정되어 있는데, 저는 이것이 좋지 않다고 생각하며 개발자가 개발 브랜치만 마주하는 것을 권장합니다). 만약 검증 릴리스 검증 과정에서 빌드 환경에 심각한 버그가 발견되어 즉시 수정이 필요해지면, 핫픽스 브랜치에서 긴급히 수정하고, 올바른 것을 확인한 후 긴급히 실행됩니다. 동시에 핫픽스 브랜치는 개발 버전과 병합되는데(여기서는 대부분 수동으로, 당시 생산 버전이 개발 버전과 매우 다르고 자동 병합을 완료하는 것이 종종 불가능하기 때문입니다), 그리고 개발 부서는 릴리스에 병합됩니다. 일정 기간 후에는 청구 반환 기능이 더 이상 필요하지 않아 취소해야 할 수 있으므로, 청구 반환 기능 분기는 삭제됩니다. 또 다른 기능은 보험이 쉽고, 개발 부서에 다시 통합되어 다음 온라인 버전에서 공개되었습니다.
위 시나리오는 기본적으로 일상적인 개발, 짐 풀기, 긴급 업데이트 및 일상 개발 과정의 기타 시나리오를 포함합니다.
|
게시됨 2018. 4. 8. 오전 10:25:39
|
|
|
|
