지속적인 통합 및 DVCS를위한 패턴

12

우리는 현재 Subversion과 TeamCity를 사용하고 있으며 Mercurial (특히 FogBugz 사용자 인 킬른)을 사용하기로하겠습니다.

분명히 이것은 개발 패턴 (우리 둘 다)에서 변화 (바람직하게 개선)를 초래할 것입니다. 그러나 내가 고민하고있는 한 가지 문제는 지속적인 통합 / CI 서버의 이점을 여전히 누릴 수 있도록 구조를 구성하는 방법입니다 ( 혜택이 존재하고 남아있을 것이라는 점에 대한 논의는 이 질문 의 범위를 벗어난다 ).

SVN을 통해 우리는 제한된 수의 중앙 리포지토리에 집중하고 있습니다. 사실상 하나의 프로젝트 (하나 이상의 Visual Studio 솔루션)로 빌드를 쉽게 트리거하고 모든 파일이 커밋되었고 그 파일이 없다는 확신을 얻습니다. 부유 한 의존성 등. 그러나 우리가 적절한 수은의 장점을 취하려면 더 많은 저장소 인스턴스를 원할 것입니다. 여기서 변경 사항이 일반적으로 결정적인 "실제"저장소로 흐를 것으로 기대합니다. 내가 어려움을 겪고있는 문제는 라이브 레포가 CI 빌드를 트리거하기에는 너무 "늦게"보인다는 것입니다. 개발자 당 프로젝트 당 하나의 CI 빌드가 너무 많을 수 있습니다 (다른 문제를 유발할 수 있음).

나는 조금 낚시를하고 있지만 그것은 중앙 서브 버전 리포지토리가 제공하는 것 중 하나 (나의 설정과 함께!)가 언제 빌드해야하는지에 대한 많은 명확성 때문이다.

nb 나는 지속적인 통합으로 수은을 사용하는 메커니즘에 대해 묻지 않고있다. 나는 개인 프로젝트, 그 패턴과 구조, 작업 실습 / 워크 플로우에 대한 대우를 받고있다.

continuous-integration dvcs

— 머프
소스

왜 중앙 / "라이브"리포지토리에서 빌드를 시작하기에 너무 늦다 고 생각하십니까?

— c_maker

아직 방문하지 않았다면 Kiln 스택 교환 사이트 ( kiln.stackexchange.com )로 이동하십시오. 그것들은 이것을 설정하는 방법에 대한 꽤 많은 내용을 가지고 있습니다 ( kiln.stackexchange.com/questions/29/…) 개인적으로, 우리는 개인적으로 기능 당 분기를 사용하고 빌드 서버를 "마스터"분기로 지정합니다. )

— Chris Phillips

@Chris-CI 문제를 다루지 않는 것은 아닙니다.

— Murph

2

첫째, TeamCity에서 프로젝트 당 여러 빌드를 갖는 것이 실제로 진행되는 방법입니다. 플랫폼의 특성상 정말 쉬워집니다. 복사 버튼이 이유가 있습니다.

어쨌든, 우리가 SVN에 있었을 때, 우리는 일반적으로 각 프로젝트에 대해 2 개의 빌드를 실행했습니다. 하나는 기본 개발 라인 (우리의 경우 트렁크)에, 하나는 릴리스 지점에있었습니다. 에 분기 모델과 유사한 다음 동안 우리는 HG이 빌드 설정을 이월 이 하나 . 현재 SVN 개정 번호를 더 이상 사용할 수 없으므로 빌드 번호에 대한 새로운 펑크 Schwea를 찾는 것이 진짜 도전이었습니다.

우리는 특히 한 번에 많은 작업이 진행되고 더 빠른 피드백주기를 원할 때 사람들이 비교적 자주 추진하도록 노력하고 장려합니다. DCVS라고해서 하루에 한 번만 밀어야한다는 의미는 아닙니다.

— 와이엇 바넷
소스

