Pengembang diblokir dengan menunggu kode untuk bergabung dari cabang lain menggunakan GitFlow


17

Tim kami baru saja beralih dari FogBugz & Kiln / Mercurial ke Jira & Stash / Git. Kami menggunakan model Git Flow untuk bercabang, menambahkan cabang subtask dari cabang fitur (terkait dengan subtitle Jira dari fitur Jira). Kami menggunakan Stash untuk menetapkan resensi ketika kami membuat permintaan tarik untuk bergabung kembali ke cabang induk (biasanya berkembang tetapi untuk subtugas kembali ke cabang fitur).

Masalah yang kami temukan adalah bahwa bahkan dengan perencanaan dan pemecahan kasus fitur terbaik, ketika beberapa pengembang bekerja bersama pada fitur yang sama, katakan pada front-end dan back-end, jika mereka bekerja pada kode saling tergantung yang di cabang terpisah satu pengembang akhirnya memblokir yang lain.

Kami telah mencoba menarik di antara cabang satu sama lain saat kami berkembang. Kami juga telah mencoba membuat cabang integrasi lokal yang dapat ditarik oleh setiap pengembang dari beberapa cabang untuk menguji integrasi ketika mereka berkembang. Akhirnya, dan ini tampaknya bekerja mungkin yang terbaik bagi kami sejauh ini, meskipun dengan sedikit lebih banyak overhead, kami telah mencoba membuat cabang integrasi dari cabang fitur langsung dari kelelawar. Ketika cabang subtugas (di luar cabang fitur) siap untuk permintaan tarik dan tinjauan kode, kami juga secara manual menggabungkan set perubahan itu ke cabang integrasi fitur ini. Kemudian semua pengembang yang tertarik dapat menarik dari cabang integrasi tersebut ke cabang subtugas lain yang bergantung. Ini mencegah siapa pun dari menunggu cabang mana pun yang mereka andalkan untuk lulus tinjauan kode.

Saya tahu ini bukan masalah Git - ini berkaitan dengan bekerja pada kode yang saling tergantung di banyak cabang, dicampur dengan proses dan budaya kerja kami sendiri. Jika kami tidak memiliki kebijakan peninjauan kode yang ketat untuk dikembangkan (cabang integrasi yang benar) maka pengembang 1 dapat bergabung untuk mengembangkan dari pengembang 2. Komplikasi lain adalah kita juga diharuskan untuk melakukan beberapa pengujian pendahuluan sebagai bagian dari proses peninjauan kode sebelum menyerahkan fitur ke QA. Ini berarti bahwa bahkan jika pengembang front-end 1 menarik langsung dari cabang pengembang back-end 2 saat mereka pergi, jika pengembang back-end 2 selesai dan permintaan tarikannya duduk dalam tinjauan kode selama seminggu, maka pengembang front-end 2 secara teknis tidak dapat membuat permintaan tarik / tinjauan kode karena pengkodeannya tidak bisa menguji karena pengembang back-end 2 '

Intinya adalah kita menemukan diri kita dalam pendekatan yang jauh lebih serial daripada paralel dalam contoh ini, tergantung pada rute mana kita pergi, dan ingin menemukan proses untuk digunakan untuk menghindari ini.

Hal terakhir yang akan saya sebutkan adalah kami menyadari dengan membagikan kode lintas cabang yang belum ditinjau kode dan diselesaikan namun pada dasarnya kami menggunakan kode beta orang lain. Sampai batas tertentu saya tidak berpikir kita bisa menghindarinya dan mau menerimanya sampai tingkat tertentu.


Hanya memverifikasi - review kode sedang dilakukan pada penggabungan tugas ke fitur? dan tidak ada ulasan kode pada penggabungan fitur untuk dikembangkan?

Tergantung. Kami memiliki aturan praktis bahwa tidak ada case Jira yang sesuai dengan cabang kami langsung memeriksa kode dan yang tidak bertindak sebagai kasus "payung" dalam arti hirarki membutuhkan waktu lebih dari 2 hari. Jadi jika case feature membutuhkan <= 2 hari, maka akan ada review kode untuk menggabungkan fitur untuk dikembangkan. Jika ada subtugas, begitu mereka semua digabung ke dalam tiket fitur mereka, seseorang benar-benar melihat permintaan tarik untuk menggabungkan cabang fitur itu menjadi pengembangan, tetapi tidak pada level yang sama dari tinjauan kode, karena semua subtugas sudah melalui proses itu.
fogwolf

Jawaban:


11

Masalahnya mungkin juga terletak pada pemisahan tugas yang terlalu kaku antara pengembangan back-end dan front-end.

