Haruskah pengembang menunggu pipa CI untuk menyelesaikan atau memulai tugas berikutnya setelah mendorong

8

Perusahaan saya mengintegrasikan CI / CD, sejauh ini kami telah mengimplementasikan CI dari apa yang saya mengerti. Saat ini ketika pengembang mendorong kode ke repo git kami, pipa CI berjalan.

Saat ini pipeline CI kami termasuk membangun proyek dan melakukan analisis kode statis untuk memastikan memenuhi standar pengkodean kami. Kami akan menerapkan pengujian berikutnya. Analisis kode build dan statis memakan waktu sekitar 3 menit sekarang. Dari apa yang saya baca, masalah perbaikan segera penting untuk CI / CD. Saya berharap ketika kita menambahkan unit test bahwa pipa bisa memakan waktu sekitar 10 menit untuk dijalankan.

Jadi pertanyaan saya adalah kapan pengembang membuat permintaan tarik / gabung haruskah mereka menunggu pipa CI untuk menyelesaikan atau hanya beralih ke tugas berikutnya dan kembali untuk memperbaiki masalah pipa jika ada? Atau haruskah mereka duduk dan menonton pipa berjalan?

continuous-integration git continuous-delivery

— iqueqiorio
sumber

7

Duduk dan saksikan pipa berjalan?

Tidak, itu bukan cara Anda bekerja secara efisien.

Pengembang mendorong komit mereka ke repositori kontrol sumber dan kemudian pipa CI / CD dipicu.

Pengembang dapat memposting permintaan tarik yang ditulis dengan baik kapan saja mereka mau. Biasanya ada tanda visual yang mewakili "bangunan yang sedang berjalan" / "bangunan yang gagal" / "bangunan yang berhasil".

Biasanya suatu pelanggaran dapat digabungkan kapan pun semua kriteria ini dipenuhi:

setidaknya satu pemberi persetujuan / atau sebanyak yang diperlukan untuk menyetujui telah menyetujui.
"bangunan yang berhasil"
tidak ada konflik gabungan yang belum terselesaikan

Jika salah satu dari kriteria ini tidak terpenuhi, mereka perlu diperbaiki, tetapi pengembang melakukannya setiap kali ia memiliki waktu atau prioritas untuk melakukan tugas ini.

— Jonas
sumber

2

Jawaban yang bagus. Banyak orang tidak menyadari bahwa dengan SaaS GitHub, Anda dapat meminta lingkaran-ci atau CI lainnya membangun perubahan yang diajukan dalam permintaan tarik sebelum perubahan tersebut digabungkan. Jadi saya telah melihat GitHub Enterprise on-prem digunakan tanpa fitur yang digunakan: Jenkins Farm on-prem hanya berjalan setelah Anda menggabungkan PR yang mungkin rusak kecuali dev melakukan penggabungan dan pembangunan penuh. Itu kemudian membuat hidup menjadi lebih kompleks. Bertahun-tahun yang lalu teamcity membiarkan Anda melakukan pembangunan di pertanian sebelum Anda bahkan berkomitmen untuk mencegah melanggar cabang. Hanya membangun setelah masalah telah diterbitkan adalah cara kerja warisan.

— simbo1905

@ simbo1905 semuanya baik, kecuali verifikasi PR tidak 100% efektif kecuali seluruhnya serial. PR yang tumpang tindih berarti perubahan masing-masing tidak mempertimbangkan satu sama lain dan mungkin masih saling mengganggu yang menyebabkan kerusakan ketika mereka mendarat di cabang integrasi. Bahkan jika mereka tidak memiliki konflik gabungan atau bahkan menyentuh file yang sama - konflik fungsional masih mungkin terjadi.

— Dan Cornilescu

