Bagaimana Anda menangani kode integrasi dari beberapa cabang / pengembang setiap sprint?

42

Baru saja keluar dari telepon retro di mana pengembang menyatakan keprihatinan tentang integrasi cerita mereka ke cabang utama setiap sprint. Semua kode pengembang di dalam cabang mereka sendiri dan menjelang akhir sprint mereka semua bergabung menjadi satu cabang utama.

Kemudian, satu pengembang (biasanya yang sama) dibiarkan dengan tugas memastikan semuanya telah terintegrasi dengan baik dengan kode pengembang lain (Sebagian besar perubahan ada di halaman yang sama. Misalnya, cerita tampilan data, cerita penyaringan data, dan indikator SLA).

Bagaimana kita bisa mengurangi beban ini dan memudahkan kode kita untuk bergabung bersama? Dari sudut pandang saya, meminta PO atau SM memprioritaskan cerita dengan cara yang lebih efisien sehingga kami tidak memiliki dependensi semacam ini dalam sprint yang sama dapat menyelesaikan beberapa masalah. Bagaimana orang lain mengatasi ini? Atau ini hanya bagian dari proses?

— juru masak
sumber

18

Apakah Anda tidak memiliki cabang pengembangan di mana integrasi berkelanjutan dilakukan?

— Kayaman

13

Saya bersama Kayaman di sini, praktik terbaik untuk ini adalah menerapkan integrasi berkelanjutan.

— RandomUs1r

27

Selamat Hari Gabungan! Setiap kali masalah Anda terlalu mirip dengan sesuatu di The Daily WTF, Anda tahu Anda dalam masalah.

— user3067860

Gabungkan lebih awal, gabungkan sering: {tulis kode uji terkecil yang akan gagal (merah), tuliskan kode produksi terkecil yang akan lulus (hijau), refactor, tes ulang, gabung} saat belum selesai.

— ctrl-alt-delor

1

Check-in pertama Menang! Tidak pernah menjadi yang terakhir! :-)

— ChuckCottrill

88

Jika Anda menggunakan Git, setiap pengembang akan menarik dari developcabang ke cabang fitur mereka sendiri sehingga mereka memastikan mereka tidak pergi terlalu jauh dari garis dasar saat ini. Mereka dapat melakukannya setiap hari, sehingga tugas yang memakan waktu lebih dari beberapa hari tetap sinkron dan menggabungkan masalah diselesaikan saat masih kecil.

Ketika pengembang selesai dengan pekerjaan mereka, mereka membuat permintaan tarik . Ketika disetujui, itu akan bergabung ke developcabang.

The developcabang harus selalu memiliki kode bekerja, dan siap untuk rilis setiap saat. Ketika Anda benar-benar membuat rilis, Anda menggabungkan developke masterdan tag itu.

Jika Anda memiliki Server Integrasi Berkelanjutan yang baik, maka ia akan membangun setiap cabang ketika perubahan dicentang - terutama untuk permintaan tarik. Beberapa server build terintegrasi dengan server Git Anda untuk menyetujui secara otomatis atau menolak permintaan tarik jika build gagal atau tes otomatis gagal. Ini adalah cara lain untuk menemukan bug integrasi potensial.

— Berin Loritsch
sumber

73

Bagian penting (yang hanya tersirat dalam jawaban Anda) adalah bahwa cabang-cabang harus digabung segera setelah mereka siap, biasanya dengan hanya 1 - 5 komitmen, dan tidak hanya pada akhir sprint. Satu cabang per fitur / cerita, bukan satu cabang per pengembang. Untuk itu diperlukan cerita yang benar-benar kecil, yaitu paling lama dua hari.

— amon

@amon, setuju. Menambahkan kata-kata "cabang fitur", tetapi mencoba untuk menjaga jawaban ini cukup kecil. Ada banyak artikel bagus yang membahas lebih dalam tentang proses ini.

— Berin Loritsch

5

