Bagaimana dan mengapa saya mengatur mesin C # build? [Tutup]
144
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:
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?
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.
Jenis perangkat keras apa yang saya perlukan untuk ini?
Setelah membangun telah selesai dan diuji, apakah itu praktik umum untuk meletakkan yang membangun di situs ftp atau memiliki cara lain untuk akses internal? Idenya adalah bahwa mesin ini membuat para membangun, dan kita semua pergi ke sana, tapi dapat membuat debug membangun jika kita harus.
Seberapa sering kita harus membuat bangunan seperti ini?
Bagaimana ruang dikelola? Jika kita membuat bangunan malam, haruskah kita tetap di sekitar bangunan lama, atau mulai membuangnya setelah sekitar satu minggu atau lebih?
Apakah ada hal lain yang tidak saya lihat di sini?
Saya menyadari bahwa ini adalah topik yang sangat besar, dan saya baru memulai. Saya tidak dapat menemukan duplikat dari pertanyaan ini di sini, dan jika ada buku di luar sana yang harus saya dapatkan, tolong beri tahu saya.
EDIT: Saya akhirnya berhasil! Hudson benar-benar fantastis, dan FxCop menunjukkan bahwa beberapa fitur yang kami pikir telah diimplementasikan sebenarnya tidak lengkap. Kami juga harus mengubah jenis penginstal dari vdproj Lama-dan-Busted ke New Hotness WiX.
Pada dasarnya, bagi mereka yang memperhatikan, jika Anda dapat menjalankan build Anda dari baris perintah, maka Anda dapat memasukkannya ke hudson. Membuat build berjalan dari baris perintah melalui MSBuild adalah latihan yang berguna dalam dirinya sendiri, karena memaksa alat Anda menjadi terkini.
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!
Jawaban bagus! Saya hanya menggunakan CruiseControl, tetapi Anda memiliki penjualan yang bagus untuk Hudson.
Ben S
1
Terima kasih untuk petunjuknya - Hudson terlihat seperti The Right Tool.
mmr
1
Bisakah Anda menaruh tautannya pada kata pertama?
Jhonny D. Cano -Leftware-
Di mana Anda meminta tautan ke hudson? Jika demikian, saya menambahkannya, terima kasih :)
Allen Rice
5
Jika ada yang melewatkannya, Hudson telah dipalsukan / diganti nama menjadi Jenkins oleh pengembang aslinya. Anda sekarang lebih baik memilih Jenkins, karena pertanyaan ini kemungkinan akan meyakinkan Anda.
Jonik
26
Kami sangat beruntung dengan kombo berikut:
Visual Studio (khususnya, menggunakan alat baris perintah MSBuild.exe dan meneruskannya file solusi kami. Menghapus kebutuhan untuk skrip msbuild)
Tidak (seperti pustaka sintaks / tugas XML lebih baik daripada MSBuild. Juga memiliki opsi untuk operasi kontrol src P4)
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.
Kamu, saya punya pengalaman hebat dengan CC.NET juga :)
cwap
Jawaban yang bagus kecuali untuk persyaratan perangkat keras. Dia melakukan pembangunan malam jadi saya ragu dia peduli jika itu membutuhkan beberapa jam untuk dikompilasi dan diuji. Saya bahkan menyarankan pengaturan semuanya dalam VM pada perangkat keras yang sudah mereka miliki.
Ben S
Terima kasih atas tipsnya. Saya akan menggunakannya dalam pembenaran saya.
mmr
1
Kami menggunakan mesin build di sini dengan NAnt / Subversion / CC.Net untuk build C # dan C ++ dan ini benar-benar alat yang hebat untuk memastikan bahwa Anda belum merusak proyek lain. Ini menghapus banyak takut melanggar proyek lain ketika mengubah perpustakaan, karena toh Anda akan melihat segera jika pecah segalanya
Julien Roncaglia
11
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.
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.
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.
Saya sudah lupa tentang ndoc. Dokumentasi adalah bola lilin nother keseluruhan yang harus kita tangani - terima kasih atas pengingatnya.
mmr
4
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.
Meskipun tautan ini dapat menjawab pertanyaan, lebih baik untuk memasukkan bagian-bagian penting dari jawaban di sini dan memberikan tautan untuk referensi. Jawaban hanya tautan dapat menjadi tidak valid jika halaman tertaut berubah.
TLama
Ini tidak memberikan jawaban untuk pertanyaan itu. Untuk mengkritik atau meminta klarifikasi dari seorang penulis, tinggalkan komentar di bawah posting mereka - Anda selalu dapat mengomentari posting Anda sendiri, dan begitu Anda memiliki reputasi yang cukup, Anda akan dapat mengomentari setiap posting .
Danilo Valente
Memperbarui komentar saya berdasarkan umpan balik.
Jawaban:
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
Berikut adalah beberapa hal .net bawaan yang didukung Hudson
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:
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!
sumber
Kami sangat beruntung dengan kombo berikut:
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.
sumber
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.
sumber
Bagaimana? Lihatlah blog Carel Lotz .
Mengapa? Ada beberapa alasan yang dapat saya pikirkan:
Artikel Martin Fowler tentang Integrasi Berkelanjutan tetap menjadi teks definitif. Lihat itu!
sumber
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.
sumber
Hanya mencoba membangun sedikit pada apa yang dikatakan mjmarsh, karena dia meletakkan dasar yang bagus ...
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.
sumber
Semakin besar proyek Anda semakin Anda akan melihat manfaat dari mesin build otomatis.
sumber
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.
sumber
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.
sumber