Bagaimana dan mengapa saya mengatur mesin C # build? [Tutup]

Saya bekerja dengan tim pengembangan (4 orang) kecil di proyek C #. Saya sudah mengusulkan menyiapkan mesin build yang akan melakukan build nightly dan tes proyek, karena saya mengerti bahwa ini adalah Good Thing. Masalahnya adalah, kita tidak memiliki banyak anggaran di sini, jadi saya harus membenarkan biaya untuk kekuatan yang ada. Jadi saya ingin tahu:

Pembaruan: Jenkins adalah versi terbaru Hudson. Semua orang harus menggunakan Jenkins sekarang. Saya akan memperbarui tautan yang sesuai.

Hudson gratis dan sangat mudah dikonfigurasi dan akan dengan mudah dijalankan pada VM.

Sebagian dari pos lama saya:

Kami menggunakannya untuk

• Menyebarkan layanan Windows
• Menyebarkan layanan web
• Jalankan MSTests & tampilkan informasi sebanyak tes junit
• Melacak tugas-tugas rendah, sedang, tinggi
• peringatan dan kesalahan trendgraph

Berikut adalah beberapa hal .net bawaan yang didukung Hudson

• MSBuild
• Tidak
• MSTest
• Nunit
• Server Yayasan Tim
• fxcop
• stylecop
• peringatan kompiler
• tugas kode

Juga, Tuhan melarang Anda menggunakan sumber visual yang aman, itu mendukung itu juga . Saya sarankan Anda melihat artikel Redsolo tentang membangun proyek .net menggunakan Hudson

Pertanyaan Anda

• T : Alat / lisensi apa yang akan saya butuhkan? Saat ini, kami menggunakan Visual Studio dan Smart Assembly untuk membangun, dan Perforce untuk kontrol sumber. Apakah saya memerlukan sesuatu yang lain, atau adakah pekerjaan yang setara dengan cron untuk menjalankan skrip otomatis?

• A: Saya baru saja menginstal visual studio pada salinan baru VM yang menjalankan OS server windows yang baru, ditambal. Jadi, Anda perlu lisensi untuk mengatasinya. Hudson akan menginstal sendiri sebagai layanan windows dan berjalan pada port 8080 dan Anda akan mengonfigurasi seberapa sering Anda ingin memindai repositori kode Anda untuk kode yang diperbarui, atau Anda dapat memerintahkannya untuk membangun pada waktu tertentu. Semua dapat dikonfigurasi melalui browser.

• T: Apa, tepatnya, ini akan membuat saya, selain indikasi bangunan yang rusak? Haruskah saya menyiapkan proyek pengujian dalam solusi ini (file sln) yang akan dijalankan oleh skrip ini, sehingga saya dapat menguji fungsi tertentu? Kami memiliki, saat ini, dua tes seperti itu, karena kami belum punya waktu (atau terus terang, pengalaman) untuk membuat tes unit yang baik.

  A: Anda akan mendapatkan email saat bangunan pertama gagal, atau menjadi tidak stabil. Build tidak stabil jika tes unit gagal atau dapat ditandai tidak stabil melalui sejumlah kriteria yang Anda tetapkan. Ketika sebuah unit tes atau bangunan gagal Anda akan diemail dan itu akan memberi tahu Anda di mana, mengapa dan bagaimana itu gagal. Dengan konfigurasi saya, kami mendapatkan:

  • daftar semua komitmen sejak build terakhir bekerja
  • komit catatan komitmen tersebut
  • daftar file yang diubah dalam komit
  • output konsol dari build itu sendiri, menunjukkan kesalahan atau kegagalan pengujian

• T: Apa jenis perangkat keras yang saya perlukan untuk ini?

  A: VM akan cukup

• T: Setelah membangun telah selesai dan diuji, apakah ini merupakan praktik umum untuk meletakkannya di situs ftp atau memiliki cara lain untuk akses internal? Idenya adalah bahwa mesin ini membuat build, dan kita semua pergi ke sana, tetapi dapat membuat debug membangun jika kita harus.

  A: Hudson dapat melakukan apa pun yang Anda inginkan dengannya, itu termasuk mengidentifikasinya melalui hash md5, mengunggahnya, menyalinnya, mengarsipkannya, dll. Ini melakukan ini secara otomatis dan memberi Anda sejarah jangka panjang pembuatan artefak.

