DVCS는 지속적인 통합을 방해합니까?

민첩한 개발자 10 명으로 구성된 팀이 있다고 가정 해보십시오. 그들은 매일 보드에서 작업을 선택하고 작업이 끝날 때까지 여러 가지 변경 사항을 커밋합니다. 모든 개발자는 트렁크에 직접 체크인합니다 (Google 스타일, 모든 커밋은 기능 전환 등을 사용하여 릴리스 후보입니다).

SVN과 같은 중앙 집중식 CVS를 사용하는 경우, 이들 중 하나가 커밋 할 때마다 빌드 서버는 다른 9 명의 개발자 작업과 변경 사항을 통합하고 테스트합니다. 빌드 서버는 하루 종일 거의 계속 실행될 것입니다.

그러나 git과 같은 DCVS를 사용하는 경우 개발자는 모든 로컬 커밋을 중앙 저장소로 푸시하기 전에 작업을 완료 할 때까지 기다릴 수 있습니다. 변경 사항은 하루가 끝날 때까지 통합되지 않습니다.

이 시나리오에서 SVN 팀은 지속적으로 더 자주 통합하고 git 팀보다 훨씬 빠르게 통합 문제를 발견합니다.

이것은 DVCS가 오래된 중앙 집중식 도구보다 지속적인 팀에 적합하지 않다는 것을 의미합니까? 이 지연 푸시 문제를 어떻게 해결합니까?

면책 조항 : 나는 Atlassian에서 일합니다.

DVCS는 개발자가 정기적으로 원격으로 자신의 브랜치를 푸시하고 CI 서버가 알려진 활성 브랜치를 빌드하도록 설정되어있는 한 Continuous Integration을 권장하지 않습니다.

전통적으로 DVCS와 CI에는 두 가지 문제가 있습니다.

• 통합 상태의 불확실성 -개발자가 마스터에서 정기적으로 병합하고 빌드를 실행하지 않는 한 결합 된 변경 상태가 무엇인지 알 수 없습니다. 개발자가 수동으로이 작업을 수행해야하는 경우 문제를 조기에 발견 할 수있을 정도로 자주 수행되지 않을 수 있습니다.
• 빌드 구성의 복제 및 드리프트 -분기 빌드를 작성하기 위해 빌드 구성을 '마스터'빌드에서 복사해야하는 경우 분기 구성이 복사 된 빌드와 신속하게 동기화되지 않을 수 있습니다.

Bamboo에서는 개발자가 생성 한 새 분기를 빌드 서버에서 감지하고 마스터의 빌드 구성을 기반으로 분기에 대한 빌드를 자동으로 설정하는 기능을 소개했습니다. 따라서 마스터 빌드 구성을 변경하면 분기 구성도 변경됩니다. 변화를 반영하기 위해).

또한 분기 빌드가 실행되기 전에 마스터에서 변경 사항으로 분기를 업데이트하거나 성공적인 빌드 분기에서 마스터로 변경 사항을 자동으로 푸시하여 분기 간 변경 사항을 가능한 한 빨리 테스트 할 수있는 병합 전략이라는 기능이 있습니다. .

어쨌든 더 배우고 싶다면 내 블로그 게시물 "연속 통합으로 효과적인 기능 분기 만들기"를 참조하십시오.

내 소규모 팀은 1 년 또는 2 년 전에 DVCS로 전환했으며 나머지 회사는 몇 달 전에 적합했습니다. 내 경험상 :

