아 귀찮아. Visual Studio 2003 및 Cruise Control.NET. 단순하고 우아합니다. 솔루션을 구축하기 위한 기본 NAnt 스크립트만 있으면 됩니다. NUnit을 실행하면 CC와 Bob의 삼촌이 이해할 수 있는 형식으로 출력됩니다. 이것을 정량화하겠습니다. 우리 Cruise 서버에는 Subversion 클라이언트(명령줄)와 .NET 1.1 SDK가 있습니다. Visual Studio는 서버이고 Cruise에는 시스템을 구축하는 데 필요한 것이 있기 때문에 설치되지 않습니다.
Visual Studio 2005를 시작합니다. 최근에 2005 프로젝트에 대한 CI를 설정했지만 여러 면에서 정말 보기 흉했습니다. 먼저 MSBuild를 사용하여 시스템을 구축하려고 했습니다.
msbuild /t:rebuild Solutionname.sln
(또는 디버그나 릴리스 등 원하는 대상)
을 간단히 입력할 수 있기 때문에 괜찮았습니다
. 제가 말했듯이 그게 전부라면 문제는 없었지만 정말 빨리 추악해졌습니다.
먼저 VSTS 단위 테스트 프로젝트가 있습니다. 팀은 모두 Visual Studio Team Suite를 갖추고 있습니다. 비용이 많이 드는 제안이지만 오래 전에 나보다 현명한 누군가가 제안한 것입니다. 그래도 문제 없습니다. 실제로 테스트 관리자를 많이 사용하지 않고 자동화된 웹 테스트도 없으므로 단위 테스트만 작성합니다(그리고 Jamie Cansdale의 뛰어난 TestDriven.NET을 사용하여 실행합니다). 그러나 MSBuild가 VS 단위 테스트 프로젝트가 포함된 솔루션을 확보하면 추가 어셈블리 세트(GAC_MSIL 및 기타 위치에 묻혀 있는 어셈블리)가 필요합니다. MSBuild를 실행하기 위한 ccnet.config 파일의 코드 조각은 매우 간단합니다.
<실행 가능>C:WINDOWSMicrosoft.NETFrameworkv2.0.50727MSBuild.exe
무차별 대입(MSBuild 실행, 필요한 어셈블리 파악, 가서 찾아 거품내기, 헹구기, 반복)을 통해 컴파일할 2005 솔루션(단위 테스트 프로젝트 포함)을 얻을 수 있었습니다. 그러나 실제로 테스트를 실행하는 것은 또 다른 이야기입니다. 수백 개의 단위 테스트를 실행하기 위해 MSTest.exe를 실행하는 데 한두 시간을 걸었을 때 여기서도 무차별 대입이 최고였습니다. 일부 단위 테스트를 위한 cc.config 항목은 다음과 같습니다:
<실행 파일>C:Program FilesMicrosoft Visual Studio 8Common7IDEMSTest.exe
이 서버에는 Visual Studio가 설치되어 있지 않다고 말한 것을 기억하십시오. VS2005 솔루션의 경우 방금 .NET SDK 2.0을 설치했는데 그것만으로도 충분했습니다. MSTest.exe는 포함되어 있지 않지만 다른 시스템에서 파일(그리고 하드 드라이브 전체에 흩어져 있는 미친 추가 DLL 세트)을 가져와서 EXE가 있던 곳에 붙여 두었으므로 만족할 것입니다.
단위 테스트 프로젝트에 대해 MSTest를 실행할 때 주사위가 없습니다. 테스트 실행 경로를 시작했지만 미친 COM 오류(CLSID가 등록되지 않음)가 발생했고 그것만으로도 충분했습니다. 절대 Visual Studio 2005의 어리석은 COM 레지스트리 설정을 모두 추적할 생각은 없습니다. 그리고 이것은 도대체 무엇이었습니까? COM? 내 생각에는 우리가 약 3개의 컴파일러 전에 그것을 제거했다고 생각했습니까?
그래서 저는 서버에 전체 Team Suite를 설치하는 데 어려움을 겪었습니다. 알았어, 물어볼게. 즉, 모든 것이 필요하지 않으므로 괜찮을 것입니다. 백만 개의 레지스트리 항목이 채워지는 것을 보면서 계속 스스로에게 중얼거립니다. 몇 시간 후 다시 명령 프롬프트를 바라보고 MSTest.exe 명령을 입력합니다. 그리고 대화 상자가 나타납니다. 예, 뭔가 잘못되었음을 알려주는 모달 대화 상자입니다(자세한 내용은 기억나지 않지만 그다지 유익하지 않았습니다).
Visual Studio가 제대로 설치되었고 원하는 솔루션을 컴파일하고 실행하고 빌드할 수 있었지만 MSTest.exe를 사용하여 명령줄에서 테스트하는 것은 전혀 불가능했습니다. 아무리 노력해도, 아무리 청소를 해도, 얼마나 많은 처녀를 희생해도 소용없어요. 그리고 또 다른 문제가 있습니다. 2003년과 NUnit 테스트를 통해 우리는 좋은 통계를 얻었습니다. 타이밍, 유익한 메시지, 그 모든 좋은 것들. MSTest를 사용하면 아무것도 얻을 수 없습니다(x개의 테스트가 실행되고 실패할 수도 있지만 실패에 대한 세부 정보를 제공하는지 확인할 수는 없었습니다). 게다가 MSBuild 로거는 그다지 유용하지 않은 약 10,000줄의 gobbly-gook을 물어서 생성합니다. 예, 새 xslt를 작성하여 예쁘게 만들고 MSBuild 작업 로거를 채우는 "모든 것이 정상이었습니다" 줄을 잘라내는 데 시간을 할애할 수 있지만 제 생각에는 그게 부가가치가 없다고 생각합니다.
다음은 CC.NET/MSBuild/MSTest 콤보가 얼마나 쓸모없는지 알려주는 빌드에서 받은 샘플 이메일입니다.
BUILD SUCCESSFUL
프로젝트: PROJECTNAME
빌드 날짜: 2006년 12월 8일 오전 8:08:30
실행 시간: 00:00:55
통합 요청: IntervalTrigger가 빌드(ForceBuild)를 트리거했습니다.
오류 (1)
D:ccnetprojectsPROJECTNAMESourceReportsServerReportsServerReports.rptproj (2,1): 오류 MSB4041: 프로젝트의 기본 XML 네임스페이스는 MSBuild XML 네임스페이스여야 합니다. 프로젝트가 MSBuild 2003 형식으로 작성된 경우 <Project& gt ; 요소. 프로젝트가 이전 1.0 또는 1.2 형식으로 작성된 경우 MSBuild 2003 형식으로 변환하십시오.
경고(1)
SourceReportsServerReportsServerReports.rptproj (,): 경고 MSB4122: "SourceReportsServerReportsServerReports.rptproj" 프로젝트에 대한 프로젝트 종속성을 검색하지 못했습니다. 프로젝트의 기본 XML 네임스페이스는 MSBuild XML 네임스페이스여야 합니다. 프로젝트가 MSBuild 2003 형식으로 작성된 경우 <Project& gt ; 요소. 프로젝트가 이전 1.0 또는 1.2 형식으로 작성된 경우 MSBuild 2003 형식으로 변환하십시오. D:ccnetprojectsBRMSSourceReportsServerReportsServerReports.rptproj
테스트 실행: 0, 실패: 0, 실행되지 않음: 0, 시간: 0초
테스트 실행 없음
이 프로젝트에는 테스트가 없습니다.
마지막 빌드 이후 수정 사항 (0)
추악하다. 정말 못생긴. MSBuild는 엄청나게 많은 출력을 생성합니다. 새 MSBuild 파일을 작성하는 것은 쉬운 일이 아니며 나처럼 NAnt를 잘 아는 사람이라도 MSBuild가 작업을 수행하는 방식에 대해 여전히 고민하고 있습니다. MSBuild가 보고서 프로젝트를 빌드할 수 없기 때문에 보고서 프로젝트를 생략하기 위해 Visual Studio 내에서 특수 구성을 만들어야 했습니다. 따라서 위의 대상 AutomatedBuild는 개발자가 사용하는 구성과 동일하지 않고 제가 좋아하지 않는 구성이기 때문입니다. CI 서버의 포인트, 모든 사람을 위한 일관된 빌드).
위 출력에서 Cruise는 빌드가 괜찮았지만 MSBuild 로거(보고서 프로젝트)에서 나온 오류 메시지가 있다고 말했습니다. 이것은 2005년 프로젝트이므로 정보가 의미가 없습니다(기록된 버그라고 생각하지만 언제 수정될지는 누가 알겠습니까). 그리고 MSTest 출력을 이메일에 통합할 수 없습니다. 왜냐하면 MSTest 출력이 없기 때문입니다. 이 프로젝트에는 100개 정도의 테스트가 있지만 로거는 아무것도 생성하지 않습니다.
또한 MSBuild가 처리할 수 없는 일부 프로젝트 유형이 있으며, 또 다른 MSBuild 작업을 호출하고 특정 프로젝트를 제외할 수 있는 MSBuild 파일을 생성하려면(MSBuild Sidekick과 같은 멋진 파일을 사용하더라도) 로켓 과학자가 필요합니다. 이는 방금 제외 목록을 생성했던 2003년만큼 쉽지는 않습니다(그리드 컨트롤에 대한 추가 라이센스가 없었고 평가판을 볼 때 모달 대화 상자가 나타났기 때문에 클라이언트 앱을 제외했습니다). 컴파일러).
좋아요, 이것은 대부분 호언장담이지만 여기에는 약간의 지혜가 있습니다. 지속적인 통합이 이렇게 어려울 필요는 없습니다. CruiseControl.NET은 뛰어난 도구이며 새로운 도구를 사용하고 해당 도구의 출력을 통합하는 데 매우 유연합니다. 그러나 해당 도구에 백만 개의 레지스트리 설정과 훨씬 더 많은 DLL이 필요한 경우(매우 특정한 위치에 배치하고 저를 믿으세요. GAC에 던져두고 하루라고 부를 수는 없습니다) 단순한 치명적이지 않은 XML 덩어리를 덤프합니다(글쎄 아마도 DonXml이 번역할 수 있을 것입니다. 그것은 단지 잘못된 것입니다. 그리고 우리가 할 수 있는 내장된 팀 빌드에 관해서는 a) 코드 체크인에서 트리거되도록 빌드를 예약할 수 없으며 b) 다시 서버에 전체 Team Suite 클라이언트를 설치해야 하는 것과 마찬가지로 쓸모가 없습니다. . 최악의 경우 처음 CC.NET 서버 설정을 시작했을 때 4시간이 걸렸습니다. 이제 한 시간 안에 완료할 수 있습니다(첫 번째 프로젝트의 빌드 테스트 포함). 나는 이미 컴파일할 무언가를 얻으려고 노력하며 즐거운 하루를 보냈습니다. 지금은 컴파일 중이지만 출력이 엉망이고 테스트도 실행되지 않아 나에게는 충분하지 않습니다. CruiseControl.NET을 사용하여 MSBuild 및 MSTest를 실행할 수 있습니다. 불가능하지 않습니다. 전체 클라이언트를 설치하고 프로젝트가 "딱 맞으면" 작동하지만 출력은 그렇게 뜨겁지 않으며 컴파일이 발생할 때 서버 CPU 슬램을 보게 됩니다.
내 조언은 MSBuild, MSTest 및 CruiseControl을 결합하지 말고 NAnt 및 NUnit(2005 솔루션을 구축할 때 필요한 경우 MSBuild 사용)을 고수하라는 것입니다.
말할 필요도 없이 지금은 하나의 옵션을 보고 있습니다. 서버에 VS2005 설치를 덤프하고 모든 단위 테스트를 다시 NUnit으로 변경하고 NAnt를 사용하여 모든 작업을 수행합니다(그리고 VS2005 프로젝트의 실행 작업으로 MSBuild를 호출합니다). 여전히 2003년 프로젝트를 실행해야 하므로 작업이 완료될 때쯤에는 CI 서버가 프랑켄슈타인 괴물처럼 보일 것입니다. VS2003 및 VS2005 프로젝트를 빌드하고 NUnit, MSBuild, NAnt, Simian, FxCop 및 우리 회사에 있는 모든 것을 실행합니다. 혼합. 그럼에도 불구하고 NAnt를 사용하면 출력이 더 간단해지고(CC.NET과 잘 통합됨) 테스트 출력이 유용하고 유익할 것이며 뚜렷한 가능성이 있는 서버에 15,000달러짜리 소프트웨어를 설치할 필요가 없습니다. 언젠가 일부 레지스트리 키를 찾을 수 없을 때 모달 대화 상자를 팝업하는 것입니다.
으르렁. 아아.