Pilih strategi percabangan yang efektif

Layanan Azure DevOps | Azure DevOps Server 2022 - Azure DevOps Server 2019

Membuat cabang untuk repositori Team Foundation Version Control (TFVC) Anda berguna untuk mengisolasi risiko. Pertimbangkan beberapa tantangan yang biasanya dihadapi anggota tim ketika mereka mengerjakan proyek perangkat lunak yang dikelola oleh lebih dari lima atau sepuluh orang:

• Grup ini memiliki beberapa (atau mungkin beberapa) tim fitur yang berbeda, masing-masing mengerjakan serangkaian fungsionalitas yang cukup diskrit. Tetapi setiap tim juga bergantung pada fungsionalitas yang dibangun oleh tim lain. Anda perlu mengisolasi risiko perubahan yang diperkenalkan oleh pekerjaan yang dilakukan di setiap tim ini, namun akhirnya, Anda perlu menggabungkan semua upaya mereka bersama-sama menjadi satu produk.

• Tim uji membutuhkan versi kode yang stabil untuk diuji, namun secara bersamaan, pengembang perlu terus bergerak maju dengan fitur baru yang kadang-kadang akan menstabilkan produk.

• Perangkat lunak ini memiliki dua versi sebelumnya dan satu versi saat ini sedang berlangsung. Meskipun sebagian besar upaya pengembangan diinvestasikan dalam versi saat ini, versi sebelumnya masih harus didukung dengan rilis paket layanan sesekali, perbaikan penting dan patch keamanan, dan perubahan lainnya.

Artikel ini mengeksplorasi beberapa strategi percabangan umum untuk membantu Anda membuat keputusan yang tepat.

Tidak seperti cabang Git, yang tercakup dalam repositori, cabang TFVC adalah jalur yang tercakup dan tidak ringan. Atur bilah Anda untuk membuat cabang tinggi dan hanya cabang saat Anda memiliki kebutuhan akan kode atau isolasi rilis.

Utama Saja

Strategi Utama Saja dapat berbasis folder atau dengan folder utama dikonversi ke Cabang, untuk mengaktifkan fitur visibilitas tambahan. Anda menerapkan perubahan Anda pada cabang utama dan secara opsional menunjukkan tonggak pengembangan dan rilis dengan label.

RISIKO: Mutabilitas dan kurangnya riwayat dengan label TFVC dapat menambah risiko kontrol perubahan.

Mulailah dengan satu-satunya strategi percabangan utama, cabang secara strategis dan mengadopsi strategi lain untuk berevolusi menjadi strategi yang lebih kompleks sesuai kebutuhan.

Isolasi pengembangan

Ketika Anda perlu memelihara dan melindungi cabang utama yang stabil, Anda dapat mencabangkan satu atau beberapa cabang dev dari utama. Ini memungkinkan isolasi dan pengembangan bersamaan. Pekerjaan dapat diisolasi di cabang pengembangan berdasarkan fitur, organisasi, atau kolaborasi sementara.

Ada kemungkinan bahwa ada perubahan di cabang utama . Selalu teruskan integrasi (FI) utama ke cabang dev dan atasi konflik penggabungan. Kemudian reverse integrate (RI) berubah kembali ke utama. Pertahankan bilah kualitas yang sama di seluruh cabang. Bangun dan jalankan pengujian verifikasi build (BVTs) dengan cara yang sama seperti yang Anda lakukan di utama.

CATATAN: Dengan strategi ini, tim cenderung menyimpan cabang dev selamanya, berpotensi membangun riwayat tiket penggabungan besar.

Isolasi fitur

Isolasi fitur adalah turunan khusus dari isolasi pengembangan, memungkinkan Anda untuk mencabangkan satu atau beberapa cabang fitur dari cabang utama, seperti yang ditunjukkan, atau dari cabang pengembangan Anda.

Ketika Anda perlu mengerjakan fitur tertentu, ada baiknya membuat cabang fitur.

Pertahankan masa pakai fitur berfungsi dan cabang fitur terkait berumur pendek. Teruskan perubahan integrasi (FI) dari cabang induk sering. Integrasi terbalik (RI) kembali ke induk hanya ketika beberapa kriteria tim yang disepakati, misalnya definisi selesai, terpenuhi. Putar kembali fitur utama bisa mahal dan dapat mengatur ulang pengujian.

Isolasi rilis

Isolasi rilis memperkenalkan satu atau beberapa cabang rilis dari utama. Strategi ini memungkinkan manajemen rilis bersamaan, beberapa rilis paralel, dan snapshot basis kode pada waktu rilis.

Ketika rilis siap untuk dikunci, saatnya untuk membuat cabang baru untuk rilis.

