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

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

---

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

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

• 지점 당 여러 작업 세트 (여기에서 Jenkins / Hudson에 대해 설명)
  • 추가 작업을 관리하기위한 도구 작성
    • 일괄 작업 생성 / 수정 / 삭제
    • 지점 별 각 작업에 대한 사용자 지정 설정 (SCM URL, dep 관리 저장소 중복)
    • 쉘 도구, ant 스크립트 및 Jenkins CLI를 사용하여이 문제를 해결하는 사람들의 몇 가지 예입니다. 보다:
      1. http://jenkins.361315.n4.nabble.com/Multiple-branches-best-practice-td2306578.html
      2. http://jenkins.361315.n4.nabble.com/Is-it-possible-to-handle-multiple-branches-where-some-jobs-should-run-on-each-one-without-duplicatin-td954729. HTML
      3. http://jenkins.361315.n4.nabble.com/Parallel-development-with-branches-td1013013.html
      4. Hudson 작업을 자동으로 구성 또는 생성
  • CI 클러스터에 더 많은 부하를 유발합니다.
  • 개발자를위한 피드백주기가 느려집니다 (인프라가 새로운로드를 처리 할 수없는 경우).
• 2 개 지점 당 여러 작업 세트 (개발 및 안정)
  • 두 세트를 수동으로 관리합니다 (작업의 conf를 변경 한 경우 다른 분기에서 변경해야 함)
    • PITA이지만 관리해야 할 최소한의 수
  • 다른 추가 브랜치는 개발자로 푸시되기 전에 전체 테스트 스위트를 얻지 못합니다.
  • 만족스럽지 않은 개발자. 개발자가 CI 확장 문제에 관심을 가져야하는 이유. 그는 간단한 요청을 가지고 있는데, 분기 할 때 내 코드를 테스트하고 싶습니다. 단순한.

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

---

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

실제 CI를 수행한다는 것은 모든 개발자가 정기적으로 메인 라인에 투입된다는 것을 의미합니다. 말하기 쉽지만 어려운 부분은 응용 프로그램을 손상시키지 않고 수행하는 것입니다. 지속적 배포 , 특히 13 장 : 구성 요소 및 종속성 관리 의 응용 프로그램 릴리스 가능 유지 섹션 을 살펴볼 것을 강력히 권장합니다 . 요점은 다음과 같습니다.

• 완료 될 때까지 새 기능을 숨 깁니다 (일명 기능 토글 ).
• 일련의 작은 변경으로 점진적으로 모든 변경을 수행하십시오. 각 변경은 해제 할 수 있습니다.
• 추상화에 의한 분기를 사용하여 코드베이스를 대규모로 변경합니다.
• 구성 요소를 사용하여 다른 속도로 변경되는 애플리케이션 부분을 분리합니다.

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

1. 변경해야하는 시스템 부분에 대한 추상화를 만듭니다.
2. 추상화 계층을 사용하도록 시스템의 나머지 부분을 리팩터링합니다.
3. 완료 될 때까지 프로덕션 코드 경로의 일부가 아닌 새 구현을 만듭니다.
4. 추상화 계층을 업데이트하여 새 구현에 위임하십시오.
5. 이전 구현을 제거하십시오.
6. 더 이상 적절하지 않은 경우 추상화 계층을 제거합니다.

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

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

It takes quite a mind shift to give up feature branches and you will always get resistance. In my experience this resistance is based on developers not feeling safe committing code the the mainline and this is a reasonable concern. This in turn usually stems from a lack of knowledge, confidence or experience with the techniques listed above and possibly with the lack of confidence with your automated tests. The former can be solved with training and developer support. The latter is a far more difficult problem to deal with, however branching doesn't provide any extra real safety, it just defers the problem until the developers feel confident enough with their code.

---

I would set up separate jobs for each branch. I've done this before and it isn't hard to manage and set up if you've set up Hudson/Jenkins correctly. A quick way to create multiple jobs is to copy from an existing job that has similar requirements and modify them as needed. I'm not sure if you want to allow each developer to setup their own jobs for their own branches, but it isn't much work for one person (i.e. a build manager) to manage. Once the custom branches have been merged into stable branches, corresponding jobs can be removed when they are no longer necessary.

If you're worried about the load on the CI server, you could set up separate instances of the CI or even separate slaves to help balance the load across multiple servers. Make sure that the server you are running Hudson/Jenkins on is adequate. I've used Apache Tomcat and just had to ensure that it had enough memory and processing power to process the build queue.

It's important to be clear on what you want to achieve using CI and then figure out a way to implement it without much manual effort or duplication. There's nothing wrong with using other external tools or scripts that are executed by your CI server that help simplify your overall build management process.

---

I would choose dev+stable branches. And if you still want custom branches and afraid of the load, then why not move these custom ones to the cloud and let developers manage it themselves, e.g. http://cloudbees.com/dev.cb This is the company where Kohsuke is now. There is an Eclipse Tooling also, so if you are on Eclipse, you will have it tightly integrated right into dev env.

---

Actually what is really problematic is build isolation with feature branches. In our company we have a set of separate maven projects all be part of a larger distribution. These projects are maintained by different teams but for each distribution all projects need to be released. A featurebranch may now overlap from one project to another and thats when build isolation gets painfully. There are several solutions we've tried:

• create separate snapshot repositories in nexus for each feature branch
• share local repositories on dedicated slaves
• use the repository-server-plugin with upstream repositories
• build all within one job with one private repository

As a matter of fact, the last solution is the most promising. All other solutions lack in one or another way. Together with the job-dsl plugin it is easy to setup a new feature branch. simply copy and paste the groovy script, adapt branches and let the seed job create the new jobs. Make sure that the seed job removes nonmanaged jobs. Then you can easily scale with feature branches over different maven projects.

But as tom said well above, it would be nicer to overcome the necessity of feature branches and teach devs to integrate cleanly, but that is a longer process and the outcome is not clear with many legacy system parts you won't touch any more.

my 2 cents

참고URL : https://stackoverflow.com/questions/5611365/handling-multiple-branches-in-continuous-integration