Apakah ada alat CI yang menjamin tidak ada regresi di tingkat kualitas cabang?

10

Secara tradisional sistem CI hanya melakukan pemantauan tingkat kualitas dalam cabang integrasi, dengan melakukan verifikasi QA pada basis kode di mana perubahan sudah dilakukan, mengawasi regresi dan mengirim pemberitahuan untuk intervensi manusia.

Tetapi ketika regresi ini terdeteksi, cabang sudah dalam masalah setidaknya sejak verifikasi QA masing-masing dimulai dan akan tetap dalam kondisi seperti itu (atau bahkan menjadi lebih buruk!) Sampai semua pelakunya diidentifikasi, perbaikan untuk mereka berkomitmen dan verifikasi QA baru menegaskan tingkat kualitas cabang telah dipulihkan. Cabang dapat dianggap diblokir untuk pengembangan normal selama ini.

Apakah ada alat CI yang mampu benar-benar mencegah regresi tersebut terjadi, yang akan melakukan verifikasi QA pra-komitmen dan memungkinkan komit hanya ketika basis kode diperbarui dengan masing-masing komit akan melewati verifikasi QA pra-komit juga, sehingga menjamin minimum tingkat kualitas cabang?

Pembaruan: asumsinya adalah bahwa verifikasi QA otomatis yang sesuai dengan cakupan yang sesuai untuk dapat mendeteksi masing-masing regresi tersedia untuk pemanggilan oleh alat CI.

continuous-integration software-recommendation Dan Cornilescu
sumber
Saya terus bertanya-tanya tentang cara yang benar untuk memahami pertanyaan ini (dan rekomendasi Anda sendiri dalam jawaban Anda sendiri). Jika saya mengganti "pemantauan" dengan "setelah fakta", dan "mencegah" dengan "mencegahnya terjadi", apakah itu kira-kira akan menjadi pertanyaan yang sama? Juga, mungkin Anda dapat menambahkan beberapa skenario contoh untuk menjelaskan perbedaannya?
Pierre.Vriens
@ Pierre.Vriens Apakah ini lebih baik?
Dan Cornilescu

Jawaban:

6

Sejauh yang saya tahu, Anda sedang mencari alat yang akan menolak komit yang melanggar pembangunan - alat CI mungkin tidak akan dapat mencegah regresi dengan benar-benar memperbaiki kode Anda, tetapi itu dapat menghentikan Anda dari menambahkan kode yang buruk ke repositori.

Atlassian memiliki beberapa aplikasi menarik dari kait Git :

Kait pra-penerimaan sisi-server adalah pujian yang sangat kuat untuk integrasi berkesinambungan karena mereka dapat mencegah pengembang mendorong kode untuk dikuasai, kecuali jika kode tersebut memenuhi persyaratan tertentu - seperti wali ninja elit, melindunginya dari kode yang buruk.

Jika Anda menggunakan Git, kaitnya sangat kuat (dan ada kait serupa untuk SVN , Mercurial , dan sistem kontrol versi lainnya), dan Anda mungkin merasa berguna untuk menggunakannya untuk menjalankan pemeriksaan pra-komit.

Dokumentasi Git memiliki halaman tentang cara membuat kait untuk menolak dorongan jika mereka tidak memenuhi kriteria tertentu yang dapat dengan mudah disesuaikan dengan kasus penggunaan ini.

Namun, banyak orang akan berpendapat bahwa menolak komit adalah ide yang buruk di featurecabang — Anda hanya akan membuang-buang waktu melawan sistem CI Anda ketika build rusak karena suatu alasan, daripada benar-benar memperbaiki bug.

Di mastercabang, masuk akal untuk menolak gabungan yang rusak, karena Anda mungkin ingin memastikannya selalu membangun. Untuk featurecabang, Anda pasti akan memecahkan banyak hal, dan karena kode tidak mulai diproduksi sekarang , lebih masuk akal hanya untuk memperingatkan Anda daripada benar-benar menolak komit Anda sama sekali.

