Bagaimana kita hanya bisa memasukkan fitur yang siap dirilis dalam rilis produksi setiap minggu?

Saya seorang pengembang perangkat lunak di tim tangkas yang cukup besar (kami memiliki delapan pengembang aktif membuat perubahan ke repositori kode tunggal). Setiap dua minggu, kami mendorong versi baru perangkat lunak kami ke produksi. Inilah alur kerja kami saat ini:

• Saat memulai tugas baru, pengembang membuat "cabang fitur" dari cabang pengembangan utama (kami menggunakan git ) dan mengerjakan cabang baru ini
• Setelah pengembang menyelesaikan tugasnya, mereka menggabungkan cabang fitur mereka kembali ke cabang pengembangan
• Pengembang menggabungkan cabang pengembangan ke cabang QA.
• Membangun dipicu dari cabang QA. Output dari bangunan ini digunakan ke lingkungan QA kami untuk memungkinkan penguji memulai pengujian mereka.

Sangat umum bagi penguji kami untuk menemukan masalah dengan fitur-fitur baru yang telah digabungkan ke cabang QA. Ini berarti bahwa pada suatu waktu tertentu, lingkungan QA kemungkinan berisi beberapa fitur baru - beberapa telah teruji dan bebas bug, dan beberapa rusak. Hal ini membuat pelepasan menjadi sulit karena jarang bahwa QA build dalam keadaan siap produksi.

Untuk mengurangi ini, kami telah mencoba untuk memulai "pembekuan QA" yang berarti pengembang tidak menggabungkan cabang pengembangan kami ke cabang QA beberapa hari sebelum rilis. Perbaikan bug ke lingkungan QA dilakukan langsung di cabang QA dan digabung ke cabang pengembangan. Secara teoritis, ini menjaga fitur baru yang rusak dari QA sambil tetap memungkinkan kami untuk memperbaiki masalah yang sudah ada di QA.

Walaupun konsep "pembekuan QA" ini telah sebagian berhasil, sulit untuk dikoordinasikan dan orang-orang sering bingung tentang apakah mereka diizinkan untuk bergabung dengan QA. Sulit juga untuk menetapkan tenggat waktu "pembekuan QA" - semua orang menyukai gagasan ruang bernapas di antara pembekuan dan rilis, tetapi dalam praktiknya, mereka lebih suka memiliki fitur mereka di rilis berikutnya daripada menghormati tenggat waktu.

Apakah ada cara yang lebih baik untuk memastikan bahwa kami memiliki bangunan yang bersih untuk rilis kami setiap minggu?

Ada beberapa masalah di sekitar ini yang menyebabkan masalah yang Anda alami.

Yang pertama adalah cabang QA yang sudah berjalan lama. Memiliki cabang yang berjalan lama yang sejajar dengan jalur utama pengembangan dapat menjadi sumber kebingungan karena ada berbagai upaya yang perlu direplikasi di cabang QA dan jalur utama. Ini berarti bahwa Anda sedang memeriksa perbaikan ke cabang QA yang perlu digabungkan ke jalur utama (bukan hal yang buruk), atau Anda memeriksa jalur utama yang akan bergabung ke cabang QA (sumber kemungkinan bug) .

Masalah lain dengan cabang paralel yang sudah berjalan lama adalah kemungkinan file menjadi tidak sinkron. Perbaikan kode yang tidak pernah digabungkan kembali, atau konfigurasi yang diperlukan untuk pembuatan produksi yang tidak pernah diuji dan merupakan bagian dari arus utama pengembangan.

Selanjutnya, Anda memiliki peran yang mulai dilanggar. Ini berarti bahwa peran pengemasan (lebih lanjut tentang ini nanti) tidak cukup terisolasi.

Dalam model git-flow , cabang rilis bercabang dari pengembangan ( bukan pengembangan digabung ke QA) dan semua perbaikan diperiksa ke cabang rilis dan kemudian digabungkan kembali ke cabang pengembangan.

Beberapa filosofi percabangan dapat ditemukan dalam Advanced SCM Branching Strategies (saya anggap sebagai pembacaan yang sangat baik). Ini berfokus pada peran yang mungkin diambil setiap cabang. Cabang rilis mengambil peran pengemasan.

Peran pengemasan sering dikacaukan dengan akumulasi atau, lebih umum, peran utama. Setelah pengembangan dan pemeliharaan yang dimaksud telah dilakukan dan akumulasi apa pun telah dilakukan, sekarang saatnya untuk mempersiapkan kode untuk dirilis. Upaya semacam itu mungkin tidak sepele, membutuhkan tim insinyur rilis dan perbaikan tambahan di luar yang sudah dilakukan. Kebijakan pada cabang pengemasan secara signifikan berbeda dari pada cabang pemeliharaan, seperti peran kemasan menyarankan, hanya perubahan yang diperlukan untuk membuat produk yang dapat dilepas harus ditangani.

• Cabang dari titik pengembangan ke cabang rilis. Cabang rilis tempat QA dibangun mendapatkan satu cabang dan tidak ada penggabungan dari pengembangan.
  • Jika Anda ingin menyusuri jalan itu, dengan penamaan dan pengait yang konsisten, adalah mungkin untuk mencegah penggabungan dari dilakukan ke cabang rilis.
