Hudson atau Teamcity untuk integrasi berkelanjutan? [Tutup]

100

Kami adalah toko Java yang mencari alat CI untuk digunakan. Baik Hudson dan Teamcity tampaknya bebas tetapi Teamcity tampaknya lebih apik dan dengan lebih banyak dukungan.

Saya bertanya-tanya mengapa seseorang masih menggunakan Hudson dan jika ada yang bisa memberikan argumen untuk / menentang keduanya?

— pdeva
sumber

Anda mungkin tertarik dengan jawabannya di sini: stackoverflow.com/questions/1200721/…

— ire_and_curses

Saya akan memasukkan CruiseControl ke dalam campuran - jika Anda belum mempertimbangkannya. Tidak dapat mengomentari sudut pandang java, setelah menggunakan versi .NET tapi saya suka itu.

— AdaTheDev

3

@ire_and_curses tidak ada balasan di pos yang memberikan argumen yang baik untuk kedua alat dibandingkan dengan yang lain

— pdeva

4

-1 untuk Cruise Control - CARA terlalu banyak file konfigurasi yang perlu diatur secara manual "begitu saja".

— Bevan

3

Sejauh yang saya bisa lihat, keberadaan TeamCity gratis membuat CruiseControl tidak berfungsi. Saya tidak melihat alasan untuk menggunakan CruiseControl atas TeamCity. Dan banyak alasan untuk kebalikannya.

— Niall Connaughton

113

Team City sejauh ini merupakan server CI terbaik di luar sana. Fitur pembunuhnya bagi saya adalah integrasi yang erat dengan IDE (IntelliJ, Eclipse dan VisualStudio). Ini dapat menunjukkan kepada Anda, misalnya, ketika file yang Anda edit di IDE menjadi usang, siapa yang mengubahnya dan apa yang mereka ubah. Anda dapat berkomitmen dari IDE ke server CI, menjalankan comile dan menguji pada kisi build, lalu server CI akan berkomitmen jika build berhasil. Anda dapat mengklik laporan build di aplikasi web CI dan itu akan membuka file yang sesuai di IDE.

