Kerangka kerja Integrasi Berkelanjutan mana yang Anda gunakan dan mengapa? [Tutup]


21

Ada beberapa kerangka kerja Continuous Integration (CI) yang berbeda di luar sana dan saya ingin tahu mana yang paling populer. Kerangka mana yang telah Anda gunakan di perusahaan tempat Anda bekerja?

Apakah ada alasan mengapa satu kerangka CI lebih populer daripada yang lain - mungkin ini berkaitan dengan fitur yang ditawarkannya, hal-hal yang berintegrasi ke dalamnya atau mungkin hanya pemasaran yang adil?

Sepertinya integrasi berkesinambungan lebih banyak digunakan di dunia Java dan .net daripada kata ruby ​​atau python. Kenapa ini?


Salah satu alasan mengapa CI tidak begitu relevan dengan Ruby dan Python adalah karena bahasa diinterpretasikan, jadi tidak perlu mengkompilasi apa pun. Tapi itu hanya pendapat pribadi saya ...
mliebelt

1
@mliebelt --CI berkembang menjadi lebih dari sekedar kompilasi cek. Anda dapat menjalankan tes unit / integrasi (bahkan dengan proyek dependen lainnya).
Apoorv Khurasia

Jawaban:


31

Hudson atau Jenkins (yang terakhir adalah fork dari yang sebelumnya). Alasan: Sederhana (mudah dipasang dan digunakan) dan memiliki fleksibilitas tinggi. Plugin menambahkan hampir setiap fungsionalitas yang dapat saya pikirkan.

Beberapa tahun yang lalu saya menggunakan damagecontrol . Itu juga mudah digunakan, tetapi tidak memiliki plugin. Tetapi penulis memutuskan bahwa dia akan menyerah pada solusi sederhana dan memulai pengembangan versi baru, yang terdiri dari berbagai server yang berkomunikasi satu sama lain (apa-apaan?). Itu tidak bekerja dengan baik dan proyek itu menyerah. Saya sedang mencari beberapa waktu, tetapi tidak cruisecontrol (terlalu rumit) atau kontinum benar-benar membuat saya. Sampai hudson, itu berhasil sejak saat pertama bagi saya.


Saya akan menambahkan UI yang layak untuk ini juga.
Martijn Verburg

Ya, saya akan meringkas UI di bawah mudah digunakan.
Mnementh

5
CruiseControl menyusahkan untuk pergi ... Hudson sangat mudah untuk bangkit dan berlari. Plugin Chuck Norris ( wiki.hudson-ci.org/display/HUDSON/ChuckNorris+Plugin ) adalah suatu keharusan.
Sam Dolan

Hudson benar-benar hebat. Padahal, saya berharap itu lebih baik di isolasi. Jika Anda memiliki sejumlah besar tim yang berbeda yang semuanya bekerja pada proyek-proyek yang terkait secara longgar, potensi untuk saling menginjak kaki masing-masing cukup tinggi.
Greg Gauthier