Jangan tetap terisolasi di cabang Anda sendiri. Begitulah cara menggabungkan neraka dimulai. Gunakan pengembangan jalur utama, pisahkan sakelar kerja dalam proses di balik fitur atau konfigurasi run-time lainnya.

— Rob Crawford

3

@Zibbobz Tim saya menggunakan "Cabang Fitur" yang eksplisit untuk mereka, yang pada dasarnya diperlakukan seperti mengembangkan cabang, tetapi hanya untuk menarik permintaan dan melakukan yang berhubungan dengan perubahan itu. Umumnya, tergantung pada berapa lama harus tetap terpisah, setiap beberapa hari seseorang akan menggabungkan perubahan dari pengembangan menjadi fitur dan menyelesaikan masalah apa pun. Dengan cara itu, ranting-rantingnya semirip mungkin ketika tiba saatnya untuk bergabung. Sebagai catatan, ini hanya untuk perubahan besar

— reffu

9

"mengisolasi work-in-progress di belakang fitur toggle atau konfigurasi run-time lainnya" Anda baru saja menghindari menggabungkan neraka dengan masuk ke config hell sebagai gantinya. "Gabungkan neraka" hanyalah masalah bagi satu pengembang pada satu waktu dan mudah dihindari hanya dengan menyinkronkan secara teratur, memiliki banyak konfigurasi sementara adalah neraka bagi semua pengembang masa depan selamanya.

— Cubic

23

Saya bekerja di tim tempat kami berjuang dengan masalah yang sama. Kami menemukan bahwa semakin sedikit waktu yang kami miliki sebelum berintegrasi, semakin sulit jadinya. Saya tahu kebanyakan orang mengajarkan pembicaraan integrasi terus-menerus tentang melakukan setiap beberapa menit - kami mungkin benar-benar berkomitmen setiap jam.

Kami juga menemukan bahwa membangun saja tidak cukup. Kami membutuhkan tingkat cakupan pengujian yang baik untuk memastikan bahwa kami tidak secara sengaja melanggar kode masing-masing.

— Daniel
sumber

2

Ini pengalaman saya juga. Tidak masalah seberapa sering Anda komit, tetapi setelah berkomitmen dengan cepat integrasi / penggabungan komit menghemat banyak upaya. Saya pernah berada di sebuah proyek di mana kami memiliki tiga cabang pembangunan yang berbeda yang masing-masing memiliki pekerjaan berbulan-bulan. Menggabungkan mereka tidak menyenangkan. Saya belajar banyak dari kesalahan itu :)

— amon

4

Ya - inilah yang dimaksud dengan "integrasi berkelanjutan"! Anda terus mengintegrasikan perubahan Anda dengan perubahan pengembang lain!

— Rob Crawford

@Rob, setuju. Pernyataan saya tidak dimaksudkan untuk menyarankan bahwa integrasi berkelanjutan tidak, yah, berkelanjutan. Hanya saja kami tidak cukup membuat yang ideal dan masih melihat banyak manfaat dalam mendekatinya.

— Daniel

12

Biarkan cabang Anda berumur pendek (sepertinya Anda sudah melakukan ini).
Biarkan hasil tes Anda berbicara sendiri.
Jangan menunggu akhir sprint.

Anda bahkan tidak perlu berlangganan TDD untuk yang satu ini. Yang Anda butuhkan hanyalah beberapa tes yang membuktikan bahwa fitur pengembang Anda berfungsi dengan benar. Ini dapat mencakup Tes Unit dan Tes Integrasi tetapi idealnya akan menjadi beberapa tes end-to-end otomatis dari fitur-fitur penting. Barang paket regresi standar.

Kemudian, setelah penggabungan Anda selesai, Anda dapat memeriksa laporan pengujian otomasi bersama dan memverifikasi bahwa semuanya telah berhasil diintegrasikan.