@DanCornilescu. PR yang disetujui dapat melewati bangunan mandiri tetapi konflik. Satu mengganti nama metode, satu menambahkan kode yang menggunakan nama metode lama. Kedua PRs pass dibangun secara paralel. Ketika keduanya disetujui dan digabungkan kode tidak akan dikompilasi. Proyek besar menggunakan bot gabungan seperti bors-ng. Peninjau tidak menggabungkannya, mereka memberi tahu bot untuk mencoba. Bot melakukan penggabungan serial hanya setelah bangunan baru di mana ia menggabungkan apa yang ada dalam antrian gabungannya. Dalam contoh kami ini akan mencoba membangun gabungan dari PR gabungan. Gagal jadi coba hanya yang pertama ditambahkan ke antriannya, berhasil, gabungkan, lalu buat dan tolak yang lain.

— simbo1905

1

Saya sarankan mencoba yang terbaik untuk memastikan pipa kurang dari 10 menit. Anda dapat menjalankan tes Anda secara paralel untuk mengaktifkan ini. Saat jonas menjawab, mereka kemudian dapat menghabiskan waktu membuat permintaan tarik (saat pipa sedang berjalan).

Pergantian konteks lebih buruk untuk produktivitas, daripada mengambil tugas lain, saya sarankan pengembang menggunakan waktu itu untuk mengerjakan hal lain yang terkait dengan perubahan yang baru saja dibuatnya. Mungkin ada beberapa dokumentasi yang dapat diperbarui terkait dengan ini. Jika itu fitur yang patut diperhatikan, ia bisa membuat gif pendek yang menunjukkan cara bekerja dengannya. Bahkan melihat perubahan kode mereka lagi dapat membantu mereka berpikir bagaimana mereka dapat memperbaikinya lain kali. Waktu ini juga dapat digunakan untuk meninjau permintaan tarik pengembang lain dan perubahan kode.

Jika mereka pindah ke mengembangkan fitur lain dalam 10 menit itu kemungkinan akan lebih lama dari 10 menit sebelum mereka kembali ke sana dan pekerjaan akan kurang segar di pikiran mereka. Jika CI kemudian gagal, akan lebih sulit bagi mereka untuk mengingat apa yang salah dan memperbaiki kode.

— Samuel Garratt
sumber

Ini sangat benar: CI dalam pendapat saya seharusnya tidak pernah berjalan lebih lama dari pada mesin dev.

— Peter Muryshkin

0

Ok jadi mari kita asumsikan Anda memiliki alat kontrol versi sebagai alat Git dan CI Jenkins. Jadi Dev membuat cabang fitur untuk masalah. Anda memiliki pipa multibranch atau alur kerja di alat CI Anda yang mendeteksi cabang fitur ini di pemindaian berikutnya dan menjalankan langkah-langkah CI.

Jadi hal-hal yang harus dipastikan adalah:

Sebelum menaikkan PR / MR, pekerjaan CI berwarna hijau. Jika tidak hijau, PR / MR tidak boleh dinaikkan. Jelas pengembang dapat melakukan tugas-tugas lain dan kemudian kembali dan memperbaiki masalah pada tugas ini, itu adalah pilihan mereka tergantung pada prioritas tugas. Anda bahkan dapat mengontrol PR apa pun agar tidak dinaikkan dengan memeriksa parameter CI-nya. (Jika Anda tidak terlalu mempercayai dev Anda dan mereka terus-menerus meningkatkan PRs untuk bangunan yang rusak)
Setelah PR dinaikkan, peninjau kode akan meninjau dan menggabungkan jika semuanya OK. Peninjau kode dapat berupa pengembang lain. Tanggung jawabnya adalah untuk meninjau kode tersebut, melihat apakah kode tersebut dalam kriteria "Definisi Selesai". DoD terutama merupakan istilah lincah tetapi lincah dan DevOps berjalan seiring.
Setelah kode digabungkan, CI untuk cabang utama harus berwarna hijau. Jika tidak, kode harus diputar kembali dan masalah harus diperbaiki karena umumnya cabang utama juga digunakan untuk lingkungan dan tidak memutar kembali berarti seluruh lingkungan akan rusak.

Jelas, tindakan post build akan memberi tahu committer bahwa Hei, Anda telah merusak build, sehingga Devs dapat melakukan tugas mereka yang lain, mereka akan mendapatkan email.

— Deosha
sumber