복잡한 분기 현실에서 단일 지점 모델로 전환하는 방법은 무엇입니까?

대규모 조직에서 폭포수 방법을 사용하면 일반적으로 매우 복잡한 분기 구조 (일명 branch spagetti )가 발생합니다.

복잡한 분기 현실에서 트렁크 기반 개발과 같은 단일 분기 모델로 전환하는 데 사용할 수있는 분기 전략은 무엇입니까?

최신 정보:

명확히하기 위해, 이전 및 이후 방법론이 아니라 마이그레이션 / 전환 자체 에 대한 질문이 있습니다.

실제로는 "오늘날 EOB에서는 여전히 여러 가지의 분기가있는 폭포이지만 내일은 트렁크 기반의 단일 분기 CI로 전환 할 것"입니다.

폭포를 언급했기 때문에, 당신이 암시하는 수많은 가지가 유지 보수 지점이 아니라 기능 지점이라는 것을 알고 있습니다.

이 설정에서는 이러한 분기가 충돌을 최소화하려는 폭포수 계획에 따라 만들어진 것으로 가정합니다. 이는 개발 목표가 여러 가지 고유 한 제품을 생산하는 것임을 의미합니다. 단일 지점 개발 모델을 사용하는 경우 단일 제품에서도 작업하는 것이 중요합니다. 단일 브랜치 개발 모델에서 여러 제품이 동시에 개발되는 경우 이러한 버전의 제품을 효과적으로 "접착"하여 버전 a 의 저장소 a 에서 버전 b 에서는 정상 제품 X 및 버그가있는 제품 Y를 가질 수 있습니다. 제품 X 에는 회귀가 있고 Y 에는 버그 수정이 있지만 X 와 X 가 모두있는 버전은 없습니다Y 는 건강합니다. 이러한 상황에서 우리는 X 와 Y 가 별개의 저장소에서 개발되고 있다고 생각하게 될 것입니다.

따라서 첫 번째 단계는 리포지토리 분할을 수행 해야 합니다 .

1. 여러 작은 저장소로 쉽게 분리 할 수 ​​있도록 저장소를 배열하십시오. 예를 들어, 각 최상위 레벨 디렉토리가 나중에 작성하려는 저장소에 해당하도록 현재 저장소를 재 배열하십시오. 그렇게함으로써, 여러분은 모두에게 친숙한 브랜치 스파게티를 계속 사용할 수 있습니다 .

2. 1 단계가 완료되면 단일 분기가 하나의 최상위 디렉토리에있는 파일 만 만질 수 있도록 하여 분기 스파게티 규율을 개선하십시오 .

3. 각 분기가 2 단계를 준수하면 분할을 수행하십시오. 개발자는 경로의 첫 번째 레벨을 제거하기 만하면 보류중인 변경 사항을 쉽게 변환하여 단일 저장소를 패치 할 수 있습니다.

이제 분할이 수행되었으므로 지점 전문 분야 자체에서 작업을 시작할 수 있습니다.

4. 단기 브랜치 개발을 돕는 프로그래밍 기술을 소개합니다. 수명이 짧은 지점은 모든 단일 지점 방법론의 중요한 측면입니다. 그들의 목표 중 하나는 오래 지속되는 지점을 병합하고 디버깅하는 데 소요되는 시간을 줄이는 것입니다. "공장"은 구성 플래그를 사용하여 객체의 히스토리 버전 또는 초기에 부분적으로 개발 된 새로운 버전의 객체를 생성하는 "기능 플래그"의 도입입니다.

5. 지금까지 각 지점에 몇 개의 지점 만있는 수십억 개의 저장소가 있으며, 트렁크에 원래 지점-스파게티 산이 붕괴되는 것을 보지 않고도“전 세계적으로 트렁크 기반 개발 원칙을 채택합니다”버튼을 돌릴 수 있습니다 .

실제 리포지토리 분할은 선택 사항 일 수 있지만 제출 된 각 패치의 허용 범위를 명확하게 나타내는 정책을 채택해야합니다 (본 지점에서 변경 사항을 병합 할 때 충돌 위험을 제한하기 위해). 충돌로 인한 오버 헤드를 줄이는 것이 단일 브랜치 모델 방법론의 목표 중 하나이므로 이것이 귀하의 상황과 관련이 있다고 가정합니다.

무언가에서 다른 것으로 이주 할 때 정의해야 할 것은 두 가지뿐입니다.

1. 당신의 목표는 무엇입니까
2. 가는 방법 (이주 계획)

첫 번째 부분은 슬프게도, 종종 간과 또는 인 방법 너무 막연. 당신은 단순히 당신이 가진 것이 엉망이고 그것을 조직하고 싶다고 말할 수 없습니다. 그게 무슨 뜻이야? (: 모든 디바이스가 생각 일명 모두가 서로 다른 해석을 할 것이다 그의 혹은 그녀의 일을하는 방법이 최고입니다).

기회는 당신이 봉사하거나 목적을 달성 한 모든 지점입니다. 명확하게 정의 된 대상 프로세스가 없으면 사람들은 자신에게 가장 적합한 방식으로 자신에게 맞는 작업을 계속 수행 할 것입니다.