• 중앙 집중식 VCS를 사용하는 사람들은 대규모 프로젝트를 수행 할 때 여전히 커밋을 보류하는 경향이 있습니다. 이것은 DVCS 고유의 문제가 아닙니다. 커밋을 수행하기 전에 며칠 동안 대기하는 변경 세트가 있습니다. 가장 큰 차이점은이 시점에서 어느 시점에서 실수를하거나 컴퓨터가 충돌하는 경우이를 해결하기 위해 훨씬 더 많은 노력이 필요하다는 것입니다.
• 우리는 각 개발자가 자신의 이름이 지정된 지점에서 작업하는 커밋 워크 플로를 사용하며 코드를 검토 한 사람 만 변경 내용을 헤드에 병합 할 수 있습니다. 이렇게하면 커밋이 문제를 일으킬 가능성이 줄어들므로 빌드 서버에서 오류 메시지가 생성 될 때 사람들이주의를 기울여야합니다. 또한 다른 개발자가 헤드가 고정 될 때까지 자체 브랜치에서 계속 작업 할 수 있습니다.
• DVCS에서 사람들은 코드 를 헤드와 병합하기 전에 프로그래밍에 더 많은 시간을 소비하는 경향이 있습니다. 따라서 빌드의 연속성에 약간의 지연이 발생하는 경향이 있습니다. 그러나 그 차이는 DVCS의 장점을 상쇄하기에 충분하지 않습니다.

필자는 최근 Subversion over Mercurial을 사용한 약 19 개의 프로젝트 (저는 Subversion 괴짜 였습니다)를 관찰했습니다 . 개발자는 자체 지점에서 작업하고 서버 일 또는 주 후에 만 ​​통합하여 실제로 개인 주의자가되기 시작했습니다. 이로 인해 심각한 통합 문제와 우려가 발생했습니다.

우리가 직면 한 또 다른 문제는 지속적인 통합 서버입니다. 커밋 동기화가 서버에 수행 된 경우에만 문제에 대한 알림을 받았습니다 (예 : 테스트 실패).

Martin Fowler 가 자신의 사이트 에 그것에 대해 쓴 것으로 보입니다 .

즉, 내가 언급 한 프로젝트 중 일부는 문제를 줄이기 위해 하루에 한 번 이상 동기화를 수행했습니다. 따라서 귀하의 질문에 답하기 위해 DVCS 는 지속적인 통합을 방해하고 개인주의를 증가시킬 수 있다고 생각합니다 . 그러나 DVCS는 직접적인 원인이 아닙니다.

사용하는 VCS에 관계없이 개발자는 여전히 책임이 있습니다.

당신의 추론에 근거한 아이디어는 매우 흔들리고 부드럽게 말하는 것입니다. 개발자가 작업을 완료 할 때까지 기다릴 수있는 것은 팀 / 관리 / 프로세스의 문제입니다 .

이 방법을 "대기"또는 "서두르 기", 공유 트렁크 또는 격리 된 분기로하는 것은 분기 전략으로 알려져 있으며 온라인 에서 정보 를 연구하는 경우 특정 전략을 선택하면 기본적으로 아무 관련이 없습니다. VCS가 중앙 집중식 또는 분산되어 있습니다.

Mercurial과 같은 분산 VCS의 경우 빈번한 병합에 대한 강력한 권장 사항을 쉽게 찾을 수 있습니다 .

먼저 자주 병합하십시오! 이렇게하면 모든 사람이 쉽게 병합 할 수 있으며 이전에 (호환되지 않는 디자인 결정에 기인 한) 충돌에 대해 알게됩니다 ...

위와 같은 권장 사항을 연구하면 Mercurial이 배포되는 것과 관련이없는 고려 사항에 대한 이러한 호소를 쉽게 알 수 있습니다.

이제 중앙 집중식 VSC 인 Subversion의 상황을 살펴 보겠습니다. 온라인 정보를 연구하면 안정적인 트렁크 와 불안정한 트렁크 라는 인기있는 전략 중 하나를 찾을 수 있습니다. 각 전략 은 병합 빈도에 반대의 영향을 미칩니다. 사람들은 VCS가 집중되는 것에주의를 기울이지 않고도 일을하는 다른 방법을 선택합니다.

• ^{중앙 VCS에서 심각하게 지연된 병합 (라임 관리에 의해 장려 됨)이 발생하는 것을 보았고 팀 / 관리자가 올바른 방법이라고 생각했을 때 DVCS로 자주 병합하는 것을 보았습니다. VCS가 어떤 식 으로든 다른 방법으로 배포되거나 중앙 집중화되는지 신경 쓰지 않는 것을 보았습니다.}

위에서 주어진 것처럼 DVCS는 지속적인 통합을 방해합니까? 것 뮤 .

