Pada titik manakah server integrasi berkelanjutan menarik?


9

Saya telah membaca sedikit tentang server CI seperti Jenkins dan saya bertanya-tanya: pada titik mana ini berguna?

Karena tentunya untuk proyek kecil di mana Anda hanya akan memiliki 5 kelas dan 10 unit tes, tidak perlu.

Di sini kita punya sekitar 1500 unit tes dan mereka lulus (pada workstation Core 2 Duo lama) dalam waktu sekitar 90 detik (karena mereka benar-benar menguji "unit" dan karenanya sangat cepat). Aturan yang kami miliki adalah bahwa kami tidak dapat melakukan kode ketika tes gagal.

Jadi setiap pengembang meluncurkan semua tesnya untuk mencegah regresi.

Jelas, karena semua pengembang selalu meluncurkan semua tes, kami menangkap kesalahan karena perubahan yang bertentangan segera setelah satu pengembang menarik perubahan dari yang lain (bila ada).

Masih belum jelas bagi saya: haruskah saya mengatur server CI seperti Jenkins? Apa yang akan dibawanya?

Apakah ini hanya berguna untuk peningkatan kecepatan? (bukan masalah dalam kasus kami)

Apakah ini berguna karena bangunan lama dapat diciptakan kembali? (tapi kita bisa melakukan ini dengan Mercurial, dengan memeriksa rev lama)

Pada dasarnya saya mengerti itu bisa berguna tetapi saya gagal melihat persis mengapa.

Penjelasan apa pun yang memperhitungkan poin-poin yang saya sampaikan di atas akan sangat disambut.

Jawaban:


9

Apakah ini hanya berguna untuk peningkatan kecepatan? (bukan masalah dalam kasus kami)

Setiap waktu yang dihabiskan untuk bersepeda, proses Anda adalah waktu yang bisa Anda habiskan untuk memasuki arus perkembangan.

Anda juga akan menghemat waktu di tonggak karena Anda idealnya membangun bit yang dikemas dan siap dikirim yang dapat dibakar langsung ke CD, diunggah ke web, dll.

Apakah ini berguna karena bangunan lama dapat diciptakan kembali? (tapi kita bisa melakukan ini dengan Mercurial, dengan memeriksa rev lama)

Tidak, Anda tidak membuat ulang bangunan. Anda menggunakan build yang dibuat, dan menyimpannya sampai pengaturan retensi Anda membuangnya.

Anda membangunnya di server build, bukan pada kotak Dev.

Di sini kita punya sekitar 1500 unit tes dan mereka lulus (pada workstation Core 2 Duo lama) dalam waktu sekitar 90 detik (karena mereka benar-benar menguji "unit" dan karenanya sangat cepat). Aturan yang kami miliki adalah bahwa kami tidak dapat melakukan kode ketika tes gagal.

Selain itu, tidakkah Anda ingin dapat menjalankan integrasi otomatis atau pengujian ujung ke ujung pada kode Anda dan menangkap masalah yang tidak akan ditemui oleh pengujian unit?

Anda tidak ingin menjalankannya di kotak dev, karena akan sulit untuk mengatur dan memelihara lingkungan itu. Tes integrasi juga cenderung sangat lambat untuk dijalankan.

pada titik mana ini berguna?

Ini adalah investasi seperti yang lainnya.

Gunakan sekali dan Anda mungkin keluar di belakang atau hanya impas. Gunakan pada banyak proyek dan Anda mungkin akan maju.

Itu juga tergantung pada jenis aplikasi yang Anda buat.

Jika Anda membuat aplikasi web yang perlu digunakan ke Java Application Server, atau IIS, maka CI menjadi no-brainer. Sama jika Anda memiliki database sebagai bagian dari proyek Anda. Penempatan sulit dilakukan secara manual, dan tim QA Anda (jika ada) akan membutuhkannya sesering setiap hari di beberapa titik.

Juga, Anda mungkin ingin melihat bagaimana kebutuhan dan masalah Anda selaras dengan 12 Steps to Better Code karya Joel Spolsky . Khususnya 2, 3 dan 10 (meskipun semuanya menarik dan penting).


2
+1 ... OK sekarang Anda sedang berbicara dengan saya! The "tidak kehilangan waktu melakukan membangun" Argumen saya seperti banyak. Build kami dilakukan beberapa kali setiap hari dan hanya membutuhkan satu klik tapi ... lebih lambat daripada menjalankan semua tes (jadi devs kehilangan waktu). Juga, saya menyukai gagasan tes yang lebih rumit: ini saya melihat bagaimana kita bisa mendapat manfaat dari server CI. Mengenai 2,3 dan 10: ya, ya dan ya (satu klik pada tugas Ant) ... Tapi man, 12 aturan ini harus diperbarui: apakah Anda menggunakan kontrol sumber? Saya lebih suka yang bukan CVS, misalnya; ) (hanya setengah bercanda;)
Cedric Martin

7

