분기는 지속적인 통합을 중단합니까?

이 기사 인 성공적인 Git 브랜칭 모델 은 숙련 된 DVCS 사용자들 사이에서 잘 알려져 있다고 생각 합니다.

나는 hg주로 사용 하지만이 토론은 모든 DVCS에 적합하다고 주장합니다.

현재 워크 플로는 각 개발자가 마스터 리포지토리를 복제하는 것입니다. 우리는 우리 자신의 로컬 저장소에 코드를 작성하고 테스트를 실행하며 모든 것이 잘되면 마스터에게 푸시합니다.

따라서 Jenkins와 같은 CI 서버를 설정하고 향후 프로비저닝 시스템 (chef, puppet, ansible 등)으로 워크 플로를 개선하고자합니다.

진짜 부분

글쎄, 위의 모델은 훌륭하지만 브랜치는 CI를 손상시킬 수 있습니다. developmentCI와 병합을 원활하게 하려면 피처 브랜치 (기사에 따르면 브랜치가 됨)와 원점을 동기화해야 합니까?

Alice와 Bob이 두 가지 기능을 작업하고 있다고 가정합니다. 그러나 앨리스는 다음 날에 끝납니다. Bob의 기능은 일주일이 걸립니다. Bob이 완료 될 때 변경 사항이 오래되었습니다 (Alice가 리팩토링 / 일부 클래스 이름 변경).

해결책은 매일 아침 개발자가 master/origin변경 사항이 있는지 확인 해야한다는 것 입니다. Alice가 커밋 한 경우 Bob은 작업 영역으로 끌어와 병합하여 기능 분기를 최신 상태로 유지해야합니다.

1. 이것이 좋은 방법입니까?
2. 이러한 브랜치가 마스터 리포지토리에 존재해야합니까 (로컬 클론이 아닙니까?) 모든 개발자가 GitHub / Bitbucket의 마스터 리포지토리에 권한을 부여하여 새 브랜치를 생성해야합니까? 아니면 로컬로 수행됩니까?
3. 마지막으로, 기사가 제시 한 모델은 분기가와 동기화되지 않은 경우 CI를 중단해야합니다 origin/master. 야간 빌드를 원하기 때문에 개발자가 퇴근하기 전에 끌어서 병합해야하고 각 기능 지점에서 CI를 실행해야합니까?

우선, 기능 분기 (기능에서 수행 한 작업을 분리하기 위해)와 CI (커밋하자마자 통합 문제를 찾기 위해)를 사용하는 것은 약간 상충됩니다.

제 생각에는 기능 분기에서 CI를 실행하는 것은 시간 낭비입니다. 기능 분기가 자주 발생함에 따라 CI 툴링을 반복해서 다시 구성해야했습니다. 그리고 CI 시스템이 감지해야하는 문제를 피하기 위해 체크인을 조정하는 하나 또는 두 개의 소스에서만 업데이트를받는 지점의 경우가 많습니다.
따라서, 마스터 리포지토리 서버에 기능 분기가있을 필요도 없습니다.

질문 1과 3에 관해서는 : 주요 개발 지점의 빌드가 기능 분기를 병합 할 때 중단되지 않도록하는 것은 개발자의 책임입니다. 그들이하는 방법은 그들의 문제이지만, 가능한 두 가지 방법은 다음과 같습니다.

• 기본 개발 지점에 대한 변경 사항을 정기적으로 (예 : 매일) 기능 지점으로 가져옵니다.
• 기능이 완료되면 기본 개발 분기를 기능 분기로 병합하고 병합 결과를 기본 개발 분기로 푸시하십시오.

두 경우 모두 명백한 통합 문제 (예 : 이름이 바뀐 클래스 / 파일)가 기능 분기에서 먼저 발견되어 수정됩니다. 더 미묘한 문제는 야간 빌드가 실행될 때만 발견되며 수정해야합니다.

1) 님의 질문에 답변

작동하는 방법은 좋은 방법입니다. 그러나 : 지속적인 통합의 전체 전제는 통합하는 것이다 계속 . 아이디어는 가능한 한 빨리뿐만 아니라 개발 피드백주기 내에서 통합 버그를 포착하는 것입니다. 즉 테스트중인 코드에 대한 모든 세부 사항이 개발자의 단기 메모리 내에있는 동안 변경합니다. 즉, 일상적인 일상 환경에서 모든 커밋마다 15 분마다 한 번씩 기능 지점 전체에 작업을 통합해야합니다. 반복적 인 설명 : 지속적인 통합의 주요 목적은 통합 버그를 노출시키는 반면 모든 세부 사항은 개발자가 변경하는 단기 메모리에 있습니다.

2)

대부분 리포지토리를 복제하여 Mercurial에서 브랜치를 생성하므로 모든 개발자에게 마스터 리포지토리에 대한 커밋 권한을 부여 할 필요는 없습니다. 그러나 테스트를 항상 로컬에서 실행할 수있는 것은 아니기 때문에 개발자가 연속 통합 서버에서 복제 된 저장소를 작성할 수있는 기능을 제공하려고합니다. (한 번은 128 개의 핵심 클러스터에서 장치 테스트를 실행하는 데 8 시간이 걸렸던 CI 시스템이있었습니다.) 물론 개발자는 로컬 테스트를 수행 할 수 없었습니다.

삼)

컴퓨팅 리소스가 있다면, 개발자는 항상 주요 개발 라인을 항상 최신 상태로 유지해야하며, 특히 출근 전에 항상 모든 개발 라인에서 야간 테스트를 실행해야합니다 (대부분의 CI 시스템이지만) 이것을 쉽게 만들지 마십시오).

기능 분기를 수행하는 방법은 다음과 같습니다.

1. 새로운 작업 (버그 수정, 기능 등)에 대해 새 분기를 시작하십시오 (예 : bugfix-ticket123-the_thingie_breaks)
2. 작업하는 동안 기본 (또는 git의 마스터) 을 지속적으로 업데이트 하여 기능 분기로 병합 하십시오 . 이를 통해 기본 지점에서 작업하지 않고도 지점을 업데이트 할 수 있습니다.
3. 기능이 준비되고 단위 테스트가 통과 한 다음 기본으로 분기에 다시 한 번 끌어 당기고 병합하고 분기하지 않고 병합하지 않으면 통합자가 새 헤드를 인식하고 폐쇄 된 분기임을 알 수 있습니다. 통합을 처리합니다. 적분기가없는 경우 기본값으로 전환하고 기능 분기를 기본값으로 병합하십시오 .

여기서 중요한 것은 기능 분기를 병합 할 때 기본 분기에서 충돌 이없고 모든 테스트 가 통과 한다는 것 입니다.

이 간단한 워크 플로우를 사용하면 항상 깨끗하고 안정적인 기본 분기를 갖게되며 이제 릴리스 분기에서도 동일하게 수행하지만 default와 통합됩니다 . 핫픽스를 릴리스 분기에 직접 통합해야하는 경우에도 기본 분기를 건너 뛰어이 작업을 수행 할 수 있지만 대상 분기에서 방금 업데이트되었으며 충돌이없고 단위 테스트가 통과 된 분기 만 선택하면됩니다.