Ada plugin yang tersedia (saya menulis satu: http://team-piazza.googlecode.com ), tetapi tidak banyak.

— Nat
sumber

9

Remote run / Pra-uji komit adalah fitur TeamCity yang sangat berguna. Secara umum TC bisa lebih nyaman jika build Anda tidak cepat, karena di TeamCity Anda mendapatkan masukan terus menerus tentang apa yang terjadi di build Anda (berapa banyak pengujian yang berhasil, gagal, di tahap mana build tersebut dan seterusnya). Notifikasi TC juga lebih canggih. Anda dapat mengonfigurasi aturan yang berbeda untuk berbagai jenis build dan untuk berbagai pemberi tahu (email, Jabber, windows tray).

— Pavel Sher

6

@Pavel: Saya tidak tahu TeamCity sebaik Hudson jadi saya tidak akan menantang awal komentar Anda. Tapi, mengenai notifikasi, mengklaim TC lebih canggih adalah FUD murni menurut saya tidak begitu sederhana. Semua saluran notifikasi yang disebutkan tersedia di Hudson (Anda bahkan dapat menambahkan twitter). Sebenarnya, saya yakin Hudson memiliki plugin yang jauh lebih banyak daripada TC (periksa wiki.hudson-ci.org/display/HUDSON/Plugins ) dan saya yakin TC memiliki lebih banyak batasan daripada Hudson.

— Pascal Thivent

3

Saya setuju tentang saluran (Hudson memiliki banyak plugin), tetapi tidak setuju tentang aturan. Di TeamCity Anda dapat berlangganan ke build dengan perubahan Anda, Anda dapat memilih untuk diberi tahu saat build mulai gagal (misalnya, saat pengujian pertama mulai gagal). Anda dapat meminta untuk diberi tahu tentang build pertama yang gagal setelah urutan keberhasilan + tentang keberhasilan pertama setelah kegagalan. Dan opsi ini tersedia untuk semua saluran notifikasi. Salah satu saluran tersebut adalah IDE notifier: ketika terjadi kesalahan, Anda akan mendapatkan notifikasi langsung di IDE Anda. Seingat saya, aturan pemberitahuan Hudson jauh lebih sederhana.

— Pavel Sher

2

Pavel - tidak menginginkan pertandingan slinging di sini, tetapi secara default Hudson hanya akan mengirim email kepada Anda jika Anda berkontribusi pada build yang gagal. Anda juga dapat berlangganan untuk diberi tahu tentang setiap build yang gagal jika Anda mau. Ada juga lebih banyak opsi di plugin email-ext. Anda tidak harus menyetujuinya, tetapi jangan salah menggambarkannya.

— Jim T

4

Google cepat akan menunjukkan kepada Anda bahwa ada plug-in untuk mengontrol kelinci nabaztag dan perangkat lucu lainnya dari Team City. Atau Anda dapat menggunakan plugin yang saya tautkan dalam jawaban saya . Manfaat integrasi IDE yang ketat adalah umpan balik yang lebih cepat dan lebih terfokus tentang kode yang sedang Anda kerjakan saat Anda mengerjakannya. Anda tidak perlu menunggu notifikasi, beralih ke browser tge, membaca laporan, beralih kembali ke IDE, dan membuka file yang sesuai. Panel editor berubah saat Anda bekerja untuk memperlihatkan bagaimana anggota tim lain telah memengaruhi kode.

— Nat

58

1 untuk Hudson.

Hudson adalah proyek yang sangat aktif, memiliki komunitas pengguna yang luas dan milis pengguna aktif, sangat mudah untuk memulai, mudah digunakan, telah digunakan pada proyek besar, sangat besar, (JBoss, JAX-WS, dll) dan dengan demikian telah membuktikan catatan kesuksesan, menawarkan tingkat lanjut yang sangat bagus fitur (misal build matrix, build clustering, dll), bersifat open source, memiliki banyak plugin ...

~~Dan jika dukungan benar-benar suatu hal yang penting, Anda bisa mendapatkan dukungan komersial dari Sun . Tapi FWIW, saya tidak pernah menghadapi masalah pemblokiran apapun dengan Hudson.~~

Pembaruan: Seperti yang Anda ketahui, Kohsuke Kawaguchi (pencipta Hudson) telah meninggalkan Sun / Oracle dan memulai perusahaannya sendiri untuk membawa Hudson ke tahap berikutnya . Dengan kata lain, ini bukanlah ancaman bagi Hudson. Dan jika Anda mencari dukungan, Anda bisa mendapatkan versi tersertifikasi dari Hudson CI Server sebagai bagian dari paket berlangganan (versi bersertifikat ini menggabungkan rilis berkualitas tinggi dari Hudson dengan seperangkat plugin yang telah ditentukan dan beberapa yang komersial).

Pembaruan: Untuk mengilustrasikan ukuran basis pengguna masing-masing, berikut adalah perbandingan tren pekerjaan untuk beberapa alat CI di Memang (kueri langsung):

Hudson build engineer, CruiseControl build engineer, Bamboo build engineer, TeamCity build engineer Job Trends

Ini tentu saja bukan indikator teknis.

— Pascal Thivent
sumber

88

Mungkin TeamCity begitu mudah digunakan, karena tidak mengharuskan siapa pun yang secara khusus dipekerjakan untuk mengkonfigurasinya?

— Henrik

3

@Henrik: Interpretasi grafik di atas adalah kebijaksanaan Anda. Tapi ya, mungkin TeamCity itu ajaib.

— Pascal Thivent

16

Jika Anda mempekerjakan insinyur bangunan penuh waktu untuk menjalankan integrasi berkelanjutan Anda, sekarang Anda memiliki dua masalah: 1) CI Anda sulit untuk dikerjakan, jadi pengembang Anda akan berjuang dengan itu dan pengetahuan akan duduk di kepala satu orang ini, 2) Anda membayar seseorang untuk melakukan pekerjaan yang seharusnya tidak perlu dilakukan!

— Niall Connaughton

15

Jika saya memilih server CI, saya akan memilih salah satu yang memiliki lowongan pekerjaan LEAST untuk insinyur yang berdedikasi untuk mengelolanya. Ini adalah alat pengembang dan pengembang harus dapat mengelolanya sendiri. Jika mereka tidak bisa, Anda membutuhkan alat yang berbeda atau pengembang yang berbeda.

— Nat

Grafik tren pekerjaan tidak menyiratkan +1 untuk hudson sama sekali ...

— Sharique Abdullah

17

Kami memulai dengan Hudson untuk beberapa proyek Flex, lalu kami bermigrasi ke TeamCity, ketika pengembang .NET bergabung dengan upaya CI kami. Sekarang kami telah mengganti server TeamCity lagi, kembali ke Hudson. Alasan utamanya adalah: - Komunitas Hudson yang bersemangat, lebih baik daripada dukungan. - Jumlah plugin yang sangat besar untuk setiap jenis tugas. - Sumber terbuka. - Hudson gratis, TeamCity hanya gratis untuk 10 proyek.