VCS가 배포되거나 배포되지 않으면 VCS에 큰 영향을 미치지 않습니다.

내 경험은 정반대입니다 . svn을 사용하는 팀은 수일 동안 밀지 않을 것입니다. 작업중 인 코드로 인해 트렁크가 수동 병합에 시간을 낭비하지 않고 다른 사람을 위해 컴파일하지 않을 수 있기 때문 입니다. 그런 다음 스프린트가 끝날 무렵에 모든 사람이 커밋하고 광기 병 합병이 일어나고 물건을 덮어 쓰거나 잃어 버려 복구해야합니다. CI 시스템이 빨간색으로 바뀌고 손가락 포인팅이 발생합니다.

Git / Gitorious에서는이 문제가 발생하지 않았습니다.

Git을 사용하면 다른 사람이 변경 한 내용을 확인하고 체크인하고 싶지만 20 분 동안 수동으로 병합 할 수 있기 때문에 다른 사람의 변경 사항을 편의에 따라 끌어서 병합 할 수 있습니다.

Git을 사용하면 다른 사람의 커밋을 가져 와서 코드를 병합 한 다음 작업 버전을 다른 사람에게 푸시하여 변경 한 내용에 따라 병합 해야하는 것을 추측 할 필요가 없습니다.

병합 요청 을 통한 코드 검토를위한 중재자로 Gitorious와 같은 것이 있으면 많은 지사와 많은 기고자를 관리하는 데 어려움이 없습니다.

Git 저장소의 모든 활성 브랜치를 추적하도록 Jenkins / Hudson을 설정하는 것도 매우 쉽습니다. 우리는 SVN에서 Git으로 옮길 때 CI에 대한 견인력과 저장소 상태에 대한 피드백을 더 자주 얻었습니다.

빌드 서버가 저렴합니다. CI 서버가 알고있는 모든 지점을 선택하도록하십시오.

Jenkins는 여러 git 리포지토리를 확인하고 단일 작업의 모든``최신 ''을 얻도록 지원합니다. 다른 도구와 비슷한 솔루션이 있다고 확신합니다.

이 오래된 질문은 방금 새로운 질문으로 복제되었으며 많은 답변이 오래된 아이디어를 참조하기 때문에 업데이트 된 질문을 게시 할 것이라고 생각했습니다.

5 년 전에는 흔하지 않은 한 가지 이유는 풀 요청 분기에서 CI 테스트를 실행하여 마스터로 병합하는 것이 었습니다. 나는이 병합 자주 바람직하지만, 공유하는 변화 태도를 반영하고 생각하는 모든 과 변화 모두를 , 즉시 그것을 만들로 , 최적이 아니다.

DVCS는 커밋을 통합하는보다 계층적인 모드를 만들었습니다. 예를 들어, 나는 종종 내 옆에 앉아있는 개발자와 매우 밀접하게 작업을 수행합니다. 우리는 하루에 여러 번 서로의 가지에서 뽑을 것입니다. 오늘 우리는 몇 시간마다 풀 요청에 대한 변경 사항을 통해 다른 개발자와 협력했습니다.

빌드 스크립트를 광범위하게 변경했습니다. Jenkins는 모든 PR 지점을 마스터와 로컬로 병합하고 테스트를 실행하므로 깨끗한 빌드가 필요한 다른 개발자를 방해하지 않으면 서 자동으로 피드백을 받았습니다. PR이 통합되어 3 명의 개발자 그룹 외부에서 공유하고 공유 할 준비가되기까지는 하루가 더 걸릴 것입니다.

그러나 누군가 변경 사항이 마스터에 병합되기를 기다릴 수없는 경우 변경 사항이 변경 사항에 의존하기 때문에 개발자 분기를 로컬로 병합하고 작업을 계속할 수 있습니다. 이것은 CVCS에 익숙한 많은 사람들이 그리워하는 것입니다. CVCS를 사용하면 변경 사항을 공유 할 수 있는 유일한 방법은 변경 내용을 중앙 저장소에 병합하는 것이므로 병합하는 것이 더 중요합니다. DVCS를 사용하면 다른 옵션이 있습니다.