Programmer ini masih tidak dapat mengkonfigurasi Hudson agar berfungsi di Windows :(
Mchl

16

Saya menggunakan TeamCity di tempat kerja dan di rumah. Ini memiliki dukungan besar untuk berbagai build runner dan dapat dikembangkan melalui plugin.

Tidak berurusan dengan tumpukan XML untuk konfigurasi adalah nilai tambah besar dalam buku saya dan versi gratisnya cukup untuk kebutuhan rumah saya.

Satu masalah yang saya hadapi dengan TeamCity ada hubungannya dengan mencoba mendapatkannya secara otomatis versi .NET assemblies. Saya harus menyiapkan solusi yang relatif rumit, tetapi begitu sudah di tempat, itu bekerja seperti pesona.


Saya akan mencoba TC di rumah. Kami memiliki masalah dengan cruisecontrol.net.
Tidak ada yang

8

Secara pribadi, saya hanya pernah menggunakan CruiseControl dan CruiseControl.Net. Alasannya ada hubungannya dengan ekonomi. Mereka cukup stabil dan sekali Anda mengaturnya, hanya ada sedikit yang perlu Anda lakukan untuk mempertahankannya. Komunitas pengguna biasanya sangat membantu, dan dapat diperluas sesuai kebutuhan Anda.

Yang mengatakan, ada beberapa penawaran komersial yang saya ketahui (satu oleh JetBrains, lainnya oleh Atlassian) yang menawarkan pengalaman pengaturan yang lebih baik dan dukungan komersial. Saya bermaksud mencoba penawaran ini tetapi benar-benar belum memiliki kesempatan.

Alat CI memiliki peran yang lebih penting untuk dimainkan dengan bahasa yang dikompilasi daripada bahasa yang ditafsirkan, tetapi itu tidak berarti bahwa alat CI terbuang sia-sia pada bahasa yang ditafsirkan. Ketika Anda memiliki beberapa proyek yang saling bergantung satu sama lain, dan Anda ingin memastikan perubahan tidak secara tidak sengaja merusak dependensinya - alat CI sangat berharga.

Ada tiga kelas umum masalah yang alat CI dapat membantu Anda menangkap:

  1. Kompilasi kesalahan - jika tanda tangan dari suatu kelas berubah dengan cara yang merusak dependensi, yang terbaik adalah mengetahuinya sebelum jam kerja dari hasil pengiriman.
  2. Kesalahan logika - jika perilaku kelas berubah dengan cara yang merusak dependensi, yang terbaik adalah mengetahuinya sejak dini. Ini harus diperiksa oleh semacam pengujian otomatis, paling umum pengujian unit.
  3. Pengujian Penerimaan - jika Anda memiliki rangkaian pengujian otomatis untuk dijalankan pada produk jadi, yang terbaik adalah sering menjalankannya.

Bahasa yang ditafsirkan tidak dikompilasi, jadi tidak ada kesalahan kompilasi yang harus ditangkap. Namun, dua masalah lainnya cukup umum sehingga alat CI berguna untuk proyek-proyek di Ruby / Python / Perl / dll.

Kata kunci dalam kesalahan logika dan poin pengujian penerimaan adalah pengujian "otomatis". Jika Anda tidak memiliki serangkaian pengujian yang dapat dijalankan mesin, maka Anda benar-benar kehilangan manfaat lebih besar dari alat CI. Suite otomatis dapat dibangun dengan waktu, sehingga Anda dapat memulai dari yang kecil.

Edit

Lihat bagan bagus ini untuk perbandingan fitur sejumlah besar Alat CI (banyak yang saya tidak tahu):

http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix


Perbedaan yang dikompilasi / ditafsirkan tidak begitu hitam dan putih. Misalnya, Perl memiliki fase kompilasi yang berjalan saat startup (dan dapat dipanggil secara terpisah dengan opsi "-c") untuk memeriksa kesalahan sintaks.
Andrew Medico

Ini benar. Ruby 1.9 dan Python juga memiliki fase kompilasi. Kelas masalah Kompilasi Kesalahan berlaku untuk bahasa apa pun yang akan memperingatkan Anda jika kelas referensi / variabel / metode tidak ada selama kompilasi. Ini jelas berlaku untuk bahasa yang diketik secara statis. YMMV pada bahasa yang diketik secara dinamis tetapi kuat (seperti Ruby dan Python).
Berin Loritsch

"Begitu Anda mengaturnya, hanya ada sedikit yang perlu Anda lakukan untuk mempertahankannya" - bukankah itu benar untuk semua server integrasi berkelanjutan?
Bryan Oakley

5

Server Yayasan Tim

Solid CI, integrasi yang kuat dengan Visual Studio, dan Git sebagai kontrol versi . Saya telah melihat Server CI yang lebih fleksibel, seperti Hudson, tetapi integrasi TFS yang ketat dengan produk lain menjadikan pengalaman itu begitu mulus sehingga masuk akal bagi tim saya.


Yang dimaksud dengan 'produk lain', maksud Anda adalah 'produk Microsoft'. Saya tidak mengkritik Anda, tetapi MS telah menyusun tumpukan teknologi mereka sehingga untuk berintegrasi dengan produk MS, Anda membutuhkan produk MS lainnya, atau banyak kesabaran dan / atau ketekunan.
GKelly

1
Omong kosong. Mereka memiliki API dan SDK untuk hampir semua yang mereka buat, bahkan Kinect, tetapi programmer non-MS tidak tahu, karena mereka menutup telinga segera setelah mereka mendengar Micros .. (tautan ke TFS SDK) msdn.microsoft.com/ en-us / library / bb130146 (v = VS.80) .aspx
Luke Puplett

2

Saya menggunakan CruiseControl.NET dan Hudson . Beberapa bangunan saya ada di salah satunya dan ada juga yang lain.

Mengapa? Karena saya bukan insinyur bangunan dan dia yang membangun insinyur mengaturnya dengan cara ini!

Saya tidak memiliki masalah dengan cara membangun saya mengatur atau keluhan tentang salah satu produk. Saya melaporkan kepada Anda bagaimana hal-hal di sini, tanpa basa-basi dan berharap Anda menghargai perspektif ini!

UPDATE: Sejak saya memposting jawabannya, Hudson telah bercabang dan menjadi Jenkins . Rekomendasi di atas berlaku untuk Jenkins.


1

Denyut nadi . Ini pada dasarnya Hanya Bekerja, yang bagi insinyur yang sibuk membangun adalah masalah besar. Mereka juga memiliki dukungan teknis yang sangat baik. Alasan utama saya sangat menyukainya adalah karena kami memiliki lebih dari 250 proyek dan menangani mereka tanpa kesulitan; Saya tidak bisa mengatakan hal yang sama untuk Hudson.


1

Tim kami bekerja terutama di Python, C ++ dan Java. Kami menggunakan Buildbot untuk CI. Kami awalnya memulainya karena terintegrasi dengan Trac dan karena itu tampak sederhana dan mudah. Saya percaya itu adalah kerangka kerja CI pilihan di dunia Python.


1

Hudson. Kadang-kadang sedikit buggy, dan beberapa plugin yang lebih menarik tidak benar-benar berfungsi, tetapi dengan sedikit pegangan itu cukup bermanfaat.

Saya mungkin akan menggunakan Pulse sebagai gantinya, tetapi jika Anda perlu membangun di beberapa platform itu> $ 5k, yang agak banyak.


1

CruiseControl.NET untuk integrasi berkelanjutan. Berfungsi cukup baik, meskipun dengan jumlah proyek pembangunan yang sangat besar yang kami atur di CruiseControl, aplikasi baki desktop CCTray sangat tidak responsif, bahkan dengan interval penyegaran yang lama.

NAnt untuk skrip build yang dijalankan di proyek CruiseControl. Untuk skrip build yang lebih kompleks, kami telah memperluas NAnt dengan tugas khusus C # NAnt, yang sangat bagus - menulis kode dalam C # jauh lebih menyenangkan daripada membuat skrip NAnt.

Kami toko Microsoft dan secara teoritis akan pindah ke Microsoft Team Build 2010 setelah kami bermigrasi lingkungan Team Foundation Server kami sampai 2010.


0

Perhatikan bahwa Anda harus dapat membangun aplikasi Anda dari baris perintah terlepas dari Anda memiliki mesin CI berjalan atau tidak.

Ini artinya semua yang dilakukan oleh CI-engine adalah mensistemasi permintaan build Anda, dan Anda dapat memilih mesin yang paling sesuai dengan kebutuhan khusus Anda.

Awalnya saya suka Hudson terutama karena "rasanya" enak, tetapi saya tahu bahwa jika semuanya gagal saya dapat beralih ke yang lain tanpa terlalu banyak usaha. Jika demikian, saya mungkin akan menyelidiki dulu yang dibuat oleh Atlassian, karena saya suka "rasa" dari program lain yang mereka buat.

Perhatikan bahwa interchangeability menyiratkan bahwa tidak masalah bahasa apa yang digunakan. Saya percaya Jawa dipilih untuk banyak mesin karena banyak platform yang didukung, dikombinasikan dengan banyak blok bangunan yang tersedia dengan mudah. Butuh server web - ambil satu. Perlu banyak utas bersamaan - gunakan saja. Perlu diperpanjang - masukkan ke dalam stoples.


0

Sebelum saya pernah mendengar istilah "integrasi-berkelanjutan" (Ini kembali pada tahun 2002 atau 2003) saya menulis skrip pembangunan malam hari yang terhubung ke cvs, mengambil salinan bersih dari proyek utama dan lima sub-proyek yang lebih kecil, membangun semua guci melalui semut kemudian membangun dan memindahkan kembali file PERANG melalui skrip semut kedua yang menggunakan tugas semut kucing jantan.

Itu berjalan melalui cron di 7:00 dan mengirim email dengan banyak file output terlampir. Kami menggunakannya selama 7 bulan seluruh proyek dan tetap digunakan selama 20 bulan ke depan pemeliharaan dan perbaikan.

Ini berfungsi dengan baik tetapi masih lebih suka hudson daripada skrip bash, cron dan semut.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.