• T: Seberapa sering kita harus membuat bangunan seperti ini?

  A: Kami memiliki jajak pendapat kami SVN setiap jam, mencari perubahan kode, lalu menjalankan build. Nightly tidak apa-apa, tapi IMO yang agak tidak berharga karena apa yang Anda kerjakan kemarin tidak akan segar di pikiran Anda di pagi hari ketika Anda masuk.

• T: Bagaimana ruang dikelola? Jika kita membuat bangunan malam, haruskah kita tetap di sekitar bangunan lama, atau mulai membuangnya setelah sekitar satu minggu atau lebih?

  A: Terserah Anda, setelah sekian lama saya memindahkan artefak build kami ke penyimpanan jangka panjang atau menghapusnya, tetapi semua data yang disimpan dalam file teks / file xml yang saya simpan, ini memungkinkan saya menyimpan changelog, grafik tren, dll di server dengan sedikit ruang yang dikonsumsi. Anda juga dapat mengatur Hudson hanya untuk menjaga artefak dari jejak bangunan

• T: Apakah ada hal lain yang tidak saya lihat di sini?

  A: Tidak, dapatkan Hudson sekarang, Anda tidak akan kecewa!

Kami sangat beruntung dengan kombo berikut:

1. Visual Studio (khususnya, menggunakan alat baris perintah MSBuild.exe dan meneruskannya file solusi kami. Menghapus kebutuhan untuk skrip msbuild)
2. Tidak (seperti pustaka sintaks / tugas XML lebih baik daripada MSBuild. Juga memiliki opsi untuk operasi kontrol src P4)
3. CruiseControl.net - dibangun di dasbor web untuk memantau / memulai pembuatan.

CCNet telah membangun pemberi notifikasi untuk mengirim email ketika build berhasil / gagal

Pada justifikasi: Ini mengambil beban dari pengembang melakukan pembuatan manual dan melakukan banyak hal untuk menghilangkan kesalahan manusia dari persamaan. Sangat sulit untuk mengukur efek ini, tetapi begitu Anda melakukannya, Anda tidak akan pernah kembali. Memiliki proses berulang untuk membangun dan merilis perangkat lunak adalah hal yang terpenting. Saya yakin Anda pernah menjadi tempat di mana mereka membangun perangkat lunak dengan tangan dan itu keluar di alam liar, hanya untuk meminta orang membangun Anda mengatakan, "Ups, saya pasti lupa menyertakan DLL baru itu!"

Di perangkat keras: sekuat yang Anda bisa. Lebih banyak daya / memori = waktu pembuatan yang lebih cepat. Jika Anda mampu membelinya, Anda tidak akan pernah menyesal mendapatkan mesin pembuat top-notch, tidak peduli seberapa kecil grupnya.

On space: Membantu memiliki banyak ruang hard disk. Anda bisa membuat skrip NAnt Anda untuk menghapus file perantara setiap kali membangun dimulai, sehingga masalah sebenarnya adalah menjaga riwayat log dan penginstal aplikasi lama. Kami memiliki perangkat lunak yang memonitor ruang disk dan mengirimkan peringatan. Kemudian kami membersihkan drive secara manual. Biasanya perlu dilakukan setiap 3-4 bulan.

Pemberitahuan saat dibuat: Ini dibuat di dalam untuk CCNet, tetapi jika Anda akan menambahkan pengujian otomatis sebagai langkah tambahan, masukkan ini ke dalam proyek sejak awal. Sangat sulit untuk melakukan tes fit sekali proyek menjadi besar. Ada banyak info tentang kerangka uji di luar sana (mungkin satu ton info tentang SO juga), jadi saya akan menunda penamaan alat khusus apa pun.

Di tempat kerja saya sebelumnya, kami menggunakan TeamCity . Ini sangat mudah dan kuat untuk digunakan. Ini dapat digunakan secara gratis dengan beberapa batasan. Ada juga tutorial tentang Dime Casts . Alasan kami tidak menggunakan CruiseControl.NET adalah karena kami memiliki banyak proyek kecil dan cukup menyakitkan untuk mengatur masing-masing di CC.NET. Saya akan sangat merekomendasikan TeamCity. Untuk meringkas jika Anda menuju open source maka CC.NET adalah grand daddy dengan kurva belajar yang sedikit lebih tinggi. Jika anggaran Anda memungkinkan Anda pergi dengan TeamCity atau melihat versi gratisnya.

