지속적 통합에서 여러 분기 처리

Question 1

저는 회사에서 CI 확장 문제를 다루면서 동시에 CI 및 여러 지점과 관련하여 어떤 접근 방식을 취해야하는지 파악하려고 노력하고 있습니다. stackoverflow, 다중 기능 분기 및 지속적인 통합에 유사한 질문이 있습니다 . 나는 더 많은 토론을 얻고 질문에 대한 분석을 제공하고 싶기 때문에 새로운 것을 시작했습니다.

지금까지 내가 취할 수있는 두 가지 주요 접근 방식이 있음을 발견했습니다 (또는 다른 방법 ???).

브랜치 당 여러 작업 세트 (여기서 Jenkins / Hudson에 대해 설명)
- 추가 작업을 관리하기위한 도구 작성
  - 일괄 작업 생성 / 수정 / 삭제
  - 지점 별 각 작업에 대한 사용자 지정 설정 (SCM URL, dep 관리 저장소 중복)
  - 셸 도구, ant 스크립트 및 Jenkins CLI를 사용하여이 문제를 해결하는 사람들의 몇 가지 예입니다. 보다:
- CI 클러스터에 더 많은 부하를 유발합니다.
- 개발자를위한 피드백주기가 느려집니다 (인프라가 새로드를 처리 할 수없는 경우).
2 개 브랜치 당 여러 작업 세트 (개발 및 안정)
- 두 세트를 수동으로 관리합니다 (작업의 conf를 변경 한 경우 다른 분기에서 변경해야 함)
  - PITA이지만 관리해야 할 최소한
- 다른 추가 브랜치는 개발자로 푸시되기 전에 전체 테스트 스위트를 얻지 못합니다.
- 만족스럽지 않은 개발자. 개발자가 CI 확장 문제에 관심을 가져야하는 이유. 그는 간단한 요청을 가지고 있는데, 분기 할 때 내 코드를 테스트하고 싶습니다. 단순한.

따라서 개발자에게 자체 사용자 지정 분기에 대한 CI를 제공하려면 Jenkins (API 또는 셸 스크립트 등)에 대한 특수 도구가 필요하고 확장을 처리해야합니다. 또는 DEV에 더 자주 병합하고 사용자 지정 분기에서 CI없이 살도록 지시 할 수 있습니다. 어떤 것을 선택하거나 다른 옵션이 있습니까?

Question 2

CI 확장에 대해 이야기 할 때 실제로 주요 라인과 함께 모든 기능 분기를 처리하기 위해 CI 서버 사용을 확장하는 것에 대해 이야기하는 것입니다. 처음에는 지점의 개발자가 CI 작업에 포함 된 자동화 된 테스트의 모든 이점을 얻었으므로 이것은 좋은 접근 방식처럼 보입니다. 그러나 발견 한 것과 같은 CI 서버 작업을 관리하는 데 문제가 발생하고 더 중요한 것은 실제로 CI를 수행하지 않는다는 것입니다. 예, CI 서버를 사용하고 있지만 모든 개발자의 코드를 지속적으로 통합하지는 않습니다.

실제 CI를 수행한다는 것은 모든 개발자가 정기적으로 메인 라인에 참여하고 있음을 의미합니다. 말하기 쉽지만 어려운 부분은 응용 프로그램을 중단하지 않고 수행하는 것입니다. 지속적 배포 , 특히 13 장 : 구성 요소 및 종속성 관리 의 응용 프로그램 릴리스 가능 유지 섹션을 참조 하는 것이 좋습니다 . 요점은 다음과 같습니다.

완료 될 때까지 새 기능을 숨 깁니다 (일명 기능 토글 ).

일련의 작은 변경으로 점진적으로 모든 변경을 수행하십시오. 각 변경은 해제 할 수 있습니다.

추상화에 의한 분기를 사용하여 코드베이스를 대규모로 변경합니다.

구성 요소를 사용하여 다른 속도로 변경되는 애플리케이션 부분을 분리합니다.

추상화에 의한 분기를 제외하고는 꽤 자명합니다. 이것은 다음을위한 멋진 용어입니다.

변경해야하는 시스템 부분에 대한 추상화를 만듭니다.

추상화 계층을 사용하도록 시스템의 나머지 부분을 리팩터링합니다.

완료 될 때까지 프로덕션 코드 경로의 일부가 아닌 새 구현을 만듭니다.

새로운 구현에 위임하도록 추상화 계층을 업데이트합니다.

이전 구현을 제거하십시오.

더 이상 적절하지 않은 경우 추상화 계층을 제거합니다.

14 장 : 고급 버전 제어 의 분기, 스트림 및 지속적 통합 섹션 의 다음 단락 은 영향을 요약합니다.

점진적 접근 방식은 분기를 만들고 새로운 기능을 다시 설계하고 개발하는 데 궁호를 뛰어 넘는 것보다 더 많은 규율과주의, 그리고 실제로 더 많은 창의성을 요구합니다. 그러나 변경 사항으로 인해 애플리케이션이 중단 될 위험이 크게 줄어들고 병합, 파손 수정 및 애플리케이션을 배포 가능한 상태로 만드는 데 많은 시간을 절약 할 수 있습니다.