Jika pengembang front-end membutuhkan API baru, apakah tidak memungkinkan untuk membuatnya membuat API dummy di ujung belakang (selalu mengembalikan nilai yang sama misalnya) untuk memvalidasi tata letak? Kemudian komit implementasi parsial itu dengan sebuah rintisan, dan di kedua kalinya, pengembang back-end akan mengimplementasikan fitur nyata.

Dengan memutus ketergantungan, Anda akan mendapatkan aliran yang lebih baik dan Anda tidak harus menghentikan semuanya menunggu satu tugas yang bertindak sebagai hambatan.


Saya memang memikirkan hal ini, tetapi ini bukan bagian dari proses pengembangan kami saat ini dan merupakan biaya tambahan. Saya tidak berpikir masalahnya sepenuhnya pengembang front-end tidak dapat mengakses kode pengembang back-end untuk menguji selama pengembangan, meskipun. Ini lebih lanjut tentang peninjau kode yang melakukan tes asap seluruh integrasi (tidak ada yang diejek atau di-stub) sebelum kita mengirimkannya ke QA.
fogwolf

6
Meskipun ini bukan bagian dari proses pengembangan Anda, apakah ini overhead tambahan daripada memiliki dua pengembang yang memutar-mutar ibu jari mereka selama tiga hari menunggu orang lain untuk melakukan kode mereka? Anda punya 8 jam waktu pengembang yang terbuang untuk setiap thumb-twiddler. Bandingkan dengan waktu yang dibutuhkan untuk mematikan dependensi backend.
Greg Burghardt

5

Masalah Anda: Pengembang A cabang dari Master, pengembang B cabang dari Master, keduanya bekerja pada fitur terkait erat, dan fakta yang tak terhindarkan bahwa penggabungan ke dalam cabang Master sulit karena konflik yang tak terhindarkan adalah apa yang menahan semua orang.

Jika ini dapat diprediksi, maka A dan B pertama-tama dapat membuat cabang bersama, lalu masing-masing cabang untuk pekerjaan terpisah mereka dari cabang bersama ini, menggabungkan masing-masing pekerjaan terpisah mereka ke cabang bersama, dan sekarang Anda memiliki cabang bebas konflik yang jauh lebih mudah diintegrasikan.


0

Jika pengembang 1 bekerja pada fitur A, dan pengembang 2 selesai bekerja pada fitur B yang tergantung pada fitur A, maka tidak ada jalan lain - penggabungan fitur B sedang ditahan. Anda tidak dapat mengujinya tanpa fitur A, dan belum ada gunanya meninjaunya lagi karena kemajuan lebih jauh dalam fitur A dapat menyebabkan perubahan dalam fitur B.

Namun itu tidak berarti bahwa pengembang 2 ditahan! Pengembang 2 dapat mulai bekerja pada fitur C, dan kembali ke siklus perbaikan-periksa fitur B setelah fitur A selesai. Saya tahu bahwa pengalihan konteks tidak optimal, tetapi karena waktu yang diperlukan untuk menyelesaikan fitur A mungkin diukur dalam beberapa hari, itu tidak terlalu buruk (Anda tidak menariknya keluar dari "The Zone" untuk tugas sampingan 15 menit)


Tentu, tapi ini bukan masalahnya. Ini lebih tentang satu fitur proses menjadi sedikit lebih serial dari yang seharusnya. Jika kami dijadwalkan untuk merilis fitur pada tanggal x, dan tiket tidak dapat ditinjau secara paralel, hal ini menyebabkan perkiraan kami tidak aktif dan berpotensi mendorong keluarnya rilis.
fogwolf

0

Satu hal yang dapat Anda lakukan untuk membantu situasi adalah memperhatikan cara-cara untuk mempersingkat siklus pengembangan.

Dalam kasus di mana pengembang menunggu fitur dari pengembang lain, adakah cara sebagian pengembang pertama dapat melalui peninjauan dan integrasi sebelum seluruh fitur untuk membebaskan blok?

Apakah ada cara untuk memecah fitur menjadi unit kerja yang lebih kecil untuk menjaga siklus integrasi tetap berjalan?

Juga, berapa lama waktu yang dibutuhkan untuk integrasi? Jika ada putaran panjang di build atau integrasi, itu bisa memperlambat seluruh antrian. Lihat apakah ada yang dapat Anda lakukan untuk mempercepat waktu pembuatan sehingga antrian dibebaskan lebih cepat.


Inilah harapan utama saya. Saya tidak berpikir kita bisa menghilangkan masalah tetapi dengan menjadi lebih nyaman dengan alur kerja baru saya berharap kita akan menjadi lebih baik dalam perencanaan dan memecah pekerjaan kita secara kolaboratif dalam sistem baru ini untuk meminimalkan masalah. Hanya memeriksa untuk melihat apakah ada orang yang mengalami hal serupa, dan memiliki proses-bijaksana atau terkait dengan model percabangan yang kami gunakan yang dapat membantu. Terima kasih.
fogwolf
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.