Oh mengganggu. Visual Studio 2003 dan Cruise Control.NET. Sederhana dan elegan. Skrip NAnt dasar untuk membangun solusi dan Anda siap melakukannya. Jalankan NUnit, output masuk ke format yang dapat dipahami CC dan paman Bob. Izinkan saya mengukurnya. Server pelayaran kami memiliki klien subversi (baris perintah) dan .NET 1.1 SDK. Visual Studio tidak diinstal karena, ya, ini adalah server dan pelayaran hanya memerlukan sesuatu untuk membangun sistem.
Masuk ke Visual Studio 2005. Saya baru saja menyiapkan CI untuk proyek tahun 2005 kami, tetapi dalam banyak hal jelek sekali. Pertama ada upaya untuk membangun sistem menggunakan MSBuild. Tidak apa-apa karena Anda cukup memasukkan ini:
msbuild /t:rebuild solutionname.sln
(atau target apa pun yang Anda inginkan seperti Debug atau Rilis)
Seperti yang saya katakan, jika hanya itu yang tidak masalah tetapi hasilnya menjadi sangat jelek dengan sangat cepat.
Pertama ada proyek uji unit VSTS. Semua tim dilengkapi dengan Visual Studio Team Suite. Proposisi yang mahal, tapi sudah lama dibuat oleh seseorang yang lebih bijak dariku. Tapi tidak masalah. Kami tidak terlalu banyak menggunakan Test Manager, tidak ada pengujian web otomatis, jadi kami hanya menulis pengujian unit (dan menjalankannya dengan TestDriven.NET yang luar biasa dari Jamie Cansdale). Namun ketika MSBuild mendapatkan solusi yang berisi proyek pengujian unit VS, ia memerlukan beberapa kumpulan rakitan tambahan (rakitan yang terkubur di GAC_MSIL dan tempat lain). Cuplikan dalam file ccnet.config untuk menjalankan MSBuild cukup mudah:
<msbuild>
<dapat dieksekusi>C:WINDOWSMicrosoft.NETFrameworkv2.0.50727MSBuild.exe</executable>
<workingDirectory>D:ccnetprojectsProjectName</workingDirectory>
<projectFile>SolutionName.sln</projectFile>
<buildArgs>/noconsolelogger /p:Configuration=AutomatedBuild /v:diag</buildArgs>
<target>Bangun</target>
<batas waktu>600</batas waktu>
<logger>C:Program FilesCruiseControl.NETserverThoughtWorks.CruiseControl.MsBuild.dll</logger>
</msbuild>
Melalui kekerasan (jalankan MSBuild, cari tahu perakitan apa yang dibutuhkan, cari, busakan, bilas, ulangi) saya bisa mendapatkan solusi tahun 2005 (dengan proyek pengujian unit) untuk dikompilasi. Namun sebenarnya menjalankan tes adalah cerita lain. Sekali lagi kekerasan berkuasa di sini saat saya menjalankan satu atau dua jam menjalankan MSTest.exe untuk mencoba membujuk beberapa ratus unit tes untuk dijalankan. Entri cc.config untuk mendapatkan beberapa pengujian unit terlihat seperti ini:
<exec>
<dapat dieksekusi>C:Program FilesMicrosoft Visual Studio 8Common7IDEMSTest.exe</executable>
<baseDirectory>d:ccnetprojectsProjectName</baseDirectory>
<buildArgs>/testcontainer:SourceTestsUnitTestsbinAutomatedBuildUnitTests.dll /runconfig:localtestrun.Testrunconfig /resultsfile:testResults.trx</buildArgs>
<buildTimeoutSeconds>600</buildTimeoutSeconds>
</exec>
Ingatlah bahwa saya mengatakan server ini tidak menginstal Visual Studio. Untuk solusi VS2005, saya baru saja menginstal .NET SDK 2.0 dan itu sudah cukup bagus. Meskipun MSTest.exe tidak disertakan, saya mengambil file tersebut (dan kumpulan DLL tambahan gila-gilaan yang tersebar di seluruh hard drive) dari sistem lain dan menempelkannya di tempat EXE berada sehingga akan menyenangkan.
Tidak ada batasan dalam menjalankan MSTest terhadap proyek pengujian unit. Ini dimulai saat menjalankan pengujian, tetapi kemudian mengalami kesalahan COM yang gila (CLSID tidak terdaftar) dan itu sudah cukup bagi saya. Tidak mungkin saya akan melacak semua pengaturan registri COM yang bodoh untuk Visual Studio 2005. Dan apa-apaan ini? COM? Saya pikir kita sudah menyingkirkannya sekitar 3 kompiler yang lalu?
Jadi saya terjebak untuk menginstal Team Suite lengkap di server. Oke, aku akan gigit. Maksudku, aku tidak memerlukan semuanya jadi semuanya akan baik-baik saja (aku terus berkata pada diriku sendiri ketika aku melihat jutaan entri registri terisi). Beberapa jam kemudian dan saya menatap command prompt saya lagi dan mengetikkan perintah MSTest.exe saya. Dan kotak dialog muncul. Yup, kotak dialog modal yang memberi tahu saya ada sesuatu yang salah (saya tidak ingat secara spesifik tetapi tidak terlalu informatif).
Visual Studio telah diinstal dengan baik dan saya dapat mengkompilasi dan menjalankan serta membangun solusi yang saya coba, tetapi pengujian dari baris perintah dengan MSTest.exe tidak dapat dilakukan. Tidak peduli seberapa keras aku berusaha, seberapa banyak aku membersihkan diri, atau berapa banyak perawan yang aku korbankan, itu tidak akan berhasil. Dan ada masalah lain. Dengan tahun 2003 dan pengujian NUnit kami, kami mendapatkan beberapa statistik yang bagus. Pengaturan waktu, pesan informatif, semua hal bagus itu. Dengan MSTest kami tidak mendapatkan apa pun (selain x jumlah pengujian yang dijalankan dan mungkin kegagalan, tetapi saya tidak bisa sejauh itu untuk melihat apakah itu akan memberikan rincian kegagalannya). Selain itu, logger MSBuild menggigit dan menghasilkan sekitar 10.000 baris gobbly-gook yang tidak terlalu berguna. Ya, saya bisa menghabiskan waktu saya menulis xslt baru untuk membuatnya cantik, memangkas baris "Semuanya baik-baik saja" yang mengisi pencatat tugas MSBuild tapi menurut saya itu tidak memberikan nilai tambah pada tarif saya.
Berikut ini contoh email yang saya dapatkan dari build yang memberi Anda gambaran betapa tidak bergunanya kombo CC.NET/MSBuild/MSTest:
BUILD SUCCESSFUL
Proyek: NAMA PROYEK
Tanggal pembuatan: 12/8/2006 08:08:30
Waktu tayang: 00:00:55
Permintaan Integrasi: intervalTrigger memicu build (ForceBuild)
Kesalahan (1)
D:ccnetprojectsPROJECTNAMESourceReportsServerReportsServerReports.rptproj (2,1): error MSB4041: Namespace XML default proyek harus berupa namespace XML MSBuild. Jika proyek dibuat dalam format MSBuild 2003, tambahkan xmlns=" http://schemas.microsoft.com/developer/msbuild/2003 " ke <Proyek> elemen. Jika proyek dibuat dalam format 1.0 atau 1.2 yang lama, harap ubah ke format MSBuild 2003.
Peringatan (1)
SourceReportsServerReportsServerReports.rptproj (,): peringatan MSB4122: Memindai dependensi proyek untuk proyek "SourceReportsServerReportsServerReports.rptproj" gagal. Namespace XML default proyek harus berupa namespace XML MSBuild. Jika proyek dibuat dalam format MSBuild 2003, tambahkan xmlns=" http://schemas.microsoft.com/developer/msbuild/2003 " ke <Proyek> elemen. Jika proyek dibuat dalam format 1.0 atau 1.2 yang lama, harap ubah ke format MSBuild 2003. D:ccnetprojectsBRMSSourceReportsServerReportsServerReports.rptproj
Pengujian dijalankan: 0, Kegagalan: 0, Tidak dijalankan: 0, Waktu: 0 detik
Tidak Ada Tes yang Dijalankan
Proyek ini tidak memiliki tes apa pun
Modifikasi sejak build terakhir (0)
Itu jelek. Jelek banget. MSBuild menghasilkan banyak sekali keluaran yang gila. Menulis file MSBuild baru bukanlah hal yang mudah dan bahkan untuk orang seperti saya yang mengenal NAnt dengan cukup baik, saya masih memikirkan bagaimana MSBuild melakukan sesuatu. Saya harus membuat konfigurasi khusus di dalam Visual Studio untuk menghilangkan proyek Laporan kami karena MSBuild tidak dapat membuatnya (oleh karena itu target AutomatedBuild di atas yang bukan konfigurasi yang sama dengan yang digunakan pengembang kami dan sesuatu yang saya tidak suka lakukan karena itu salah satunya titik server CI, build yang konsisten untuk semua orang).
Dari output di atas, Cruise mengatakan buildnya baik-baik saja tetapi ada pesan error yang keluar dari MSBuild logger (proyek laporan kami). Ini adalah proyek tahun 2005 jadi informasinya tidak masuk akal (saya yakin ini adalah bug yang dicatat tetapi siapa yang tahu kapan bug itu akan diperbaiki). Dan saya benar-benar tidak dapat mengintegrasikan keluaran MSTest ke dalam email karena, tidak ada. Ada sekitar seratus pengujian dalam proyek ini tetapi logger tidak menghasilkan apa pun.
Selain itu, ada beberapa jenis proyek yang tidak dapat ditangani oleh MSBuild dan sekali lagi, diperlukan ilmuwan roket untuk membuat file MSBuild (bahkan menggunakan sesuatu yang keren seperti MSBuild Sidekick) yang dapat memanggil tugas MSBuild lain dan mengecualikan proyek tertentu. Hal ini tentunya tidak semudah pada tahun 2003 ketika Anda baru saja membuat daftar pengecualian (kami mengecualikan aplikasi klien kami karena tidak ada lisensi tambahan untuk kontrol grid dan dialog modal muncul ketika versi uji coba bahkan dilihat oleh kompiler).
Oke, ini sebagian besar hanya kata-kata kasar tetapi ada beberapa hikmah di sini. Integrasi Berkelanjutan tidak perlu sesulit ini. CruiseControl.NET adalah alat yang luar biasa dan sangat fleksibel dengan alat-alat baru dan mengintegrasikan keluaran dari alat-alat tersebut. Namun ketika alat-alat tersebut memerlukan sejuta pengaturan registri dan bahkan lebih banyak DLL (diletakkan di tempat yang sangat spesifik, percayalah, Anda tidak bisa begitu saja memasukkannya ke dalam GAC dan berhenti sejenak) dan membuang sekumpulan XML yang bukan manusia biasa (yah mungkin DonXml bisa) bisa menerjemahkan, hanya saja salah. Dan untuk Team Build bawaan yang dapat Anda gunakan, itu sama tidak bergunanya dengan a) Anda tidak dapat menjadwalkan build untuk memicu check-in kode dan b) sekali lagi ini memerlukan klien Team Suite lengkap untuk diinstal di server . Skenario terburuk ketika saya pertama kali mulai menyiapkan server CC.NET memerlukan waktu 4 jam. Sekarang saya bisa menyelesaikannya dalam satu jam (termasuk pengujian pembangunan proyek pertama). Saya telah menghabiskan hari yang baik hanya dengan mencoba mengkompilasi sesuatu. Ini sedang dikompilasi tetapi hasilnya jelek dan tidak ada pengujian yang berjalan dan itu tidak cukup baik bagi saya. Anda bisa menjalankan MSBuild dan (mungkin) MSTest dengan CruiseControl.NET. Itu bukan tidak mungkin. Jika Anda menginstal klien lengkap dan proyek Anda "tepat" itu akan berfungsi tetapi outputnya tidak terlalu panas dan Anda akan melihat CPU server Anda membanting ketika kompilasi terjadi.
Saran saya, hindari mencoba menggabungkan MSBuild, MSTest, dan CruiseControl dan tetap menggunakan NAnt, dan NUnit (gunakan MSBuild jika perlu saat membuat solusi 2005).
Tak perlu dikatakan lagi, saya sedang melihat satu opsi saat ini. Membuang instalasi VS2005 di server, mengubah semua pengujian unit kami kembali ke NUnit dan menggunakan NAnt untuk melakukan semuanya (dan hanya memanggil MSBuild sebagai tugas exec untuk proyek VS2005). Saya masih perlu menjalankan proyek tahun 2003 sehingga server CI kami akan terlihat seperti monster Frankenstein pada saat saya selesai, membangun proyek VS2003 dan VS2005, menjalankan NUnit, MSBuild, NAnt, Simian, FxCop dan apa pun yang kami miliki di kami mencampur. Meskipun menggunakan NAnt, hasilnya akan lebih sederhana (dan terintegrasi dengan baik dengan CC.NET), hasil pengujian akan berguna dan informatif, dan saya tidak perlu menginstal perangkat lunak seharga $15.000 di server yang memiliki kemungkinan berbeda. untuk memunculkan dialog modal suatu hari nanti ketika tidak dapat menemukan beberapa kunci registri.
Grr. Argh.