Bagaimana? Lihatlah blog Carel Lotz .

Mengapa? Ada beberapa alasan yang dapat saya pikirkan:

• Build yang berfungsi, bila diterapkan dengan benar, berarti semua pengembang Anda dapat membangun di mesin mereka ketika build tersebut berwarna hijau
• Bangunan kerja, bila diterapkan dengan benar, berarti Anda siap untuk digunakan kapan saja
• Bangunan kerja, ketika diimplementasikan dengan benar, berarti apa pun yang Anda lepaskan telah melakukan perjalanan ke sistem kontrol sumber Anda.
• Bangunan kerja, ketika diimplementasikan dengan benar, berarti Anda mengintegrasikan lebih awal dan sering, mengurangi risiko integrasi Anda.

Artikel Martin Fowler tentang Integrasi Berkelanjutan tetap menjadi teks definitif. Lihat itu!

Argumen utama yang mendukung adalah bahwa hal itu akan memangkas biaya proses pengembangan Anda, dengan memberi tahu Anda sesegera mungkin bahwa Anda memiliki tes yang rusak atau gagal.

Masalah mengintegrasikan pekerjaan beberapa pengembang adalah bahaya utama menumbuhkan tim. Semakin besar tim, semakin sulit untuk mengoordinasikan pekerjaan mereka dan menghentikan mereka mengacaukan perubahan masing-masing. Satu-satunya solusi yang baik adalah memberi tahu mereka untuk "berintegrasi lebih awal dan sering", dengan memeriksa unit-unit kerja kecil (kadang-kadang disebut "cerita") ketika mereka selesai.

Anda harus membuat mesin build membangun kembali SETIAP kali memeriksa, sepanjang hari. Dengan Cruise Control, Anda bisa mendapatkan ikon di bilah tugas Anda yang berubah menjadi merah (dan bahkan berbicara kepada Anda!) Saat build rusak.

Anda kemudian harus melakukan pembangunan bersih malam penuh di mana versi sumber diberi label (diberi nomor pembuatan unik) yang dapat Anda pilih untuk dipublikasikan kepada para pemangku kepentingan Anda (manajer produk, orang-orang QA). Ini agar ketika bug dilaporkan, itu melawan nomor build yang diketahui (itu sangat penting).

Idealnya Anda harus memiliki situs internal tempat build dapat diunduh, dan memiliki tombol yang dapat Anda klik untuk menerbitkan build malam sebelumnya.

Hanya mencoba membangun sedikit pada apa yang dikatakan mjmarsh, karena dia meletakkan dasar yang bagus ...

• Studio visual. MSBuild berfungsi dengan baik.
• Tidak .
• NantContrib . Ini akan memberikan tugas tambahan seperti operasi Perforce.
• CruiseControl.net . Lagi-lagi ini pada dasarnya adalah "build dashboard" Anda.

Semua hal di atas (simpan untuk VS) adalah open source, jadi Anda tidak melihat adanya lisensi tambahan.

Seperti yang disebutkan Earwicker, bangunlah lebih awal, bangunlah dengan sering. Mengetahui sesuatu pecah, dan Anda dapat menghasilkan barang yang berguna untuk menangkap barang sejak dini.

Tidak termasuk tugas untuk nunit / nunit2 juga, sehingga Anda benar-benar dapat mengotomatiskan pengujian unit Anda. Anda kemudian dapat menerapkan stylesheet ke hasilnya, dan dengan bantuan kerangka yang disediakan oleh CruiseControl.net, dapatkan hasil pengujian unit yang mudah dibaca dan dapat dicetak untuk setiap bangunan.

Hal yang sama berlaku untuk tugas ndoc . Buat dokumentasi Anda tersedia dan tersedia, untuk setiap bangunan.

Anda bahkan dapat menggunakan tugas exec untuk menjalankan perintah lain, misalnya, menghasilkan Pemasang Windows menggunakan InstallShield.