edit: TeamCity sekarang gratis untuk 20 proyek.

— subotnik
sumber

2

10 batasan proyek telah jatuh, satu-satunya batasan sekarang adalah 20 konfigurasi build. Untuk proyek ukuran kecil hingga menengah mungkin cukup.

— ashwoods

4

Karena penasaran, fitur apa yang tersedia melalui plugin Jenkins yang hilang di dunia TeamCity?

— Behrang Saeedzadeh

14

TeamCity sangat bagus karena memungkinkan setiap pengembang untuk memiliki profil build mereka sendiri dan menghubungkannya dari IDE mereka. Bahwa satu-satunya adalah 'tendangan pantat'. Ada juga dukungan untuk GIT dll. Serius lihat itu. Versi profesionalnya gratis.

— Beaumont Muni
sumber

5

GIT juga didukung oleh Jenkins / Hudson

— CJBrew

14

Argumen terbesar terhadap Hudson adalah bahwa setiap rilis menghadirkan bug baru.

Rilis sangat sering, jadi Anda harus sering meningkatkan agar tidak ketinggalan. Itu berarti Anda perlu mencurahkan banyak waktu untuk mendiagnosis masalah dan memutar kembali ke rilis Hudson sebelumnya. (Terkadang rollback bahkan tidak mungkin dilakukan!)

Kami memperkenalkan Penerapan Berkelanjutan di toko kami (saat Anda memeriksa kode, kode akan diterapkan di situs langsung!) Dan harus bergumul dengan Hudson membuat kami terlalu mahal.

Kami secara aktif mencari cara untuk bermigrasi ke TeamCity semata-mata karena biaya bug Hudson.

— jdtangney.dll
sumber

8

Hanya karena ada pembaruan yang tersedia tidak berarti Anda harus meningkatkan. Saya lebih suka mereka merilis lebih banyak daripada lebih jarang. Itu pilihan saya kapan harus meningkatkan, dan saya pasti tidak melakukannya setiap minggu. Juga, pengelola sangat konservatif tentang kompatibilitas ke belakang. Plugin umumnya tidak memerlukan Hudson terbaru agar dapat berfungsi. Faktanya, 130 plugin yang tersedia sekarang dibuat dengan versi Hudson yang lebih dari satu tahun. Jika Anda masih khawatir, ada plugin rollback otomatis yang sedang bekerja ..;)

— Christopher Orr

1

Dari pengalaman saya, masalahnya lebih pada plugin daripada Hudson itu sendiri, meskipun ini tidak membuat perbedaan besar dari sudut pandang pengguna. Tetapi, tidak ada yang memaksa Anda untuk meningkatkan kecuali Anda menghadapi bug tertentu atau tidak dapat hidup tanpa fitur baru. Kami hanya tidak mengikuti setiap rilis dan tidak menggunakan versi terakhir sama sekali bukan masalah bagi kami: "Jika tidak rusak, jangan perbaiki" .

— Pascal Thivent

2

Ketika pelaku utama mengirimkan pesan yang mengatakan bahwa cacat keamanan utama telah diperbaiki, itulah alasan untuk memperbarui. Poin saya masih berlaku: Hudson terlalu rapuh - bahkan tanpa plugin tambahan yang terpasang.

— jdtangney

1

Saya dapat mengatakan bahwa setelah satu setengah tahun menggunakan Hudson / Jenkins pada satu proyek, sementara itu adalah alat yang hebat - kami juga mengalami kualitas yang tidak konsisten di antara rilis - dan kami hanya meningkatkan saat kami benar-benar membutuhkannya. Kami menemukan solusi, termasuk sering mencadangkan konfigurasi. Saya menantikan untuk mencoba TeamCity pada proyek terbaru saya.

— JaysonRaymond

4

Mengapa pembaruan dan stabilitas harus menjadi faktor yang berlawanan? Bukankah itu hanya menunjukkan kurangnya kualitas?

— Niall Connaughton

6

Saya sangat menyukai Teamcity tetapi dalam lingkungan saya mengerjakannya, waktu yang dibutuhkan untuk mendapatkan Pesanan Pembelian untuk Teamcity melalui lapisan manajemen kemungkinan akan melebihi waktu yang dibutuhkan untuk memigrasi semuanya ke Hudson.

— sal
sumber

10