Pada titik mana ini berguna?

  • Siklus build + test Anda berlangsung selama beberapa menit. Dengan 5 menit uji coba, Anda tidak akan lagi ingin menjalankan semua tes sendiri, terutama untuk perubahan kecil.
  • Anda mulai membangun beberapa varian. Jika Anda memiliki beberapa pelanggan dengan penyesuaian yang berbeda, Anda harus menjalankan tes terhadap setiap varian, sehingga jumlah pekerjaan akan mulai tumbuh cukup cepat. Daripada Anda menjalankan test suite untuk satu varian pada mesin pengembang dan menyerahkannya kepada CI untuk menjalankannya pada yang lain.
  • Anda menulis tes integrasi otomatis yang memerlukan pengaturan lingkungan tes non-sepele. Daripada Anda ingin menguji terhadap satu lingkungan pengujian kanonik, karena pengembang mungkin memiliki lingkungan mereka yang dimodifikasi dengan berbagai cara karena perubahan pengembangan. CI adalah tempat yang paling cocok untuk lingkungan kanonik.
  • Penguji hanya dapat menarik bangunan terbaru dari CI. Jadi mereka tidak perlu memiliki, mempelajari dan menggunakan alat pengembangan, juga tidak ada pengembang yang harus mengirimkannya secara manual.
  • Saat Anda bersiap untuk rilis:
    • Pengujian menjadi lebih penting, sehingga memiliki satu tempat dengan build yang disiapkan untuk pengujian bahkan lebih bermanfaat.
    • Anda yakin semua build dibangun dengan lingkungan build yang sama, sehingga Anda terhindar dari masalah yang mungkin disebabkan oleh perbedaan halus antara instalasi pengembang.
    • Anda yakin bahwa Anda sedang membangun apa yang diperiksa dalam sistem kontrol versi. Selama pengembangan jika seseorang lupa memeriksa sesuatu, Anda akan menemukannya dengan cepat, karena itu akan gagal untuk pengembang berikutnya. Tetapi jika bangunan seperti itu tergelincir ke QA atau produksi dan mereka melaporkan bug, akan sangat sulit dilacak.

Anda mungkin belum membutuhkan CI dulu, tetapi saya pikir itu akan menjadi berguna ketika Anda sampai pada tahap pengujian. Jenkins diatur dalam beberapa jam dan itu akan menyederhanakan pengujian Anda dan membantu menghindari kesalahan konyol (itu terjadi terutama ketika Anda terburu-buru memperbaiki cepat untuk produksi).


+1, terima kasih. Tapi argumen build yang saya tidak pernah benar-benar mengerti: bukankah aplikasi lebih kuat ketika semua pengembang dapat checkout rev apa pun dan membangun build yang sama persis, masing-masing di mesin mereka? Bukankah kita hanya menggeser masalah "build terikat ke akun pengembang" menjadi "build terikat ke server CI" ? Maksud saya: server CI itu sendiri mungkin salah dikonfigurasi dan karenanya membangun menjadi tergantung pada perbedaan halus instalasi CI server !? Yang mengatakan saya agak menyadari itu bisa berguna: Saya pikir saya hanya perlu "menginstalnya dan melihat"
:)

@CedricMartin: Server CI hanya satu, sehingga Anda tidak akan memiliki bug yang diperkenalkan oleh perbedaan antara lingkungan yang Anda lakukan ini dan yang sebelumnya dibangun di dan karena Anda tidak melakukan pekerjaan lain pada server CI, itu kurang mungkin bahwa Anda memecahkannya .
Jan Hudec

@CedricMartin: Jelas jika server CI salah dikonfigurasi, Anda akan melihat bahwa build berperilaku berbeda dari yang dilakukan pada kotak pengembang, karena pengembang akan mengkompilasi sendiri setiap saat. Lebih mudah daripada ketika beberapa kotak pengembang tertentu salah dikonfigurasi, karena lebih banyak orang dapat melihat.
Jan Hudec

6

Bagi saya, CI akan menarik jika tim Anda memiliki lebih dari 1 anggota.

Anda harus berhenti menganggap CI sebagai "PC lain yang menjalankan tes untuk saya". CI tentang memiliki proses pembangunan yang ditetapkan dan otomatis serta manajemen rilis.

CI adalah entitas otoritatif tunggal yang membuat rilis perangkat lunak Anda. Jika tidak dibangun di atas CI, itu tidak terjadi.

Dengan CI Anda memiliki batasan untuk mengotomatiskan segala sesuatu yang akan menunjukkan kepada Anda semua tweak manual, retas, dan pintasan yang Anda miliki dan hanya tidak bekerja dengan CI dan harus dihindari sejak awal.

Masalah yang dihindari:

  • Siapa yang bertanggung jawab untuk membangun rilis
  • Apakah orang ini 24/7 tersedia
  • Tapi itu dibangun di atas sindrom mesin saya
  • Menghapus semua ambiguitas tentang versi apa yang kami rilis