Wyatt, 완료된 작업 단위 (ish)가있을 때 제 생각에 푸시가 발생합니다. DVCS의 장점 중 하나는 로컬에서 깨진 코드를 커밋 할 수 있다는 것입니다. 나는 하루가 끝나서 일정에 따라 행동한다는 개념을 정말로 싫어합니다. "백업"이라는 별도의 문제가 있습니다. 저에게-커밋시-백업용으로 존재하는 다른 복제본을 옆으로 밀어 넣는 규칙을 설정하는 것과 관련이 있습니다.

— Murph

2

트릭 작업 단위의 정의는 무엇입니까? "이 기능이 완료되었습니다"또는 "이 벽돌이 성공적으로 배치되었습니다"입니까? 우리는 후자를 향한 경향이 있습니다. 특히 명확하게 개발 된 분기가있는 분기 모델에서 특히 그렇습니다. 브레이킹 기능은 브랜치를 특징으로하는 것이 가장 좋습니다. 그 중 하나를 오래 실행하면 가능하면 CI 빌드도 얻을 수 있습니다. 특히 부엌에 여러 요리사가있는 경우.

— Wyatt Barnett

나는 "작업 단위"에 대한 귀하의 정의에 동의합니다. 이것이 제가 전체 모델 (“CI”빌드와“배포”빌드 모두를 수용하기 위해 프로젝트마다 여러 빌드를 이미 가지고 있음)과 약간의 어려움을 겪고있는 이유입니다. 맞습니다. 대답은 많은 빌드를 연결하는 것이므로 결국 실제 문제는 수표에 서명하게됩니다! 참조 된 브랜칭 모델도 옳습니다. 여전히 전체적인 패턴을 고려하고 (및 kilnhg를 구체적으로 허용하도록 추가 조정될 수 있도록 허용)

— Murph

2

우리는 약 1 년 동안 Kiln을 사용해 왔으며 여러 가지 다른 것을 시도했습니다. 우리가 끝낸 곳은 다음 브랜치 전략으로 브랜치 클론과 달리 명명 된 브랜치를 사용하는 것입니다.

기본 트랙 "완료"개발
기능 분기 는 현재 진행중인 작업을 추적
릴리스 브랜치 는 기본에서 릴리스 한 지점을 추적합니다.

따라서 현재의 기본 팁에서 기능 분기 를 작성하여 작업을 시작 하십시오 . 기능 분기 가 완료 되면 * 분기가 닫히고 기본값으로 다시 병합됩니다 .

언젠가 릴리스 할 준비가되었으므로 현재 팁에서 default 로 새 릴리스 브랜치 를 작성합니다 . 이를 통해 릴리스 브랜치 에 커밋 하면서 기능 브랜치 및 default 에 대한 적극적인 개발을 허용함으로써 현재 프로덕션중인 코드를 변경할 수 있습니다.

지속적인 통합과 관련하여 두 가지 작업을 수행합니다.

기본 상태를 모니터링하는 "항상 켜짐"통합
각 릴리스 지점에 대한 새로운 통합

기본 더 - 지점 작업은 우리가 우리의 주요 소스 트리가 항상 안정적인지 알 수 있습니다 릴리스 브랜치의 작업은 우리가 그 가지가 안정적이며 우리는 생산에 방출을 추진하는 데 필요한 빌드 출력을 우리에게 제공하는 것을 알 수 있습니다.

_{* "완료"에 대한 정의는 해당 기능이 최신 상태의 병합으로 최신 상태이며 코드 검토에서 승인되었다는 것입니다.}

— 크리스 필립스
소스

1

Hg와 같은 DVCS로 이동하면 "분산 된 부품"을 얻는 것뿐만 아니라 우수한 분기 및 병합 기능을 최대한 활용할 수 있습니다.

이제 좋은 이슈 트래커와 좋은 SCM을 갖게 될 것입니다 ... 각 작업마다 브랜치를 생성하지 않겠습니까?

"작업 당 분기"패턴은 새로운 것이 아니며 (Berczuk의 책을 확인하십시오) 반드시 시도해야 할 것입니다.

여기 에 자세히 설명하고 CI의 장단점은 여기에서 "제어" 합니다 .

— 프 산톨
소스

나는 행복하고 열정적으로 성공적으로 기능 및 유지 관리 분기 및

— 하위 버전