โอ้รบกวน Visual Studio 2003 และ Cruise Control.NET เรียบง่ายและสง่างาม สคริปต์ Nant พื้นฐานสำหรับสร้างโซลูชัน เท่านี้คุณก็พร้อมใช้งานแล้ว เรียกใช้ NUnit เอาต์พุตไปที่รูปแบบ CC ที่เข้าใจได้และเป็นลุงของ Bob ขอผมหาปริมาณอันนี้หน่อย เซิร์ฟเวอร์ล่องเรือของเรามีไคลเอนต์โค่นล้ม (บรรทัดคำสั่ง) และ .NET 1.1 SDK ไม่ได้ติดตั้ง Visual Studio เพราะมันเป็นเซิร์ฟเวอร์และการล่องเรือเพียงต้องการบางสิ่งเพื่อสร้างระบบด้วย
เข้าสู่ Visual Studio 2005 ฉันเพิ่งติดตั้ง CI สำหรับโครงการปี 2005 ของเรา แต่มันก็ดูน่าเกลียดในหลายๆ ด้าน ก่อนอื่นมีการพยายามให้ระบบสร้างโดยใช้ MSBuild ไม่เป็นไรเพราะคุณสามารถป้อนสิ่งนี้:
msbuild /t:rebuild solutionname.sln
(หรือเป้าหมายใดๆ ที่คุณต้องการ เช่น Debug หรือ Release)
อย่างที่ฉันบอกไว้ ถ้าแค่นั้นก็ไม่มีปัญหา แต่มันน่าเกลียดจริงๆ อย่างรวดเร็ว
อย่างแรกคือโครงการทดสอบหน่วย VSTS ทีมงานทุกคนมี Visual Studio Team Suite ข้อเสนอราคาแพง แต่มีคนทำไว้เมื่อนานมาแล้วโดยคนที่ฉลาดกว่าฉัน แต่ไม่มีปัญหา เราไม่ได้ใช้ Test Manager มากนัก ไม่มีการทดสอบเว็บอัตโนมัติ ดังนั้นเราจึงแค่เขียนการทดสอบหน่วย (และรันด้วย TestDriven.NET ที่ยอดเยี่ยมของ Jamie Cansdales) อย่างไรก็ตาม เมื่อ MSBuild ได้รับโซลูชันที่มีโครงการทดสอบหน่วย VS ก็จำเป็นต้องมีชุดแอสเซมบลีเพิ่มเติม (แอสเซมบลีที่ฝังอยู่ใน GAC_MSIL และที่อื่น ๆ ) ตัวอย่างข้อมูลในไฟล์ ccnet.config เพื่อให้ MSBuild ดำเนินต่อไปนั้นค่อนข้างตรงไปตรงมา:
<msbuild>
<ปฏิบัติการ>C:WINDOWSMicrosoft.NETFrameworkv2.0.50727MSBuild.exe</ปฏิบัติการ>
<workingDirectory>D:ccnetprojectsProjectName</workingDirectory>
<projectFile>SolutionName.sln</projectFile>
<buildArgs>/noconsolelogger /p:Configuration=AutomatedBuild /v:diag</buildArgs>
<เป้าหมาย>สร้าง</เป้าหมาย>
<หมดเวลา>600</หมดเวลา>
<logger>C:Program FilesCruiseControl.NETserverThoughtWorks.CruiseControl.MsBuild.dll</ logger>
</msbuild>
ด้วยกำลังดุร้าย (เรียกใช้ MSBuild ค้นหาว่าต้องการชุดประกอบใด ไปหามัน ฟอก ล้าง ทำซ้ำ) ฉันสามารถรับโซลูชันปี 2005 (พร้อมโปรเจ็กต์การทดสอบหน่วย) เพื่อคอมไพล์ อย่างไรก็ตาม การทำการทดสอบจริงๆ เป็นอีกเรื่องหนึ่ง อีกครั้งที่กองกำลังเดรัจฉานครองตำแหน่งสูงสุดที่นี่ ขณะที่ฉันเหยียบย่ำชั่วโมงหรือสองชั่วโมงในการรัน MSTest.exe เพื่อพยายามเกลี้ยกล่อมการทดสอบสองสามร้อยหน่วยให้ทำงาน รายการ cc.config สำหรับการรับการทดสอบหน่วยบางอย่างมีลักษณะดังนี้:
<exec>
<ปฏิบัติการ>C:Program FilesMicrosoft Visual Studio 8Common7IDEMSTest.exe</ ปฏิบัติการ>
<baseDirectory>d:ccnetprojectsProjectName</baseDirectory>
< buildArgs > /testcontainer:SourceTestsUnitTestsbinAutomatedBuildUnitTests.dll /runconfig:localtestrun.Testrunconfig /resultsfile:testResults.trx</buildArgs>
<buildTimeoutSeconds>600</buildTimeoutSeconds>
</exec>
จำไว้ว่าฉันบอกว่าเซิร์ฟเวอร์นี้ไม่ได้ติดตั้ง Visual Studio สำหรับโซลูชัน VS2005 ฉันเพิ่งติดตั้ง .NET SDK 2.0 และนั่นก็เพียงพอแล้ว แม้ว่าจะไม่รวม MSTest.exe แต่ฉันขัดขวางไฟล์ (และเป็นชุด DLL เพิ่มเติมที่กระจัดกระจายไปทั่วฮาร์ดไดรฟ์) จากระบบอื่นและติดไว้ที่ EXE เพื่อที่มันจะมีความสุข
ไม่มีลูกเต๋าในการรัน MSTest กับโครงการทดสอบหน่วย มันเริ่มต้นในเส้นทางของการรันการทดสอบ แต่แล้วเกิดข้อผิดพลาด COM อย่างบ้าคลั่ง (ไม่ได้ลงทะเบียน CLSID) และนั่นก็เพียงพอแล้วสำหรับฉัน ไม่มีทางที่ฉันจะติดตามการตั้งค่ารีจิสทรี COM โง่ ๆ ทั้งหมดสำหรับ Visual Studio 2005 แล้วนี่มันอะไรกัน? คอม? ฉันคิดว่าเรากำจัดคอมไพเลอร์ประมาณ 3 ตัวที่แล้วไปแล้วเหรอ?
ดังนั้นฉันจึงติดอยู่กับการติดตั้ง Team Suite เต็มรูปแบบบนเซิร์ฟเวอร์ โอเค ฉันจะกัด ฉันหมายความว่า ฉันไม่ต้องการทุกอย่าง ดังนั้นมันก็โอเค (ฉันคอยบอกตัวเองในขณะที่ฉันดูรายการรีจิสตรีนับล้านรายการเต็มไปหมด) ไม่กี่ชั่วโมงต่อมา ฉันก็จ้องมองที่พรอมต์คำสั่งของฉันอีกครั้ง และพิมพ์คำสั่ง MSTest.exe ของฉัน และกล่องโต้ตอบจะปรากฏขึ้น ใช่แล้ว กล่องโต้ตอบโมดอลที่บอกฉันว่ามีบางอย่างผิดปกติ (ฉันจำรายละเอียดเฉพาะไม่ได้ แต่ก็ไม่ได้ให้ข้อมูลมากนัก)
Visual Studio ได้รับการติดตั้งอย่างดี และฉันสามารถคอมไพล์ รัน และสร้างโซลูชันที่ฉันพยายามทำ แต่การทดสอบจากบรรทัดคำสั่งด้วย MSTest.exe นั้นทำไม่ได้ ไม่ว่าฉันพยายามแค่ไหน ทำความสะอาดไปมากแค่ไหน หรือเสียสละหญิงพรหมจารีไปกี่คน มันก็ไม่หมด และมีปัญหาอีกอย่างหนึ่ง ในปี 2003 และการทดสอบ NUnit ของเรา เรามีสถิติที่ดี เวลา ข้อความที่ให้ข้อมูล ทุกสิ่งที่ดี ด้วย MSTest เราไม่ได้รับอะไรเลย (นอกเหนือจากการทดสอบจำนวน x ครั้งและอาจล้มเหลว แต่ฉันไปไม่ถึงขนาดนั้นเพื่อดูว่ามันจะให้รายละเอียดของความล้มเหลวหรือไม่) ยิ่งไปกว่านั้น ตัวบันทึก MSBuild ยังกัดและสร้าง gobbly-gook ประมาณ 10,000 บรรทัดซึ่งไม่มีประโยชน์มากนัก ใช่ ฉันสามารถใช้เวลาเขียน xslt ใหม่เพื่อให้ดูสวยงาม ตัดบรรทัด "ทุกอย่างโอเค" ที่เติมลงในตัวบันทึกงาน MSBuild ออก แต่ฉันคิดว่านั่นไม่เพิ่มมูลค่าในอัตราของฉัน
นี่คืออีเมลตัวอย่างที่ฉันได้รับจากบิลด์ซึ่งช่วยให้คุณทราบว่าคอมโบ CC.NET/MSBuild/MSTest นั้นไร้ประโยชน์เพียงใด:
สร้างความสำเร็จ
โครงการ: PROJECTNAME
วันที่สร้าง: 8/12/2549 8:08:30 น
เวลาดำเนินการ: 00:00:55 น
คำขอบูรณาการ: IntervalTrigger ทริกเกอร์บิลด์ (ForceBuild)
ข้อผิดพลาด (1)
D:ccnetprojectsPROJECTNAMESourceReportsServerReportsServerReports.rptproj (2,1): ข้อผิดพลาด MSB4041: เนมสเปซ XML เริ่มต้นของโครงการต้องเป็นเนมสเปซ MSBuild XML หากโครงการนี้เขียนในรูปแบบ MSBuild 2003 โปรดเพิ่ม xmlns=" http://schemas.microsoft.com/developer/msbuild/2003 " ลงใน <Project> องค์ประกอบ. หากโครงการได้รับการเขียนในรูปแบบ 1.0 หรือ 1.2 เก่า โปรดแปลงเป็นรูปแบบ MSBuild 2003
คำเตือน (1)
SourceReportsServerReportsServerReports.rptproj (,): คำเตือน MSB4122: การสแกนการอ้างอิงโครงการสำหรับโครงการ "SourceReportsServerReportsServerReports.rptproj" ล้มเหลว เนมสเปซ XML เริ่มต้นของโครงการจะต้องเป็นเนมสเปซ MSBuild XML หากโครงการนี้เขียนในรูปแบบ MSBuild 2003 โปรดเพิ่ม xmlns=" http://schemas.microsoft.com/developer/msbuild/2003 " ลงใน <Project> องค์ประกอบ. หากโครงการได้รับการเขียนในรูปแบบ 1.0 หรือ 1.2 เก่า โปรดแปลงเป็นรูปแบบ MSBuild 2003 D:ccnetprojectsBRMSSourceReportsServerReportsServerReports.rptproj
การทดสอบทำงาน: 0, ความล้มเหลว: 0, ไม่ทำงาน: 0, เวลา: 0 วินาที
ไม่มีการทดสอบรัน
โปรเจ็กต์นี้ไม่มีการทดสอบใดๆ
การแก้ไขตั้งแต่การสร้างครั้งล่าสุด (0)
มันน่าเกลียด. น่าเกลียดจริงๆ MSBuild สร้างเอาต์พุตที่บ้าคลั่งมากมาย การเขียนไฟล์ MSBuild ใหม่ไม่ใช่การเดินเล่นในสวนสาธารณะ และแม้แต่สำหรับคนอย่างฉันที่รู้จัก NAnt ค่อนข้างดี ฉันยังคงคิดว่า MSBuild ทำงานอย่างไร ฉันต้องสร้างการกำหนดค่าพิเศษภายใน Visual Studio เพื่อละเว้นโครงการรายงานของเราเนื่องจาก MSBuild ไม่สามารถสร้างได้ (ดังนั้นเป้าหมาย AutomatedBuild ด้านบนซึ่งไม่ใช่การกำหนดค่าแบบเดียวกับที่นักพัฒนาของเราใช้และบางสิ่งที่ฉันไม่ชอบทำเพราะเป็นอย่างนั้น ของเซิร์ฟเวอร์ CI ซึ่งเป็นรุ่นที่สอดคล้องกันสำหรับทุกคน)
จากผลลัพธ์ข้างต้น Cruise กล่าวว่างานสร้างนั้นใช้ได้ แต่มีข้อความแสดงข้อผิดพลาดที่ออกมาจากตัวบันทึก MSBuild (โครงการรายงานของเรา) นี่เป็นโปรเจ็กต์ปี 2005 ดังนั้นข้อมูลจึงไม่สมเหตุสมผล (ฉันเชื่อว่ามันเป็นข้อบกพร่องที่บันทึกไว้ แต่ใครจะรู้ว่าเมื่อไรจะได้รับการแก้ไข) และฉันไม่สามารถรวมเอาต์พุต MSTest เข้ากับอีเมลได้จริงๆ เพราะไม่มีเลย มีการทดสอบประมาณร้อยครั้งในโปรเจ็กต์นี้ แต่ตัวบันทึกไม่ได้สร้างอะไรเลย
นอกจากนี้ ยังมีโปรเจ็กต์บางประเภทที่ MSBuild ไม่สามารถจัดการได้ และขอย้ำอีกครั้งว่าต้องใช้นักวิทยาศาสตร์จรวดในการสร้างไฟล์ MSBuild (แม้จะใช้บางอย่างเจ๋งๆ เช่น MSBuild Sidekick) ที่สามารถเรียกงาน MSBuild อื่นและแยกบางโปรเจ็กต์ออกได้ นี่ไม่ใช่เรื่องง่ายเหมือนในปี 2003 ที่คุณเพิ่งสร้างรายการยกเว้น (เรายกเว้นแอปไคลเอ็นต์ของเราเนื่องจากไม่มีใบอนุญาตพิเศษสำหรับการควบคุมกริด และกล่องโต้ตอบโมดอลก็ปรากฏขึ้นเมื่อมีการดูเวอร์ชันทดลองด้วยซ้ำ คอมไพเลอร์)
โอเค นี่เป็นการพูดจาโวยวายเป็นส่วนใหญ่ แต่ก็มีเกร็ดความรู้อยู่บ้าง การบูรณาการอย่างต่อเนื่องไม่จำเป็นต้องยากขนาดนี้ CruiseControl.NET เป็นเครื่องมือที่ยอดเยี่ยมและมีความยืดหยุ่นอย่างมากกับเครื่องมือใหม่ๆ และการรวมเอาเอาท์พุตจากเครื่องมือเหล่านั้น อย่างไรก็ตาม เมื่อเครื่องมือเหล่านั้นต้องการการตั้งค่ารีจิสทรีนับล้านรายการและ DLL มากขึ้น (วางไว้ในสถานที่ที่เฉพาะเจาะจงมาก เชื่อฉันเถอะ คุณไม่สามารถโยนมันลงใน GAC และเรียกมันว่าวันเดียวได้) และถ่ายโอนข้อมูล XML จำนวนมากที่ไม่ใช่แค่มนุษย์ธรรมดา (เช่นกัน บางที DonXml อาจ) สามารถแปลได้มันผิด และสำหรับ Team Build ในตัวที่คุณสามารถทำได้ นั่นก็ไร้ประโยชน์พอ ๆ กันกับ ก) คุณไม่สามารถกำหนดเวลาบิลด์ให้ทริกเกอร์การเช็คอินโค้ดได้ และ b) อีกครั้ง จำเป็นต้องมีการติดตั้งไคลเอนต์ Team Suite แบบเต็มบนเซิร์ฟเวอร์ . สถานการณ์กรณีที่เลวร้ายที่สุดเมื่อฉันเริ่มตั้งค่าเซิร์ฟเวอร์ CC.NET ครั้งแรกนั้นใช้เวลา 4 ชั่วโมง ตอนนี้ฉันสามารถทำให้มันเสร็จภายในหนึ่งชั่วโมง (ซึ่งรวมถึงการทดสอบบิลด์ของโปรเจ็กต์แรกด้วย) ฉันใช้เวลาทั้งวันไปกับการพยายามหาอะไรมารวบรวม ตอนนี้กำลังรวบรวม แต่ผลลัพธ์ออกมาห่วยและไม่มีการทดสอบ และนั่นก็ไม่ดีพอสำหรับฉัน คุณสามารถรับ MSBuild และ (อาจ) MSTest ทำงานด้วย CruiseControl.NET ไม่ใช่เรื่องที่เป็นไปไม่ได้ หากคุณติดตั้งไคลเอนต์ตัวเต็มและโปรเจ็กต์ของคุณ "ถูกต้อง" มันจะใช้งานได้ แต่เอาท์พุตไม่ได้ร้อนขนาดนั้น และคุณจะเห็น CPU เซิร์ฟเวอร์ของคุณกระแทกเมื่อการคอมไพล์เกิดขึ้น
คำแนะนำของฉัน หลีกเลี่ยงการพยายามรวม MSBuild, MSTest และ CruiseControl และยึดติดกับ NAnt และ NUnit (ใช้ MSBuild หากคุณจำเป็นต้องสร้างโซลูชันปี 2005)
ไม่จำเป็นต้องพูดว่าฉันกำลังดูตัวเลือกเดียวตอนนี้ ทิ้งการติดตั้ง VS2005 บนเซิร์ฟเวอร์ เปลี่ยนการทดสอบหน่วยทั้งหมดของเรากลับเป็น NUnit และใช้ NAnt เพื่อทำทุกอย่าง (และเพียงแค่เรียก MSBuild เป็นงานผู้บริหารสำหรับโครงการ VS2005) ฉันยังต้องทำโปรเจ็กต์ในปี 2003 ดังนั้นเซิร์ฟเวอร์ CI ของเราจะดูเหมือนสัตว์ประหลาดแฟรงเกนสไตน์เมื่อถึงเวลาที่ฉันเสร็จ สร้างโปรเจ็กต์ VS2003 และ VS2005 รัน NUnit, MSBuild, Nant, Simian, FxCop และอะไรก็ตามที่เรามีใน ผสม. แม้ว่าการใช้ NAnt ผลลัพธ์จะง่ายกว่า (และรวมเข้ากับ CC.NET ได้ดี) ผลลัพธ์การทดสอบจะมีประโยชน์และให้ข้อมูล และฉันไม่จำเป็นต้องติดตั้งซอฟต์แวร์มูลค่า 15,000 ดอลลาร์บนเซิร์ฟเวอร์ที่มีความเป็นไปได้ที่แตกต่างกัน สักวันหนึ่งป๊อปอัปกล่องโต้ตอบโมดอลเมื่อไม่พบคีย์รีจิสทรี
กร๊าก อ๊าก