Idenya adalah untuk mengotomatiskan bangunan sebanyak mungkin, karena manusia membuat kesalahan. Waktu yang dihabiskan di depan adalah waktu yang dihemat di jalan. Orang tidak harus mengasuh gedung dengan melalui proses pembangunan. Identifikasi semua langkah pembuatan Anda, buat skrip NAnt untuk setiap tugas, dan buat skrip NAnt Anda satu per satu hingga Anda sepenuhnya mengotomatiskan seluruh proses pembuatan Anda. Itu juga kemudian menempatkan semua bangunan Anda di satu tempat, yang bagus untuk tujuan perbandingan. Sesuatu yang merusak Build 426 yang bekerja dengan baik di Build 380? Nah, ada kiriman yang siap untuk diuji - ambil dan uji pergi.

• Tidak diperlukan lisensi. CruiseControl.net tersedia secara bebas dan hanya membutuhkan .NET SDK untuk dibuat.
• Server bangun, bahkan tanpa pengujian unit otomatis masih menyediakan lingkungan yang terkendali untuk membuat rilis. Tidak ada lagi "John biasanya membangun di atas mesinnya tetapi dia sakit. Untuk beberapa alasan saya tidak bisa membangun di atas mesin saya"
• Saat ini saya memiliki satu pengaturan dalam sesi PC Virtual.
• Iya. Bangunan harus dibuang di tempat yang dapat diakses. Pembangunan pembangunan seharusnya mengaktifkan debugging. Rilis build seharusnya dimatikan.
• Seberapa sering terserah Anda. Jika diatur dengan benar, Anda dapat membangun setelah setiap check in akan sangat sedikit overhead. Ini adalah ide bagus jika Anda memiliki (atau berencana memiliki) tes unit.
• Simpan tonggak dan rilis selama diperlukan. Apa lagi tergantung pada seberapa sering Anda membangun: terus menerus? membuang. Harian? Simpan satu minggu. Mingguan? Menyimpan nilai dua bulan.

Semakin besar proyek Anda semakin Anda akan melihat manfaat dari mesin build otomatis.

Ini semua tentang kesehatan bangunan. Apa yang Anda dapatkan adalah Anda dapat mengatur segala hal yang Anda inginkan terjadi pada build. Di antaranya Anda dapat menjalankan tes, analisis statis, dan profiler. Masalah ditangani jauh lebih cepat, ketika Anda baru-baru ini mengerjakan bagian aplikasi itu. Jika Anda melakukan perubahan kecil, maka hampir memberitahu Anda di mana Anda memecahkannya :)

Ini tentu saja mengasumsikan, Anda mengaturnya untuk membangun dengan setiap check-in (integrasi berkelanjutan).

Ini juga dapat membantu mendekatkan QA dan Dev. Karena Anda dapat mengatur tes fungsional untuk menjalankannya, bersama dengan profiler dan hal lain yang meningkatkan umpan balik ke tim pengembang. Ini tidak berarti tes fungsional berjalan dengan setiap proses check in (bisa memakan waktu cukup lama), tetapi Anda mengatur build / tes dengan alat yang umum bagi seluruh tim. Saya telah mengotomatisasi tes asap, jadi dalam kasus saya, kami berkolaborasi lebih dekat.

Mengapa: 10 tahun yang lalu kami sebagai pengembang perangkat lunak digunakan untuk menganalisis sesuatu sampai tingkat n mendapatkan dokumen (ditulis dalam bahasa manusia) 'ditandatangani' lalu mulai menulis kode. Kami akan menguji unit, uji string dan kemudian kami akan melakukan uji sistem: pertama kali sistem secara keseluruhan akan berjalan bersama, kadang-kadang minggu atau bulan setelah kami menandatangani dokumen. Baru saat itulah kami akan mengungkap semua asumsi dan kesalahpahaman yang kami miliki ketika kami menganalisis semuanya.

Integrasi dan ide yang berkelanjutan menyebabkan Anda membangun sistem yang lengkap (walaupun, awalnya, sangat sederhana) ujung ke ujung. Seiring waktu fungsi sistem dibangun secara orthogonal. Setiap kali Anda melakukan build lengkap, Anda melakukan tes sistem lebih awal dan sering. Ini berarti Anda menemukan dan memperbaiki bug dan asumsi sedini mungkin, saat ini adalah waktu termurah untuk memperbaikinya.

Bagaimana: Mengenai caranya, saya ngeblog tentang hal ini beberapa waktu yang lalu: [ Klik disini ]

Lebih dari 8 posting berjalan selangkah demi selangkah tentang cara mengatur server Jenkins di lingkungan windows untuk solusi .NET.