기능 브랜치를 포기하는 데 상당한 마음의 전환이 필요하며 항상 저항을 받게됩니다. 내 경험상이 저항은 개발자가 메인 라인에서 코드를 커밋하는 것이 안전하다고 느끼지 않는 데 기반을두고 있으며 이는 합리적인 관심사입니다. 이는 일반적으로 위에 나열된 기술에 대한 지식, 자신감 또는 경험 부족 및 자동화 된 테스트에 대한 자신감 부족에서 비롯됩니다. 전자는 교육 및 개발자 지원으로 해결할 수 있습니다. 후자는 처리하기 훨씬 더 어려운 문제이지만 분기는 추가적인 실제 안전성을 제공하지 않으며 개발자가 코드에 대해 충분히 확신 할 때까지 문제를 연기합니다.

Question 3

각 지점에 대해 별도의 작업을 설정했습니다. 저는 이전에이 작업을 수행했으며 Hudson / Jenkins를 올바르게 설정했다면 관리하고 설정하는 것이 어렵지 않습니다. 여러 작업을 빠르게 만드는 방법은 유사한 요구 사항이있는 기존 작업에서 복사하여 필요에 따라 수정하는 것입니다. 각 개발자가 자신의 브랜치를 위해 자신의 작업을 설정하도록 허용하고 싶은지 확실하지 않지만 한 사람 (예 : 빌드 관리자)이 관리하는 것은 많은 작업이 아닙니다. 사용자 지정 분기가 안정된 분기로 병합되면 해당 작업이 더 이상 필요하지 않을 때 제거 할 수 있습니다.

CI 서버의 부하가 걱정되는 경우 CI의 개별 인스턴스를 설정하거나 별도의 슬레이브를 설정하여 여러 서버의 부하를 분산 할 수 있습니다. Hudson / Jenkins를 실행중인 서버가 적절한 지 확인하십시오. Apache Tomcat을 사용했고 빌드 대기열을 처리 할 수있는 충분한 메모리와 처리 능력이 있는지 확인해야했습니다.

CI를 사용하여 달성하려는 목표를 명확히 한 다음 많은 수작업이나 중복없이 CI를 구현하는 방법을 찾는 것이 중요합니다. 전체 빌드 관리 프로세스를 단순화하는 데 도움이되는 CI 서버에서 실행되는 다른 외부 도구 또는 스크립트를 사용하는 데 아무런 문제가 없습니다.

Question 4

dev + stable 브랜치를 선택하겠습니다. 그리고 여전히 커스텀 브랜치를 원하고 부하를 두려워한다면, 이러한 커스텀 브랜치를 클라우드로 옮기고 개발자가 직접 관리하도록하는 것이 어떻습니까? 예 : http://cloudbees.com/dev.cb 이것은 현재 Kohsuke가있는 회사입니다. . Eclipse Tooling도 있으므로 Eclipse를 사용하는 경우 dev env에 바로 통합됩니다.

Question 5

실제로 문제가되는 것은 기능 분기로 격리를 구축하는 것입니다. 우리 회사에는 더 큰 배포판의 일부인 별도의 메이븐 프로젝트 세트가 있습니다. 이러한 프로젝트는 서로 다른 팀에서 유지 관리하지만 각 배포에 대해 모든 프로젝트를 릴리스해야합니다. 이제 featurebranch가 한 프로젝트에서 다른 프로젝트로 겹칠 수 있으며 빌드 격리가 고통 스러울 때입니다. 우리가 시도한 몇 가지 솔루션이 있습니다.

각 기능 분기에 대해 nexus에 별도의 스냅 샷 저장소를 생성합니다.
전용 슬레이브에서 로컬 저장소 공유
업스트림 저장소와 함께 repository-server-plugin 사용
하나의 개인 저장소로 하나의 작업 내에서 모두 구축

사실 마지막 솔루션이 가장 유망합니다. 다른 모든 솔루션은 한 가지 또는 다른 방식으로 부족합니다. job-dsl 플러그인과 함께 새 기능 브랜치를 쉽게 설정할 수 있습니다. 그루비 스크립트를 복사하여 붙여넣고, 가지를 조정하고, 시드 작업이 새로운 작업을 생성하도록합니다. 시드 작업이 관리되지 않는 작업을 제거하는지 확인하십시오. 그런 다음 다양한 메이븐 프로젝트에서 기능 분기로 쉽게 확장 할 수 있습니다.

그러나 톰이 위에서 잘 말했듯이 기능 브랜치의 필요성을 극복하고 개발자에게 깔끔하게 통합하도록 가르치는 것이 더 좋겠지 만, 이는 더 긴 프로세스이며 더 이상 손대지 않을 많은 레거시 시스템 부품으로 결과가 명확하지 않습니다.

내 2 센트