예를 들어, Vincent Driessen이 "성공적인 Git 분기 모델"을 정의한대로 대상을 명확하게 정의해야합니다 . 이 모델을 살펴보면 매우 정확합니다. 안정적인 코드의 위치와 불안정한 기능을 개발해야하는 위치를 나타냅니다. 또한 분기, 업데이트 및 병합 방법 및시기도 설명합니다. 각 브랜치가 무엇을 위해 무엇을해야하는지 알고 있습니다. 우리는 Vincent가 제시 한 변형을 사용하며 변형은 위키에 정의되어 있습니다.

중요한 점은 모든 팀이 목표를 이해하고 동의하도록하는 것입니다. 사람들이 개인적으로 선호하는 브랜칭 모델을 찾고 있지 않지만 모든 팀 구성원이 쉽게 동의하고 사용할 수있는 모델을 상기시키는 것이 좋습니다.

목표가 설정되면 마이그레이션 계획을 구체화 할 수 있습니다. 그 계획은 원하는만큼 길거나 짧을 수 있습니다. 이러한 분기 모델이 밤새 부과되는 것을 보았습니다. 다른 곳에서는 2 ~ 3 회 이상의 스프린트를 거쳤습니다. 우리가 발전하는 한 나에게별로 중요하지 않습니다.

"가장 큰"또는 더 중요한 분기로 시작할 수 있습니다. 예 : "지금부터 마스터는 항상 prod에 배포 된 상태에 있어야하며 dev 분기는 항상 컴파일해야합니다"(또는 규칙에 관계없이). 그런 다음 버전 (릴리스) 분기를 시행하십시오. 그런 다음 기능 분기를 시행하십시오. 그런 다음 버전 분기에 코드 동결을 적용하십시오.

DevOps는 커뮤니케이션, 개방성 및 효율성에 관한 것입니다. 이러한 개념은 프로세스 전체에서 염두에 두어야합니다.

개발 팀 외부의 일부 사람들을 관찰자로 프로세스 회의에 초대하는 것이 좋습니다. 작전 또는 중간 관리 진은 모델에 대해 한두 가지를 말할 수 있습니다. 개발자의 요구에 우선 순위를 두어야하지만 분기 모델이 사물을 관리하는 방식과 일치 할 수없는 경우 한두 달이 아니라 지금 더 잘 알고 있어야합니다.

정말 큰 팀이 있다면 그럼에도 불구하고 모든 사람을 포함 시키십시오. 매우 큰 팀이 있으면 어쨌든 두세 번의 회의가 끝납니다. 따라서 회의실에 팀 리더를 초대하지만 웹 캐스트를 사용하여 모든 사람에게 알려주십시오. 제안이나 우려 사항이있는 사람은 팀 리더에게 의견을 제시 할 수 있으며, 유효한 경우 두 번째 또는 세 번째 모임에서 해결됩니다.

다중 분기 hydra 저장소를 단일 분기 모델로 변환하는 것은 실제로 매우 간단합니다.

먼저, 자신과 마스터 또는 트렁크 사이의 차이가 가장 적은 가지로 시작하고 싶습니다. 나이와 관련성을 조사하십시오. 여전히 관련이 있으면 함께 병합하고 갈등을 해결하십시오. 더 이상 관련이 없으면 삭제하십시오.

모든 지점을 병합하고 모든 충돌을 해결하고 단일 지점 만 남을 때까지이 프로세스를 계속하십시오.

이 간단한 개요를 따라 시작할 수 있습니다.

1. 마스터 / 트렁크 지점의 사본을 작성하여 호출하십시오. temp_master
2. 마스터 / 트렁크에서 가장 큰 분기점을 찾으십시오.
3. 분기를 보관, 보관 또는 삭제할 필요가 있는지 확인하십시오.
   1. 유지해야하는 경우 4 단계를 계속하십시오.
   2. 삭제 또는 보관해야하는 경우 삭제 및 보관 한 다음 2 단계로 돌아갑니다.
4. 발산이 가장 적은 다음 분기를 찾으려면 2 단계를 반복하십시오.
5. 2 단계와 3 단계에서 찾은 두 가지를 병합하여 모든 충돌을 해결하십시오.
6. 이 두 지점을 지점으로 병합하십시오 temp_master.
7. temp_master 코드에서 코드를 테스트하여 컴파일 및 빌드 여부를 확인하고 온전한 다른 자동화 테스트를 실행하십시오.
   1. 테스트가 실패하면 돌아가서 이유를 찾아서 수정 한 후 프로세스를 반복하십시오.
   2. 테스트가 여전히 실패하면 서로 다른 두 가지를 선택하십시오.
8. 마스터 / 트렁크 및 분기가 두 개만있을 때까지 2-7 단계를 반복하십시오 temp_master.
9. 마지막 temp_master으로 마스터 / 트렁크에 병합 하여 새로운 단일 브랜치 모델을 사용하십시오.

전형적인 사주 질주주기에 대규모 조직을 위해 힘내-흐름 당신은 기능 지점 마스터 생산 준비 가지의 이점은 또한 항상 전개 할 수 있기 때문에 두 가지를 수행하여 마스터 분기 원치 않는 커밋에서 청결하게 유지되고, 접근 방식을 선호는 기능에서에주기 (커밋 Develop및 Develop지점을 마스터하기).

또한 분기는 생산 릴리스 빈도에 따라 결정됩니다. 프로덕션에 자주 배포하려면 기능 분기 또는 중앙 집중식 모델을 사용하는 것이 좋습니다. 이 경우 지점 관리의 오버 헤드는 생산 안정성을 유지하기 위해 낮은 환경에서 강력한 테스트로 전환됩니다.