Profesional TeamCity tidak dikenai biaya.

— Pavel Sher

6

@Pavel, kami memiliki lebih dari 20 pengguna dan lebih banyak bangunan dari itu.

— sal

22

@sal selalu membuat saya takjub bagaimana perusahaan dapat begitu peduli atas beberapa ribu dolar untuk alat tim pengembangan mereka dan lebih suka jika mereka menyia-nyiakan 100 jam gabungan yang tidak mereka miliki dengan alat tersebut.

— Chris Marisic

5

@Chris Bagaimana jika mereka mulai dengan alat gratis open source karena hanya untuk melihat bagaimana sesuatu bekerja dan 2 tahun kemudian menyadari bahwa itu masih berfungsi tanpa masalah? Apakah Anda masih menyarankan menghabiskan beberapa ribu dolar untuk meningkatkan ke alat komersial yang kemungkinan besar melakukan hal yang persis sama?

— StefanB

1

@stefan Jika Anda telah menggunakan suatu alat selama 2 tahun dan alat tersebut memenuhi kebutuhan Anda kecuali ada featureX yang Anda perlukan dari alat lain, mengapa Anda beralih ke alat lain yang gratis atau berbayar?

— Chris Marisic

2

Saya telah menggunakan dan mengatur TeamCity dan Jenkins (alias Hudson baru) sebelumnya dan sementara saya setuju bahwa TeamCity jauh lebih licin untuk mengaturnya hanya gratis untuk tim dengan 10 pengguna atau kurang. Kedua sistem ini sangat mudah diatur dan memiliki sistem plugin yang didukung dengan baik. Fitur mematikan di TeamCity adalah alur kerja pra-check in di mana Anda dapat menguji kode sebelum memeriksanya ke dalam kontrol sumber dan kelebihan Jenkins adalah bahwa ia sepenuhnya gratis bahkan jika Anda berkembang melebihi 10 pengguna dan membangun agen.

— runxc1 Bret Ferrier
sumber

Saya juga suka tampilan grafik Jenkins, dan itulah yang saya lewatkan di Teamcity. Selanjutnya saya setuju dengan komentar Anda!

— Danny Gloudemans

Jika Anda setuju dengan sebuah komentar, maka voting :)

— runxc1 Bret Ferrier

1

Saya baru saja mulai terbiasa dengan hudson yang siap bereksperimen dan melihat bagaimana hal itu akan cocok dengan lingkungan kita saat ini. Saya sama sekali tidak memiliki pengalaman dengan Teamcity jadi tidak dapat berkomentar tentang itu tetapi sejauh ini saya menikmati bekerja dengan hudson.

Ada banyak plugin untuk hudson dan situs hudson memberi Anda banyak saran untuk menulis sendiri ( http://wiki.hudson-ci.org/display/HUDSON/Extend+Hudson ).

— Jake Worrell
sumber

1

Saya telah merekomendasikan kepada klien bahwa mereka menganggap Bambu. Alasannya karena (ok, dari membaca lembar spesifikasi!) Ia memiliki set fitur yang sangat mirip dengan TeamCity. Namun keuntungan utamanya adalah integrasi yang sangat erat dengan JIRA yang cukup populer sebagai sistem pelacakan fitur / bug. Suite lengkapnya adalah JIRA, Greenhopper, Bamboo, dan Eclipse. Beberapa klien juga memiliki pusat Kualitas HP dan ada plugin yang menggabungkannya ke JIRA juga. Saya juga menyukai fakta bahwa JIRA, Bamboo dan GreenHopper semuanya berasal dari Atlassian.

— drekka
sumber

Setelah menggunakan TeamCity secara ekstensif, Jenkins terlihat sangat polos. Ya, plugin memungkinkan Anda melakukan apa saja, setelah Anda menginstalnya. TeamCity memiliki serangkaian fitur dewasa yang membuat Anda keluar dari kotak. Namun pada tingkat pengiriman berkelanjutan, keduanya membiarkan pipeline pementasan yang tepat tidak diterapkan. QuickBuild adalah produk yang lebih kaya fitur yang perlu diperhatikan, yaitu perangkat pembayaran.

— bbaassssiiee

Setelah melihat Bamboo beraksi di situs klien, saya tidak lagi tertarik dengannya. Ada beberapa area di sekitar pembuatan skrip dan mentransfer informasi di antara build yang kesulitan untuk dilakukan. Hasilnya cenderung pengembang menempatkan segala macam hal di area variabel global CI yang seharusnya tidak ada di sana.

— drekka