어떤 Continuous Integration 프레임 워크를 사용합니까? 그 이유는 무엇입니까? [닫은]

몇 가지 다른 CI (Continuous Integration) 프레임 워크가 있으며 가장 인기있는 것이 궁금합니다. 근무하는 회사에서 어떤 프레임 워크를 사용해 보셨습니까?

한 CI 프레임 워크가 다른 CI 프레임 워크보다 더 인기가있는 이유가 있습니까? 아마도 이것이 제공하는 기능, 통합 된 기능 또는 마케팅과 관련이있을 수 있습니까?

루비 또는 파이썬보다 Java 및 .net 세계에서 지속적인 통합이 더 많이 사용되는 것 같습니다. 왜 이런거야?

Hudson 또는 Jenkins (후자는 전자의 포크). 이유 : 간단하고 (설치 및 사용이 간단 함) 유연성이 뛰어납니다. 플러그인은 내가 생각할 수있는 거의 모든 기능을 추가합니다.

몇 년 전에 나는 damagecontrol을 사용 했다 . 사용하기도 쉽지만 플러그인은 없었습니다. 그러나 저자는 간단한 솔루션을 포기하고 서로 통신하는 서로 다른 서버로 구성된 새로운 버전의 개발을 시작하기로 결정했습니다. 그것은 잘 작동하지 않았고 프로젝트는 포기되었습니다. 나는 얼마 동안 수색을하고 있었지만 cruisecontrol (너무 복잡한)이나 연속체가 실제로 나를 얻지 못했습니다. 허드슨까지, 그것은 첫 순간부터 저를 위해 일했습니다.

나는 직장과 가정에서 TeamCity 를 사용 합니다. 다양한 빌드 러너를 강력하게 지원하며 플러그인을 통해 확장 할 수 있습니다.

구성을 위해 XML을 다루지 않는 것은 저의 책에 큰 도움이되며 무료 버전은 가정의 요구에 충분합니다.

TeamCity에서 겪은 한 가지 문제는 자동으로 .NET 어셈블리 버전을 얻는 것과 관련이 있습니다. 비교적 복잡한 해결 방법을 설정해야했지만 일단 설치되면 매력처럼 작동했습니다.

개인적으로 CruiseControl과 CruiseControl.Net 만 사용했습니다. 그 이유는 경제와 관련이 있습니다. 그것들은 합리적으로 안정적이며 일단 설정하면 유지하기 위해 할 일이 거의 없습니다. 사용자 커뮤니티는 일반적으로 매우 유용하며 필요에 따라 확장 될 수 있습니다.

즉, 더 나은 설정 경험과 상업적 지원을 제공하는 몇 가지 상용 제품이 있습니다 (하나는 JetBrains, 다른 하나는 Atlassian). 나는 이러한 제안을 시도하는 것을 의미했지만 실제로 아직 기회가 없었습니다.

CI 도구는 해석 된 언어보다 컴파일 된 언어로 재생하는 데 더 중요한 역할을 수행하지만 CI 도구가 해석 된 언어에서 낭비되는 것은 아닙니다. 서로 의존하는 여러 프로젝트가 있고 변경으로 인해 실수로 변경이 종속성을 손상시키지 않도록하려면 CI 도구가 매우 중요합니다.

CI 도구를 사용하면 다음과 같은 세 가지 일반적인 문제 유형을 파악할 수 있습니다.

1. 컴파일 오류-클래스의 서명이 종속성을 깨뜨리는 방식으로 변경되는 경우 제공 시간이 끝나기 전에 클래스에 대해 아는 것이 가장 좋습니다.
2. 논리 오류-클래스의 동작이 종속성을 손상시키는 방식으로 변경되면 조기에 파악하는 것이 가장 좋습니다. 이것은 일종의 자동 테스트, 가장 일반적으로 단위 테스트로 확인해야합니다.
3. 승인 테스트-완성 된 제품에서 실행할 자동화 된 테스트 제품군이있는 경우 자주 실행하는 것이 가장 좋습니다.

해석 된 언어는 컴파일되지 않으므로 포착 할 컴파일 오류가 없습니다. 그러나 다른 두 가지 문제는 CI 도구가 Ruby / Python / Perl / etc의 프로젝트에 유용 할 정도로 충분히 일반적입니다.

논리 오류와 합격 테스트 포인트의 핵심은 "자동화 된"테스트입니다. 기계가 실행할 수있는 일련의 테스트가 없다면 CI 도구의 더 큰 이점이 실제로 없습니다. 자동화 된 제품군은 시간이 지남에 따라 구축 될 수 있으므로 소규모로 시작할 수 있습니다.

편집하다

많은 수의 CI 도구 (주로 몰랐던)의 기능 비교에 대해서는이 멋진 차트를 참조하십시오.

http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix

팀 파운데이션 서버