Aurora0001
sumber
Nah, apa gunanya citra sw yang dibangun, tetapi apakah DOA dari pengujian prospektif? Pengembang tidak dapat menguji perubahan kode mereka bahkan jika mereka membangun, sehingga mereka akan diblokir. Jadi secara umum saya akan memperpanjang komit penolakan terhadap apa pun yang gagal pemeriksaan QA minimum, dipilih dengan menyeimbangkan 2 persyaratan yang saling bertentangan: setinggi mungkin untuk memaksimalkan jumlah pengembang yang dilindungi dari pemblokiran dan serendah mungkin sehingga verifikasi QA tertunda. memperlambat proses terlalu banyak.
Dan Cornilescu
Contohnya mungkin model permintaan tarik di mana Anda dapat mengajukan batasan tertentu pada apakah permintaan tarik dapat digabungkan atau tidak. Sebagai contoh, kami (perusahaan saya) menggunakan Atlassian Bitbucket Server dan ada beberapa opsi untuk meminta setidaknya N jumlah persetujuan dan X jumlah passing untuk cabang tertentu sebelum permintaan tarik diizinkan untuk digabung. Ini tidak langsung menolaknya. Tetapi mencegah penggabungan yang tidak disengaja ketika tes gagal atau mata lain belum melihat kode.
Andy Shinn
@AndyShinn: Ya, saya menemukan itu cukup berguna — GitHub juga menawarkan cabang yang dilindungi dan memeriksa permintaan tarik , yang sering membantu.
Aurora0001
1
Salah satu argumen untuk mengizinkan kode rusak di cabang fitur adalah memungkinkan devs untuk mendorong kode yang sedang mereka kerjakan ke repo, bahkan jika itu belum cukup siap. Ini dapat berguna untuk berbagi kode dengan orang lain untuk tinjauan kode / arsitektur awal sebelum semuanya siap, membantu masalah debugging, atau bagi seseorang yang pergi berlibur untuk meletakkan pekerjaan yang telah selesai sebagian di mana orang lain bisa mendapatkannya. Untuk cabang fitur, saya hanya akan meletakkan hal-hal seperti linter dan sebagai kait pre-commit.
bradym
2

Tidak ada alat yang dapat menjamin tidak ada regresi - yang jauh lebih tergantung pada tes Anda daripada alat yang menjalankannya. Namun, Anda dapat membantu mencegah regresi yang akan tertangkap masuk ke cabang integrasi. Anda dapat melakukan ini dengan kait pra-komit, tetapi seringkali lebih mudah dengan permintaan tarik (yang mudah-mudahan Anda sudah gunakan untuk ulasan kode rekan).

Jika cabang mutakhir dengan upstreamnya (tempat PR dilebur), dan tesnya lolos, maka mereka akan tetap lulus setelah penggabungan; keadaan cabang target setelah penggabungan akan cocok dengan keadaan cabang sumber sebelum penggabungan.

Biasanya tidak terlalu sulit (tergantung pada alat yang digunakan) untuk menunjukkan apakah cabang sumber dalam PR adalah yang terbaru dengan target, dan jika memiliki bangunan CI yang lewat. Anda dapat menggunakan ini sebagai persyaratan (berdasarkan kebijakan, dan / atau diberlakukan dalam perangkat lunak) untuk menggabungkan permintaan tarik.

Adrian
sumber
"Jika cabang up-to-date dengan hulu (tempat PR bergabung), dan tesnya lulus, maka mereka akan tetap lulus setelah penggabungan" - Mengapa? Menggabungkan adalah diskontinuitas, ia membawa yang tidak diketahui. Seperti konflik - kode mungkin tidak akan dibangun sampai diselesaikan. Anda perlu menjalankan tes dan mengonfirmasi bahwa mereka lulus untuk penggabungan cabang apa pun. Saya akan mengatakan bahkan untuk yang maju cepat, jika Anda ingin bermain aman. Lihat apartsw.com/insights/2016/11/16/...
Dan Cornilescu
Um, ya, jaminan seperti itu mungkin, periksa jawaban saya. Yah, mungkin saya harus mengklarifikasi: dengan regresi yang saya maksud hasil lebih buruk dari hasil baseline cabang (dan mengabaikan kemungkinan positif palsu, yang perlu ditangani karena mereka dapat memiringkan baseline, mengacaukan semuanya dan membutuhkan intervensi manusia). Negatif palsu yang terputus-putus hanyalah gangguan, memperlambat segalanya, tetapi dapat diatasi.
Dan Cornilescu
Anda tidak dapat menjamin tidak ada regresi, Anda hanya dapat menjamin tidak ada regresi yang terdeteksi. Jika perubahan menyebabkan regresi yang tidak tertangkap oleh tes, itu adalah regresi yang tidak dapat dijamin oleh alat CI. Dan sementara menggabungkan dua set perubahan memang tidak diketahui, Anda bisa memilih untuk melakukannya di cabang fitur (dengan menggabungkan upstream in) sebelum menggabungkan arah lain. Jika sumber terkini dengan target, itu adalah penggabungan sederhana (maju cepat), dan setelah itu status target akan identik dengan status sumber sebelum penggabungan, maka jika tes lulus sebelumnya, mereka akan lulus setelah.
Adrian
Rambut membelah. Alat CI dapat dikonfigurasi dengan tes untuk mendeteksi dan dengan demikian melindungi terhadap regresi mana pun yang Anda pedulikan. Saya tidak akan berdebat terlalu banyak tentang penggabungan - tujuan saya adalah untuk menghindari mereka sebanyak mungkin, mereka hanya masalah secara keseluruhan :)
Dan Cornilescu
Maksud saya adalah bahwa itu bukan alat CI yang menawarkan perlindungan itu, itu Anda, dengan menulis tes. Alat CI tidak dapat memberikan jaminan apa pun di luar tes yang Anda berikan.
Adrian
1