DVCS가 지속적인 통합에 더 도움이된다고 말하고 싶습니다. 합병은 그들에게 자극적이지 않습니다. 그러나 더 많은 훈련이 필요합니다. 기본에서 가져와 로컬 커밋을 따라 병합 한 다음 작업이 완료되면 (다음으로 이동하기 전에) 푸시해야합니다.

우리 팀이 Git으로 전환했을 때, 우리는 프로세스를 명시 적으로 배치하여 이전 VCS에서 푸시가 정확히 커밋처럼 취급되고 각 커밋이 자주 / 가끔 자주 수행되도록 할 수있었습니다. 따라서 DVCS를 사용하든 중앙 집중식 VCS를 사용하든 CI 시스템에는 차이가 없습니다.

대답은 '그렇다'입니다.

여기서 차이점은 중앙 CI 조회 리포지토리에 직접 커밋하고 변경 사항을 중앙 CI 조회 리포지토리로 푸시하는 것입니다. 당신이 발견 할 수있는 '문제'는 DVCS 사용자가 실제로 그러한 푸시를 정기적으로 수행하지 않을 수 있다는 것입니다.

이것이 DVCS의 고유 한 디자인 기능이라고 말하고 싶습니다. 변경 사항을 중앙 서버로 항상 푸시하도록 설계되지 않았습니다. 그렇다면 CVCS를 대신 사용할 수도 있습니다. 따라서 개발자들 사이에 더 나은 워크 플로를 시행하는 것이 답입니다. 그들에게 매일 밤 변화를 강요하라고 말한다. 단순!

(그리고 SVN 사용자가 매일 밤 커밋하지 않으면 정확히 같은 문제를 알려주십시오).

Git은 지속적인 통합을 방해하지 않습니다. 트렁크 기반 워크 플로우입니다.

직관적이지 않은 것처럼 들리지만 개발자가 기능 분기에서 작업하는 경우 자신의 컴퓨터에 자주 통합하도록 권장 할 수 있으며 병합을 위해 기능을 제출하기 전에 그렇게해야합니다. 반대로 트렁크 기반 워크 플로는 커밋이 커지므로 통합 빈도가 줄어 듭니다.

Google 스타일 트렁크 기반 워크 플로는 병합이 쉬운 Git과 같은 VCS를 사용하면 비생산적입니다. 대신 조언하는 것이 있습니다.

• 개발에 하루나 이틀이 걸리지 않을 정도로 기능을 작게 나누십시오.
• 각 기능은 개인 지점에서 개발되었습니다.
• 개발자는 개인 브랜치 ( git fetch origin; git merge master) 에 자주 통합됩니다 . 나는 보통 이런 식으로 일할 때 하루에 여러 번 이것을한다.
• 개발자가 병합 및 검토를 위해 지점을 제출하면 CI 서버가 자동 빌드를 수행합니다. 이 경우에만 병합이 발생합니다.

따라서 작은 커밋, 빈번한 통합 및 커밋이 어떤 기능에 속하는지 추적 가능한 기록이 있습니다. 올바르게 사용되는 지점은 Git에 대한 가치가있는 모든 것의 핵심이므로이를 피하는 것은 큰 실수입니다.

@jdunay와 같은 멋진 기술 솔루션이 언급되었지만 사람들이 svn에 헌신하는 환경을 조성하는 것이 사람들의 문제와 같은 방식으로 사람들의 문제입니다.

우리를 위해 일한 것은 : ( 'master'를 현재 활성화 된 dev 분기로 대체하십시오)

1. 마스터에서 자주 병합 / 리베이스
2. 마스터에 자주 밀어

3. 특정 리팩토링과 같은 합병을 유발하고 의사 소통을 통해이를 완화시키는 것들에 대한 인식. 예를 들면 다음과 같습니다.

   • 점심 식사 전에 모두가 밀도록하십시오
   • 점심 식사 시간 동안 리팩토링 수행 및 푸시
   • 점심 식사 후 모두가 잡아 당겨야합니다