Keuntungan (terlalu banyak untuk disebutkan semua):

  • Penomoran versi otomatis
  • Integrasi pelacakan masalah
  • Generasi metrik otomatis
  • Analisis kode statis
  • Penempatan otomatis
  • Pengaturan multi-tahap

5

Ada satu masalah mendasar tentang Continuous Integration (CI) yang benar-benar tercermin dalam pertanyaan Anda: Praktik CI sulit diimplementasikan dan dipertahankan karena perangkat lunak server CI tidak sepele untuk pengaturan, juga tidak sepele untuk mendapatkan proyek Anda dan menjalankan melalui CI server. Dengan ini, menjadi sulit untuk benar-benar melihat di mana keuntungan dalam merangkul CI sama sekali.

Pertama-tama, CI adalah tentang wawasan dan kualitas. CI yang baik membawa Anda lebih dekat ke proyek Anda, memberi Anda umpan balik yang tepat tentang metrik kualitas, dokumentasi, kepatuhan standar pengkodean, dll. Ini akan memberi Anda alat untuk dengan mudah memvisualisasikan semua ini, dan memungkinkan Anda untuk sekilas mengenali dan dengan mudah kaitkan satu set perubahan dengan cuplikan spesifik dari semua metrik proyek ini.

Ini bukan hanya tentang menjalankan unit test. Tidak semuanya! Yang membawa saya ke kualitas. CI mencakup kesalahan, itu tidak menghindarinya atau membuangnya. Apa yang dilakukannya cukup sederhananya memberi Anda alat untuk melakukan kesalahan sejak awal, alih-alih nanti. Jadi Anda tidak benar-benar melakukan kode yang diuji sebelumnya ke server CI. Meskipun Anda harus berusaha untuk melakukan kode yang bersih dan tidak rusak, Anda benar-benar menggunakan server CI untuk secara otomatis menjalankan pembangun integrasi secara otomatis melalui kode Anda dan membuatnya menilai jika semuanya keluar dengan benar. Jika sudah, rapi! Jika tidak, tidak ada masalah - praktik CI yang baik menyatakan bahwa prioritas Anda berikutnya adalah memperbaiki apa saja yang telah rusak. Yang, di server CI yang baik, harus dengan mudah ditunjukkan untuk Anda.

Ketika ukuran tim meningkat, integrasi kode setiap orang secara alami menjadi lebih sulit. Seharusnya tugas server CI terpusat untuk menguji semua bagian yang terintegrasi dan mengambil beban itu dari anggota tim. Jadi, Anda harus meminta semua orang melakukan komitmen lebih awal (dan sebersih mungkin) dan kemudian memantau status build (biasanya ada notifikasi yang dilibatkan). Dan lagi, jika ada sesuatu yang rusak karena komitmen beberapa pengembang, itu segera menjadi tanggung jawabnya untuk memperbaikinya dan membuat bangunan otomatis itu kembali ke status OK segera.

Jadi Anda tahu, menurut saya setiap proyek mendapat manfaat dari Terintegrasi Secara Berkelanjutan. Masalahnya adalah, sampai sekarang dan karena kompleksitas yang membingungkan dari setiap server CI tunggal yang saya tahu, orang benar-benar menangkis praktik CI pada proyek yang lebih kecil / sederhana. Karena, ayolah, orang-orang memiliki hal-hal yang lebih baik untuk dilakukan daripada menghabiskan waktu berhari-hari mengonfigurasi perangkat lunak yang jelek, terlalu rumit, pengirimannya rendah, dan kembung.

Saya memiliki masalah yang sama persis, dan itulah yang membuat saya mengembangkan Cintient di waktu luang saya sejak sekitar setahun yang lalu sekarang. Premis saya adalah membuatnya mudah untuk menginstal, mengonfigurasi, dan menggunakan, dan membuatnya memberikan metrik kualitas yang setiap orang gagal atau underdelivers. Jadi, setelah jawaban yang panjang ini datang plug saya yang tidak tahu malu menunjukkan tautan GitHub untuk proyek (yang gratis dan open-source, natch). Ini juga memiliki beberapa tangkapan layar yang bagus. :-) https://github.com/matamouros/cintient

Semoga saya membantu Anda.

(CATATAN: Diedit setelah komentar Bryan Oakley, pada kenyataan bahwa saya seharusnya mengambil lebih banyak waktu untuk membangun jawaban yang lebih baik. Saya juga berpikir dia benar.)


Saya memilih karena ini tidak menjawab pertanyaan, itu hanya iklan. Anda tidak pernah membahas kapan bagian dari pertanyaan selain secara tidak langsung menyatakan "sekarang, dengan alat saya".
Bryan Oakley

Saya meluangkan waktu untuk mengedit jawabannya, seperti yang disarankan oleh @ bryan-oakley.
matamouros

@matamouros: pekerjaan yang bagus di edit.
Bryan Oakley
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.