Alat integrasi kontinu sejati (bukan hanya pengujian berkelanjutan) seperti Reitveld dan Zuul dapat membantu, meskipun mereka hanya sebagus tes yang Anda tulis dan ulasan kode yang Anda lakukan.

pembuat kode
sumber
Tapi Reitveld tampaknya menjadi alat peninjau kode kolaboratif, bukan alat CI, apakah saya kehilangan sesuatu? Inilah yang saya lihat: github.com/rietveld-codereview/rietveld
Dan Cornilescu
Zuul tampaknya memang, terkait, saya akan mempelajarinya lebih dekat.
Dan Cornilescu
Itu tidak melakukan pengujian tetapi menangani beberapa aspek manajemen cabang, bertindak sebagai sistem gatekeeper, yang merupakan taruhan terbaik untuk menjaga kode buruk dari masuk dengan memblokir penggabungan.
coderanger
Saya mengerti apa yang kamu maksud. Yah, ini bisa membantu dengan kualitas kode secara keseluruhan, tetapi dengan sendirinya tidak membawa jaminan apa pun. Dua perubahan sempurna yang lulus semua verifikasi QA secara mandiri masih dapat menyebabkan kerusakan saat mereka bertemu di cabang.
Dan Cornilescu
1

Gunakan GitLAB, Anda dapat mengatur dalam pengaturan proyek untuk hanya memungkinkan penggabungan ketika pipa berhasil, sehingga dapat memiliki Integrasi Berkelanjutan yang benar-benar, gabungkan bahwa dengan menambahkan QA Anda ke daftar persetujuan penggabungan dan dengan Lingkungan Dinamis, Anda dapat memiliki jaminan kualitas sebelum Anda bergabung dengan master.

Danny Goossen
sumber
Itu berfungsi tetapi hanya jika Anda tidak mengizinkan penggabungan ke-2 untuk memulai pemeriksaan QA sebelum penggabungan sebelumnya selesai, jika penggabungan ke-2 tidak akan melihat yang ke-1, meninggalkan ruang untuk regresi. Dengan kata lain, penggabungan (termasuk pemeriksaan QA mereka) harus benar-benar bersambung, yang tidak menskalakan tim besar.
Dan Cornilescu
0

ApartCI adalah sistem CI yang dirancang tepat untuk mencegah regresi, sehingga menjamin tingkat kualitas cabang yang datar. Masih dalam versi beta.

Ini mengatur verifikasi pra-komitmen terpusat sedemikian rupa untuk memastikan bahwa perubahan dilakukan hanya setelah diverifikasi, bersama dengan semua perubahan lain yang dilakukan sebelum itu, untuk memenuhi atau melampaui tingkat kualitas cabang terbaru.

Ini adalah perbedaan utama dibandingkan dengan verifikasi pra-komitmen tradisional yang digerakkan oleh pengembang, sering dilakukan secara paralel, yang memberikan ruang untuk regresi yang disebabkan oleh perubahan yang mengganggu yang tidak pernah diuji bersama.

Alat ini juga dirancang untuk dengan mudah skala - mampu mempertahankan tingkat yang sangat tinggi dari perubahan kandidat yang masuk dan mendukung 100/1000 pengembang yang bekerja di cabang integrasi yang sama.

Penafian: Saya penulis alat dan pendiri perusahaan yang menawarkannya. Permintaan maaf untuk iklan.

Dan Cornilescu
sumber
Ada baiknya Anda menambahkan disclaimer, tetapi secara pribadi saya mempertimbangkan untuk mengajukan pertanyaan dan menjawabnya sendiri dengan mempromosikan perusahaan atau produk Anda sendiri sebagai bentuk spam.
THelper
Saya telah mengajukan pertanyaan pada meta apakah ini diperbolehkan atau tidak: meta.devops.stackexchange.com/q/59
THelper
SnapCI juga melakukan ini. MENINGGAL DUNIA.
paul_h
@ paul_h, kecuali saya melewatkan sesuatu SnapCI dan GoCD pengganti yang disarankan keduanya didasarkan pada verifikasi pasca-komitmen (dipicu oleh polling SCM), jadi mereka masih hanya pemantauan. Kecuali mungkin untuk pemeriksaan PR, tetapi kecuali pemeriksaan ini benar-benar bersambung, mereka hanya dapat mengurangi tingkat kemunculan regresi, tetapi tidak menghilangkannya sama sekali.
Dan Cornilescu
Dan, bukan polling no, kait. Dan ke cabang PR yang berumur pendek yang belum digabung menjadi trunk / master - trunkbaseddevelopment.com/game-changers/…
paul_h