Saya setuju dengan salah satu jawaban lain di mana penulis menyatakan Git PRs akan menyelesaikan masalah ini dengan meminta setiap pengembang untuk menggabungkan pekerjaan mereka sendiri.

Satu hal lagi yang saya yakin cukup penting untuk ditinggalkan sampai paragraf terakhir. Saya sarankan Anda menjalankan tes manual di atas bangunan malam Anda, daripada menunggu sampai akhir sprint. Pengembang harus bergabung segera setelah fitur selesai sehingga dapat diintegrasikan, digunakan, dan diuji sesegera mungkin.

— Liath
sumber

6

Jangan

Bergantung pada bahasa Anda dan file apa yang Anda edit, mungkin tidak masuk akal bagi setiap pengembang untuk mengeditnya di cabang mereka sendiri. Misalnya, dalam C # saya telah menemukan yang terbaik adalah hanya satu orang untuk mengedit file desainer UI pada suatu waktu. Ini adalah file yang di-autogenerasi, sehingga kode terkadang dipindahkan tanpa alasan yang jelas - dan ini mendatangkan malapetaka pada sebagian besar alat penggabungan.

Ini berarti bahwa beberapa cerita dapat memblokir cerita lain sampai pekerjaan UI selesai. Dan / Atau, cerita baru dibuat hanya untuk tata letak UI, dengan cerita lainnya yang mengimplementasikan fungsionalitas. Atau, mungkin satu pengembang melakukan semua UI berfungsi sementara yang lain mengimplementasikan fungsionalitas UI itu.

Pada catatan terkait, jika Anda tahu banyak cerita akan menyentuh file yang sama, Anda mungkin hanya ingin menghindari mengerjakannya pada waktu yang bersamaan. Jangan tarik semuanya ke dalam sprint yang sama, atau jangan mulai mengerjakan semuanya sampai satu atau lebih selesai.

— mmathis
sumber

Jujur, alat kontrol versi yang digunakan lebih penting untuk percabangan dan penggabungan yang sukses. Bahkan dengan kode C # dan kode WinForms atau WebForms mungkin Anda harus bekerja dengan biasanya tidak banyak berubah . Jika ya, mungkin Anda perlu melakukan beberapa maket sebelum bermain dengan kode. UI berbasis XAML sama stabilnya dengan kode reguler dan kode perantara tidak dicentang.

— Berin Loritsch

2

Kode desainer @BerinLoritsch WinForms memang dapat banyak berubah, bahkan dengan perubahan visual kecil. Saya telah menemukan bahwa baris kode itu sendiri sama, tetapi urutannya sangat berbeda - terutama ketika banyak pengembang melakukan pengeditan pada saat yang sama. Mungkin ini adalah masalah alat VCS (kami telah menggunakan beberapa, mungkin kami hanya menggunakan yang salah), tetapi bagi kami itu jauh lebih mudah untuk mengubah proses kami sedikit.

— mmathis

2

@BerinLoritsch Saya harus mmathis kedua di sini setidaknya untuk formulir menang (tidak pernah menggunakan formulir web). Desainer UI winforms senang memesan ulang secara acak semua kode dalam file desainer sebagai tanggapan terhadap perubahan sepele di suatu tempat pada formulir. Kecuali jika Anda secara manual membatalkan pemesanan ulang sebelum setiap komit (sesuatu yang dapat dengan mudah 10 atau 15 menit pada formulir yang kompleks) riwayat file desainer sama sekali tidak berguna, dan jika 2 orang mengerjakan UI formulir sekaligus akan menghasilkan konflik gabungan dari neraka. Mengunci umumnya merupakan opsi yang mengerikan, tetapi dengan winforms sebenarnya adalah yang paling tidak jahat.

— Dan Neely