• Perbaiki semua yang perlu diperbaiki di cabang rilis dan gabungkan perubahan itu kembali ke jalur utama.
• Di akhir upaya rilis, gabungkan cabang rilis ke cabang "rilis pergi ke sini" dan beri tag seperti itu.
  • Beberapa situs tidak memiliki cabang "rilis ke sini" dan biarkan saja cabang rilis tergantung dengan tag.

Seseorang harus secara serius mempertimbangkan untuk menerapkan keseluruhan aliran git di tempatnya. Ini tidak terlalu jauh dari apa yang sedang dilakukan saat ini dan menempatkan beberapa disiplin dan konsistensi ke dalam arti setiap cabang dan bagaimana masing-masing cabang berinteraksi dengan yang lain.

Masalahnya bagi saya adalah bahwa Anda memiliki cabang QA tunggal.

Untuk setiap rilis, buat cabang QA terpisah dari induk utama / induk pengembangan. Kemudian gabungkan hanya perbaikan untuk bug untuk fitur di cabang itu - tidak pernah fitur baru. Lakukan tes QA cabang itu.

Dengan cara ini, "pembekuan" cukup jelas - itu dalam nama cabang. Anda dapat menggunakan sesuatu seperti, saya tidak tahu release/26/10/2015,. Maka jelas bahwa tidak ada yang harus menggabungkan fitur baru setelah ini.

Ini sangat membantu jika Anda bahkan tidak bercabang sampai pembekuan. Orang-orang dapat bergabung untuk menguasai kapan saja, itu tidak akan menjadi bagian dari rilis ini jika tidak dilakukan pada waktunya untuk diuji.

Tidak memiliki satu cabang QA yang telah berjalan lama, itu hanya mengemis masalah. Fork dari cabang pengembangan utama untuk setiap rilis dan QA cabang itu.

Anda agak dipetakan ke model percabangan Development-MAIN-Production yang terlihat di bawah ini. Area di atas UTAMA dikatakan sebagai area pengembangan. Area di bawah UTAMA adalah area produksi.

Sorotan dari model ini yang saya anggap relevan untuk Anda:

• Devs Anda perlu Teruskan Integrasi (FI) (FI = bergabung jauh dari MAIN) sering (2-3 kali seminggu) ke cabang DEV mereka untuk memastikan perubahan terbaru mereka selalu mempertimbangkan perkembangan keseluruhan terbaru.
• Pengembang Anda perlu Membalikkan Integrasi (RI) (RI = bergabung ke MAIN) di cabang TEST hanya ketika mereka telah mencapai tonggak penyelesaian fitur yang ingin mereka paparkan ke QA dan mereka siap memberikan perbaikan cepat di Menanggapi umpan balik QA. Perbaikan akan dilakukan pada cabang TEST dan segera FI di cabang DEV mereka.
• Jangan pernah RI dari cabang DEV ke MAIN
• Selalu RI dari cabang TEST ke MAIN, secara eksklusif ketika QA Anda menganggap kualitas TEST baik-baik saja. Pertahankan ambang batas kualitas tinggi untuk bergabung ke dalam MAIN. Paling tidak, Manajer Produk Anda harus dapat selalu mendemonstrasikan versi kerja Produk Anda dari komitmen terbaru di MAIN.
• Buat cabang di area produksi hanya sesuai kebutuhan. Server build Anda harus selalu menandai semua cabang, termasuk yang dari area pengembangan, dan sumber build / rilis apa pun harus dapat diidentifikasi setiap saat terlepas dari cabang mana asalnya.
• Ambil rilis untuk produksi hanya dari MAIN atau area produksi. Jika nanti Anda perlu menyediakan perbaikan untuk versi rilis yang tepat (yaitu Anda tidak bisa hanya memberikan versi terbaru dari MAIN), buat cabang di area produksi dari tag UTAMA dari rilis yang salah, ketika perbaikan diperlukan. Selalu perbaiki masalah pada cabang HotFix dan kemudian segera RI menjadi UTAMA dan FI ke UJI.

Saya menduga Anda memiliki masalah karena:

• Devs RI Anda menjadi kode TEST yang tidak memiliki fitur-tonggak lengkap
• Devs Anda RI ke TEST tanpa mendapatkan lampu hijau dari QA (yaitu QA tidak mengendalikan apa yang akan disuntikkan ke TEST)
• Ketika QA melaporkan bug pada TEST, pengembang Anda memperbaikinya pada cabang DEV mereka dan kemudian RI ke TEST. Ini adalah praktik buruk utama karena penggabungan akan selalu menghasilkan omong kosong dev lain yang tidak lengkap. Mereka harus selalu memperbaikinya pada TEST dan kemudian FI ke cabang DEV mereka. Jika tidak diperbaiki pada TEST, mereka memberikan omong kosong total di tempat pertama dan Anda memiliki masalah yang lebih besar.
• Pengembang Anda tidak cukup sering FI dari TEST sehingga mereka mendestabilisasi TEST setiap kali mereka mengirim ke sana. Ini adalah keseimbangan seni seberapa sering untuk FI ke DEV. Tunda terlalu banyak dan akan sangat mahal & berisiko tepat sebelum pengiriman, yang tidak pernah Anda inginkan. Lakukan terlalu sering dan Anda tidak mendapatkan pekerjaan dev yang sebenarnya dilakukan jika Anda tumpang tindih dengan pekerjaan yang disampaikan oleh orang lain di TEST dalam waktu yang bersamaan.