견고한 CI, Visual Studio와의 긴밀한 통합 및 버전 제어로 Git . 허드슨처럼 더 유연한 CI 서버를 보았지만 다른 제품과의 TFS의 긴밀한 통합은 경험이 너무 매끄 럽기 때문에 팀에 적합합니다.

CruiseControl.NET 과 Hudson을 모두 사용합니다 . 내 빌드 중 일부는 그들 중 하나에 있고 일부는 다른 것입니다.

왜? 저는 빌드 엔지니어가 아니기 때문에 빌드 엔지니어 인 사람이 이런 식으로 설정했습니다!

빌드가 설정되는 방식이나 두 제품에 대한 불만이 없습니다. 나는 당신이 물건이 여기에있는 방식으로 당신에게보고하고 있으며, 당신 이이 관점에 감사하기를 바랍니다!

업데이트 : 대답을 게시 한 후 Hudson은 갈래 났고 Jenkins 가되었습니다 . 위의 권장 사항은 Jenkins에 적용됩니다.

맥박 . 기본적으로 Just Works는 바쁜 빌드 엔지니어에게는 큰 문제입니다. 또한 기술 지원도 뛰어납니다. 내가 너무 좋아하는 주된 이유는 250 개가 넘는 프로젝트가 있고 딸꾹질없이 프로젝트를 처리하기 때문입니다. 허드슨에 대해서도 같은 말을 할 수 없습니다.

우리 팀은 주로 Python, C ++ 및 Java에서 일합니다. CI에는 Buildbot을 사용합니다. 처음에는 Trac과 통합되어 있고 단순하고 간단 해 보였기 때문에 시작했습니다. 나는 그것이 파이썬 세계에서 선택되는 CI 프레임 워크라고 믿는다.

허드슨 강. 때때로 약간의 버그가 있으며, 더 흥미로운 플러그인 중 일부는 실제로 작동하지 않지만 약간의 손 잡음으로 꽤 유용합니다.

필자는 대신 Pulse를 사용하지만 여러 플랫폼에서 빌드 해야하는 경우 $ 5k 이상입니다.

지속적인 통합을위한 CruiseControl.NET CruiseControl에서 많은 수의 빌드 프로젝트를 설정했지만 CCTray 데스크탑 트레이 앱은 긴 새로 고침 간격으로도 응답하지 않습니다.

NAnt 는 CruiseControl 프로젝트에서 실행되는 빌드 스크립트를위한 것입니다. 보다 복잡한 빌드 스크립트를 위해 NAnt를 사용자 정의 C # NAnt 태스크로 확장했습니다. 이는 매우 훌륭합니다. C #으로 코드를 작성하는 것이 NAnt 스크립트를 작성하는 것보다 훨씬 즐겁습니다.

우리는 Microsoft 샵이며 Team Foundation Server 환경을 2010으로 마이그레이션하면 이론적으로 Microsoft의 Team Build 2010으로 전환됩니다.

CI 엔진이 실행 중인지 여부에 관계없이 명령 줄에서 응용 프로그램을 빌드 할 수 있어야합니다.

이는 모든 CI 엔진이 빌드 호출을 체계화하는 것이므로 특정 요구에 가장 적합한 엔진을 선택할 수 있음을 의미합니다.

개인적으로 나는 허드슨을 좋아합니다. "느낌"이 좋기 때문에 , 모든 것이 실패하면 너무 많은 노력없이 다른 것으로 바꿀 수 있다는 것을 압니다. 그렇다면, 나는 그들이 만든 다른 프로그램 의 "느낌" 을 좋아하기 때문에 아마도 Atlassian이 만든 것을 먼저 조사 할 것입니다.

상호 교환 성은 어떤 언어로 작성되었는지는 중요하지 않다는 것을 의미합니다. 많은 플랫폼이 지원되고 쉽게 사용할 수있는 많은 빌딩 블록과 함께 지원되기 때문에 많은 엔진에 Java가 선택되었다고 생각합니다. 웹 서버가 필요합니다. 많은 동시 스레드가 필요합니다. 사용하십시오. 확장 성이 필요합니다-항아리에 떨어 뜨립니다.

"연속 통합"(2002 년 또는 2003 년에 다시 시작)이라는 용어를 듣기 전에 cvs에 연결된 야간 빌드 스크립트를 작성하고 주요 프로젝트와 5 개의 작은 하위 프로젝트를 정리하여 ant를 통한 jar은 tomcat ant 태스크를 사용한 두 번째 ant 스크립트를 통해 WAR 파일을 빌드하고 재배치했습니다.

오후 7시에 cron을 통해 실행되었으며 많은 첨부 파일이 첨부 된 이메일을 보냈습니다. 프로젝트의 전체 7 개월 동안 사용했으며 향후 20 개월 동안 유지 관리 및 개선 작업을 계속했습니다.

잘 작동했지만 여전히 bash 스크립트, cron 및 ant보다 hudson을 선호합니다.