C ++ 연속 통합을위한 buildbot 대 hudson / jenkins
저는 현재 주로 C ++ 프로젝트의 지속적인 통합을 위해 jenkins / hudson을 사용하고 있습니다. 트렁크와 모든 지점에 대해 별도의 프로젝트가 있습니다. 또한 Java 코드와 관련된 몇 가지 프로젝트가 있지만 그 설정은 현재 매우 기본적입니다 (나중에 더 많은 작업을 수행 할 수 있음). C ++ 프로젝트는 다음을 수행합니다.
- 재구성, 클린 빌드 또는 새로운 체크 아웃 사용 여부에 대한 옵션으로 모든 것을 빌드합니다.
- 선택적으로 모든 테스트를 빌드하고 실행합니다.
- 선택적으로 Valgrind의 memcheck를 사용하여 모든 테스트를 실행합니다.
- cppcheck를 실행합니다.
- doxygen 문서 생성
- 보고서 게시 : 단위 테스트, valgrind, cppcheck, 컴파일러 경고, SLOC, 개방형 작업 및 코드 검사 (gcov, gcovr 및 cobertura 플러그인 사용)
- 야간 또는 요청시 테스트 환경 및 패키지 저장소에 코드 배포
모든 것은 자동 빌드를 위해 구성 가능하고 주문형 빌드를 위해 선택 사항입니다. 그 아래에는 많은 부분을 제어하는 bash 스크립트가 있으며, 이는 사용자 지정 bash 스크립트와 함께 automake 및 autoconf를 사용하는 빌드 시스템에 더 많이 의존합니다.
우리는 Hudson (당시)을 사용하기 시작했습니다. 그 이유는 Java 사람들이 사용하고 있었기 때문에 야간 빌드를 원했기 때문입니다. 그 이후로 우리는 더 많은 것을 추가했고 계속해서 더 추가했습니다. 어떤면에서 Hudson은 훌륭하지만 확실히 이상적이지 않습니다.
다른 솔루션을 살펴 봤는데 이것이 대체 될 수있는 유일한 솔루션은 buildbot입니다. 이 상황에 buildbot이 더 좋을까요? 이미 Hudson을 사용하고 있기 때문에 투자 가치가 있습니까? 왜?
편집 : 누군가 내가 왜 Hudson / Jenkins가 이상적이지 않은지 물었습니다. 짧은 대답은 모든 것이 개선 될 수 있다는 것입니다. Jenkins가 내 사용 사례에 가장 적합한 현재 솔루션인지 또는 새로운 요구 사항이 발생하더라도 장기적으로 유지하기 쉬운 더 나은 것이 있는지 (buildbot?) 궁금합니다.
둘 다 오픈 소스 프로젝트이지만 "확장"하기 위해 빌드 봇 코드를 변경할 필요는 없습니다. 실제로 추가 된 기능으로 대부분의 기능을 하위 클래스화할 수있는 구성에서 자신의 패키지를 가져 오는 것은 매우 쉽습니다. 예 : 자체 컴파일 또는 테스트 코드, 다음 단계에 제공 할 출력 / 오류의 일부 구문 분석, 경고 이메일의 자체 형식 등 많은 가능성이 있습니다.
일반적으로 buildbot이 가장 "일반적인 용도"의 자동 빌드 도구라고 말하고 싶습니다. 그러나 Jenkins는 테스트 실행과 가장 관련이있을 수 있습니다. 특히 결과를 구문 분석하고 결과를 좋은 방식 (결과, 세부 정보, 차트 .. 몇 번의 클릭으로 표시)으로 표시 할 때 buildbot이 "즉시"수행하지 않는 작업을 수행 할 수 있습니다. 나는 실제로 둘 다 사용하여 더 섹시한 테스트 결과 페이지를 만들려고합니다 .. :-)
또한 경험상 새 도구의 구성을 만드는 것이 어렵지 않아야합니다. 수행 할 작업 (구성, 빌드, 테스트)의 사양이 한 도구에서 다른 도구로 전환하기 너무 어렵다면 (나쁜) 신호입니다. 충분하지 않은 구성 스크립트가 소스로 이동되었습니다. Buildbot (또는 Jenkins)은 간단한 명령 만 호출해야합니다. 테스트를 실행하는 것이 간단하면 개발자도이를 수행하여 성공률을 높일 수있는 반면, 지속적 통합 시스템 만 테스트를 실행하는 경우 새로운 코드 오류를 수정하기 위해 실행하고 느슨해집니다. 비 회귀 값, 내 0.02 € :-)
도움이되기를 바랍니다.
'결과 통합'도 jenkins / hudson에 있으며 '다른 곳에 복사'하지 않고도 빌드 제품을 비교적 쉽게 캡처 할 수 있습니다.
예를 들어 커버리지 보고서와 단위 테스트 메트릭 및 Java 코드에 대한 javadoc이 모두 통합되었습니다. C ++ 코드의 경우 플러그인이 약간 부족하지만 여전히 대부분을 얻을 수 있습니다.
우리는 0.7 이전부터 buildbot을 실행했으며 현재 0.8을 실행 중이며 buildbot 0.8이 오랜 기간 동안 Windows 슬레이브를 잊어 버렸고 지원이 매우 열악했기 때문에 전환해야 할 실제 이유가 있습니다.
Jenkins / Hudson / BuildBot 외에도 많은 다른 솔루션이 있습니다.
- Jetbrains의 TeamCity
- Atlassian의 Bamboo
- Thoughtworks로 이동
- 크루즈 컨트롤
- OpenMake 마이스터
실제로 수행중인 에이전트 (일명 노드)가 해당 작업을 지원하는 한 수행중인 작업에 대한 세부 사항은 그다지 중요하지 않습니다.
CI 서버의 장점은 새 빌드 (및 테스트)를 트리거하고 아티팩트를 게시하고 테스트 결과를 게시하기 위해 빌드가 변경 될 때이를 인식하는 것입니다.
앞서 언급 한 것과 같은 CI 도구를 비교할 때 인터페이스의 유용성, 분기가 얼마나 쉬운 지 (및 자동 병합과 같은 기능을 제공 할 수 있음), 알림 (XMPP / jabber와 같은) 또는 정보 방사기 (후킹과 같은)와 같은 기능을 고려하십시오. 항상 상태를 표시하려면 모니터를 켜십시오.) 제품 지원은 고려해야 할 또 다른 사항입니다. Jenkins의 지원은 질문이있는 시점에 커뮤니티 질문에 응답하는 사람만큼만 우수합니다.
개인적으로 가장 좋아하는 것은 Bamboo이지만 라이센스 비용이 있습니다.
저는 오랫동안 Buildbot을 평가하는 Jenkins 사용자이며 다중 모듈 솔루션에 Buildbot 사용을 고려중인 사람들에게 몇 가지 항목을 제공하고 싶습니다.
*) Buildbot에는 artifacts각 빌드와 관련된 파일의 기본 개념이 없습니다 . UI에없고 내가 볼 수있는 한 기본 제공 "단계"모듈에도 없습니다.
http://docs.buildbot.net/current/manual/configuration/buildsteps.html
... 제 3 자 플러그인이 보이지 않습니다.
https://github.com/buildbot/buildbot/wiki/PluginList#steps
Buildbot은 특정 빌드에서 모든 콘솔 출력을 수집하지만 중요한 것은 관련 파일을 수집 할 수 없다는 것입니다.
*) 아티팩트가 지원되지 않는다는 점을 감안할 때 여러 모듈을 단일 설치 프로그램으로 가져 오는 "수집기"프로젝트를 만드는 것은 쉽지 않습니다. Jenkins에는 다른 모듈의 빌드로 빌드를 매개 변수화 할 수있는 훌륭한 기능이 있습니다 (매개 변수 유형은 run).
*) Buildbot에서는 모듈간에 종속성을 설정하는 것이 더 까다 롭습니다. 3 개의 바이너리가 의존하는 라이브러리가 있고 라이브러리가 변경 될 때마다 바이너리가 다시 빌드되기를 원한다고 가정 해 보겠습니다. Jenkins는 triggersUI에 내장되었습니다. Buildbot에서 트리거를 수행하려면을 사용하여 스크립트를 작성해야 schedulers.Dependent하며 이로 인해 SchedulersUI 에서 많은 항목 정체가 발생합니다 .
*) Buildbot에서 작업 할 때 거의 모든 구성이 master.cfg코드 로 수행되는 것 같습니다 . 이것은 굉장하고 실망 스럽습니다.
*) Buildbot은 서버 worker에 추가로 생성 하도록 master합니다. 이것은 단일 빌드 서버로 충분한 초보자와 시스템에게는 성가신 일입니다.
My impression after two days of Buildbot evaluation is that we'll stick with Jenkins, primarily due to it having artifacts. Buildbot is a tool we'd only use if we had more extensive customization needs, and the time to do it.
On the subject of buildbot and artifacts -- I don't have enough user score to make a comment -- you can get artifacts from buildbot 2.x series pretty easy with built-in file/directory upload actions. However you rarely want to just move files. Typically you make a triggered buildstep that does deployment directly off the worker for best results. eg push to cloud storage, containers, thirdparty (steam uploads), etc.
This way you can get metrics on the uploads and conditionally control them better (or even mix and match artifacts across worker machines).
참고URL : https://stackoverflow.com/questions/5653372/buildbot-vs-hudson-jenkins-for-c-continuous-integration
'Programing' 카테고리의 다른 글
| 자바 REST 구현 : Jersey 대 CXF (0) | 2020.10.20 |
|---|---|
| 커밋없이 Github의 한 줄에 댓글을 달았나요? (0) | 2020.10.20 |
| Golang : 텍스트 파일을 읽는 방법? (0) | 2020.10.20 |
| 열거 형 사용 및 유지를위한 모범 사례 (0) | 2020.10.20 |
| Git : 저장소에서 자동 가져 오기? (0) | 2020.10.20 |