Ketika saya mengerti pertanyaan Anda memiliki dua masalah. (a) fitur rusak sedang digabungkan dengan fitur bagus yang ingin Anda rilis; (B) Anda ingin dapat melepaskan fitur yang baik sambil menahan yang rusak. Sebagai kendala pada solusi yang mungkin, saya berasumsi Anda ingin pengujian QA final / resmi Anda terjadi pada cabang terintegrasi yang berisi semua fitur yang dijadwalkan untuk rilis berikutnya.

Terlepas dari model percabangan SCM Anda, saya sarankan Anda mencoba satu atau keduanya berikut ini:

1. Tetapkan sumber daya QA untuk setiap tim fitur. Mintalah mereka melakukan beberapa pengujian fitur berdasarkan build dari cabang fitur, dan beri mereka wewenang untuk memutuskan kapan suatu fitur cukup baik untuk digabung. Idealnya, minta mereka bekerja secara kolaboratif dengan (sisa) tim fitur, sehingga hal-hal diuji segera setelah ditulis. (Catatan ini tidak berarti mereka harus melakukan semua pengujian sendiri.)
2. Gunakan fitur toggle, sebagai ganti cabang fitur atau sebagai tambahan. Jika dilakukan dengan benar, fitur toggle memungkinkan Anda mematikan fitur yang rusak tanpa mencoba mencabutnya dari kode, sehingga Anda dapat menguji dan melepaskan fitur lainnya. Jenis beralih yang saya bicarakan tidak dapat diakses oleh pelanggan; Anda tidak ingin menguji jumlah kombinasi yang meningkat secara eksponensial. Anda mengatur sakelar pada cabang QA agar sesuai dengan fitur yang Anda rencanakan untuk dirilis, dan jika paket berubah karena fitur tidak siap, Anda mengubah sakelar itu.

Salah satu solusi yang sangat sederhana yang saya lihat bekerja di tim yang sedikit lebih besar dari milik Anda adalah membuat semua orang bekerja dan menggunakan dari satu cabang.

Anda mengatakan tim ini gesit tetapi tidak jelas apakah Anda bekerja dalam sprint (yaitu Scrum) atau pendekatan aliran yang lebih berkelanjutan (yaitu Kanban). Anggap Anda sedang melakukan sprint, tujuan tim adalah membuat kode dapat dirilis pada akhir setiap sprint, untuk rilis Anda setiap dua minggu. Tidak ada kebingungan apakah satu fitur akan merusak yang lain karena mereka semua telah dikembangkan bersama. Penguji mungkin bisa mendapatkan akses ke fitur dalam bongkahan yang lebih kecil karena biaya yang harus dikeluarkan pengembang untuk mengirimkannya lebih rendah. Dan Anda tidak benar-benar membutuhkan QA-Freeze, sebagai gantinya semua orang tahu kapan akhir sprint adalah dan tidak seharusnya melakukan pekerjaan yang tidak dapat mereka selesaikan, atau meninggalkannya dalam status dapat digunakan (yaitu dinonaktifkan).

Jelas ada pro dan kontra untuk pendekatan apa pun, saya menyajikan ini sebagai pilihan belum tentu 'cara terbaik'.

Alasan Anda mendapatkan masalah ini adalah karena kode Anda dirilis ke QA tidak berkualitas cukup baik (dan siapa pun ?!), jadi Anda harus mulai mendapatkan rilis yang lebih baik ke QA sehingga mereka tidak perlu terlalu sering menerima perbaikan besar. cara paling sederhana untuk melakukan ini adalah dengan memperkenalkan cabang perantara yang Anda lepaskan (sebut saja uji). Ini masih dalam pengembangan pengiriman, tetapi memungkinkan pengembang untuk mendorongnya untuk terus bekerja, sementara juga memiliki cabang terintegrasi yang harus berkualitas cukup baik untuk dikirim ke QA.

Pengujian integrasi dapat dilakukan pada cabang ini untuk menemukan bug yang saat ini ditemukan QA, bug dapat diperbaiki pada cabang asli dan kemudian digabung lagi, dan lagi sampai benar atau bug dapat diperbaiki pada cabang ini secara langsung (saya sarankan bekas). Setelah lulus uji dasar, maka dapat dikirim ke QA untuk 'jari lengket pengguna dan mereka-lakukan-apa?' pengujian.

Jadi pendekatan ini dirancang untuk melindungi cabang QA dari fitur pengembangan yang rusak - apakah itu karena fitur tersebut tidak dikodekan dengan baik atau apakah ada masalah integrasi yang tidak terduga. Hanya cabang dev yang lulus pengujian integrasi yang dapat dipromosikan ke QA.