Jangan pernah meneruskan integrasi (FI) dari utama. Kunci cabang rilis menggunakan izin akses, untuk mencegah modifikasi yang tidak diinginkan pada rilis. Patch dan perbaikan panas yang dibuat ke cabang rilis dapat diintegrasikan balik (RI) kembali ke cabang utama .

CATATAN: Tidak ada skenario percabangan yang tidak dapat diubah, itulah sebabnya Anda melihat perbaikan darurat yang dilakukan pada cabang rilis. Berevolusi setiap strategi agar sesuai dengan kebutuhan Anda, tanpa kehilangan pandangan akan kompleksitas dan biaya terkait.

Layanan dan isolasi rilis

Strategi Layanan dan Isolasi Rilis memperkenalkan cabang layanan . Strategi ini memungkinkan manajemen layanan bersamaan dari paket layanan, dan snapshot basis kode pada waktu rilis.

Gunakan strategi ini jika Anda memerlukan model layanan bagi pelanggan untuk meningkatkan ke rilis utama berikutnya dan paket layanan tambahan per rilis.

Seperti isolasi rilis, isolasi layanan dan cabang rilis dibuat ketika rilis siap untuk dikunci. Jangan pernah meneruskan integrasi dari layanan utama ke layanan, atau dari layanan ke rilis. Kunci cabang rilis untuk mencegah modifikasi. Perubahan layanan di masa mendatang dapat dilakukan pada cabang layanan .

Buat cabang layanan dan rilis baru untuk rilis berikutnya jika Anda memerlukan tingkat isolasi tersebut.

Layanan, perbaikan, isolasi rilis

Meskipun tidak direkomendasikan, Anda dapat terus mengembangkan strategi, dengan memperkenalkan cabang perbaikan tambahan dan skenario rilis terkait.

Pada titik ini, Anda telah berhasil menjelajahi beberapa skenario percabangan TFVC umum. Anda dapat mengembangkannya, atau menyelidiki strategi lain seperti pengalih fitur, mengaktifkan dan menonaktifkan fitur untuk menentukan apakah fitur tersedia pada waktu proses.

Q&A

Mengapa cabang harus berumur pendek?

Dengan menjaga cabang tetap berumur pendek, konflik penggabungan disimpan seserang mungkin.

Mengapa hanya cabang jika perlu?

Untuk merangkul DevOps, Anda perlu mengandalkan otomatisasi build, pengujian, dan penyebaran. Perubahan terus menerus, sering, dan menggabungkan operasi yang lebih menantang karena konflik penggabungan sering memerlukan intervensi manual. Oleh karena itu disarankan untuk menghindari percabangan dan mengandalkan strategi lain, seperti pengalihan fitur.

Mengapa menghapus cabang?

Tujuan Anda adalah untuk mendapatkan perubahan kembali ke utama sesegera mungkin, untuk mengurangi konsekuensi penggabungan jangka panjang. Cabang sementara, tidak digunakan, dan berlimpah menyebabkan kebingungan dan overhead bagi tim.

Dapatkah basis kode bercabang di seluruh proyek?

Ya. Tidak disarankan, kecuali tim harus berbagi sumber dan tidak dapat berbagi proses umum.

Bagaimana dengan strategi promosi kode?

Strategi Promosi Kode terasa seperti peninggalan dari era pengembangan air terjun. Biasanya dengan siklus pengujian yang panjang, dan tim pengembangan dan pengujian terpisah. Strategi ini tidak lagi direkomendasikan. Untuk informasi selengkapnya tentang strategi ini, lihat panduan percabangan.

Saat menggabungkan dev ke cabang utama , mengapa tidak ada perubahan yang terdeteksi?

Anda kemungkinan telah mengabaikan perubahan dalam penggabungan sebelumnya, misalnya, menggunakan keep source opsi resolusi konflik. Lihat menggabungkan cabang pengembangan ke utama: tidak ada perubahan untuk digabungkan untuk detailnya.

Apakah ada kesamaan antara strategi cabang TFVC dan Git?

Strategi percabangan Isolasi Fitur TFVC mirip dengan cabang topik Git.

Penulis: Jesse Houwing, Marcus Fernandez, Mike Fourie, dan Willy Schaub dari ALM | DevOps Rangers. Anda dapat menghubungi mereka di sini.

(c) 2015 Microsoft Corporation. Semua hak dilindungi undang-undang. Dokumen ini disediakan "apa adanya." Informasi dan tampilan yang dinyatakan dalam dokumen ini, termasuk URL dan referensi situs Web Internet lainnya, dapat berubah tanpa pemberitahuan. Anda menanggung risiko menggunakannya.

Dokumen ini tidak memberikan hak hukum apa pun kepada Anda atas kekayaan intelektual apa pun di semua produk Microsoft. Anda dapat menyalin dan menggunakan dokumen ini sebagai referensi internal.