@DanNeely, Itu hanya salah satu alasan tim kami bermigrasi jauh dari kode WinForms. Alasan lain adalah bahwa perancang sangat rapuh, dan beberapa bentuk kompleks kami tidak dapat diedit secara visual. Kami akhirnya harus membuat perubahan langsung di codebehind - mungkin mengapa saya tidak ingat terlalu banyak pergolakan di sana. Itu dan pengguna kami yang bekerja dengan tampilan kepadatan tinggi benar-benar mendorong kami ke WPF. Proses yang menyakitkan dengan kurva belajar yang tinggi, tetapi hadiah yang bagus di akhir itu. Lagipula, kebanyakan cerita di backlog adalah untuk berbagai bagian aplikasi.

— Berin Loritsch

@BerinLoritsch sama di sini. Formulir Win membayar sebagian besar tagihan saya selama hampir satu dekade di pekerjaan saya sebelumnya, tetapi saya akan senang tidak pernah menyentuhnya lagi di masa depan.

— Dan Neely

2

Pendekatan lain yang mungkin untuk menghindari penggabungan yang terlambat dan besar adalah flag fitur : Anda melindungi perubahan Anda dengan flag yang dapat dikonfigurasi (idealnya dinamis) yang mencegahnya menjadi aktif sebelum dimaksudkan.

Ini memungkinkan Anda untuk menggabungkan perubahan Anda kembali ke salah satu masteratau cabang pengembangan bersama Anda tanpa merusak apa pun. Pengembang lain kemudian dapat menggabungkan perubahan ini kembali ke cabang fitur mereka (atau rebase cabang mereka sesuai).

Seperti jawaban lain telah menunjukkan ini harus dikombinasikan dengan solusi integrasi berkelanjutan.

Bendera fitur memiliki manfaat tambahan (misalnya, membuatnya mudah untuk melakukan tes A / B). Lihat artikel ini oleh Martin Fowler untuk informasi lebih lanjut.

— Florian Brucker
sumber

0

Kami mengikuti pendekatan cabang pengembangan terpisah untuk setiap fitur, dan kemudian kami menggabungkan cabang ke cabang QA untuk pengujian dalam lingkungan pengujian integrasi.

Setelah pengujian regresi dan integrasi selesai, kami dengan mudah memindahkan fitur yang siap digunakan, ke cabang rilis.

Jika semuanya berjalan dengan baik, kami menggabungkan cabang rilis kembali ke cabang master.

— emarshah
sumber

0

Sederhananya, melakukan dan menggabungkan sering mengurangi jendela peluang untuk menggabungkan konflik dan akan sangat mengurangi konflik. Bagian lainnya memang perencanaan oleh pimpinan, yang selanjutnya dapat memastikan bahwa pekerjaan mengalir dengan lancar.

Jawaban lain memberikan beberapa wawasan besar tentang praktik terbaik untuk komitmen dan hanya dengan mengikuti yang Anda mungkin akan mengurangi sebagian besar masalah gabungan Anda. Lebih banyak penggabungan hampir pasti suatu keharusan, tetapi untuk tim yang lebih kecil, pendekatan cabang-per-orang Anda mungkin cukup berhasil. Tentu saja, tidak ada salahnya (banyak) untuk melakukan praktik yang lebih luas!

Namun, sepertinya tidak ada yang menjawab salah satu pertanyaan Anda yang paling signifikan - apa yang harus dilakukan ketika Anda semua menyentuh area kode yang sama. Di sinilah berguna untuk memiliki seorang pemimpin yang akrab dengan basis kode dan dapat mengenali dependensi dari berbagai tugas. Jika mereka tidak mengatur waktu kerja dan melakukan, Anda mungkin akan berakhir dengan menggabungkan konflik dan resolusi baris demi baris. Mengatur waktu tugas jauh lebih sulit dengan tim yang lebih besar, tetapi dengan tim kecil memungkinkan untuk mengidentifikasi tugas-tugas yang saling bertentangan ini. Pemimpin kemudian bahkan dapat mengalihkan semua tugas terkait ke insinyur yang sama, untuk menghindari konflik sama sekali.

— Mars
sumber