Cabang secara strategis

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

Kode sumber adalah aset penting dalam upaya pengembangan Anda. Tetapi ini bisa menjadi tantangan untuk mengelola dan mengembangkan file sumber secara efektif ketika beberapa pengembang bekerja secara bersamaan pada pembaruan file. Anda dapat menggunakan sistem kontrol versi untuk menyimpan kode sumber di repositori bersama, untuk mengisolasi upaya pengembangan paralel, untuk mengintegrasikan perubahan kode, dan memulihkan versi file sebelumnya. Elemen kunci dalam kontrol versi adalah pencabangan yang memungkinkan pengembangan simultan. Jika Anda bercabang secara strategis, Anda dapat mempertahankan urutan dan konsistensi beberapa versi perangkat lunak Anda.

Team Foundation menyediakan sistem kontrol versi yang fleksibel dan andal. Anda dapat menggunakan kontrol versi Team Foundation untuk mengelola beberapa revisi selama pengembangan kode sumber, dokumen, item kerja, dan informasi penting lainnya yang dikerjakan oleh tim Anda.

Bagaimana tim Anda mengelola kode saat memperkenalkan beberapa perubahan secara bersamaan melalui beberapa rilis proyek?

Saat Anda bekerja dengan sistem kontrol versi, Anda harus mempertimbangkan cara menyiapkan struktur cabang. Anda dapat membuat cabang dengan mencerminkan file kode sumber. Kemudian Anda dapat mengubah cabang tanpa memengaruhi sumbernya. Misalnya, seperti yang ditunjukkan struktur cabang dalam ilustrasi berikut, cabang MAIN berisi fungsionalitas lengkap yang telah lulus pengujian integrasi, dan cabang DEVELOPMENT berisi kode yang sedang dibangun. Ketika fungsionalitas baru di cabang DEVELOPMENT selesai dan dapat lulus pengujian integrasi, Anda dapat mempromosikan kode dari cabang DEVELOPMENT ke cabang UTAMA. Proses ini disebut sebagai integrasi terbalik. Sebaliknya, jika Anda menggabungkan kode dari cabang UTAMA ke cabang PENGEMBANGAN, prosesnya disebut sebagai integrasi penerusan.

Untuk informasi selengkapnya tentang cara membuat dan menggabungkan cabang kode, lihat halaman berikut ini di situs Web CodePlex: Team Foundation Server Branching Guide 2.0.

Percabangan dan penggabungan memerlukan prinsip-prinsip berikut:

1. Setiap cabang harus memiliki kebijakan yang ditentukan tentang cara mengintegrasikan kode ke dalam cabang ini. Misalnya, dalam struktur cabang ilustrasi sebelumnya, Anda dapat menetapkan anggota tim untuk memiliki dan mengelola cabang UTAMA. Anggota ini bertanggung jawab untuk melakukan operasi cabang awal, mengintegrasikan kembali perubahan dari cabang PENGEMBANGAN ke cabang UTAMA, dan meneruskan integrasi perubahan dari cabang UTAMA ke cabang PENGEMBANGAN. Integrasi penerusan penting ketika cabang MAIN juga mengintegrasikan perubahan dari cabang lain.

2. Cabang UTAMA harus berisi kode yang telah lulus pengujian integrasi sehingga selalu siap untuk rilis.

3. Cabang PENGEMBANGAN (atau pekerjaan) terus berkembang karena anggota tim memeriksa perubahan secara berkala.

4. Label adalah rekam jepret file di cabang pada waktu tertentu.

   Untuk informasi selengkapnya, lihat Menggunakan label untuk mengambil rekam jepret file Anda.

Team Foundation Build memungkinkan Anda memilih dari beberapa jenis build untuk cabang Anda: manual, berkelanjutan, terjaga, bergulir, dan terjadwal. Sebaiknya cabang MAIN memiliki jenis build check-in yang terjaga. Ini berarti bahwa cabang PENGEMBANGAN harus melewati semua persyaratan untuk cabang MAIN sebelum Anda dapat melakukan integrasi terbalik. Cabang PENGEMBANGAN harus menjalankan jenis build berkelanjutan karena tim Anda harus tahu sesegera mungkin ketika check-in baru memengaruhi cabang PENGEMBANGAN.

Seberapa sering tim Anda harus berintegrasi balik dan maju berintegrasi?

Seperti yang ditunjukkan dalam ilustrasi berikut, integrasi terbalik dan integrasi maju harus terjadi setidaknya ketika Anda menyelesaikan cerita pengguna. Meskipun setiap tim mungkin menentukan kelengkapan secara berbeda, penyelesaian cerita pengguna umumnya berarti Anda menyelesaikan fungsionalitas dan pengujian unit yang sesuai. Anda dapat berintegrasi balik ke cabang UTAMA hanya setelah pengujian unit telah memverifikasi stabilitas cabang PENGEMBANGAN.

Jika Anda memiliki lebih dari satu cabang kerja (DEVELOPMENT), integrasi ke depan ke semua cabang kerja harus terjadi segera setelah cabang apa pun terintegrasi ke cabang UTAMA. Karena cabang MAIN tetap stabil, integrasi ke depan aman. Konflik atau kegagalan di cabang kerja mungkin terjadi karena Anda tidak dapat menjamin bahwa cabang kerja stabil.

Penting bagi Anda untuk menyelesaikan semua konflik sesegera mungkin. Dengan menggunakan check-in terjaga untuk cabang UTAMA, Anda membantu membuat integrasi terbalik jauh lebih mudah karena gerbang kualitas membantu menghindari konflik atau kesalahan di cabang UTAMA. Untuk informasi selengkapnya, lihat Cek masuk ke folder yang dikontrol oleh proses build check-in yang terjaga.

Bagaimana tim Anda mengelola sumber yang menerapkan cerita pengguna yang berbeda?

Seperti yang ditunjukkan oleh ilustrasi berikut, Anda dapat memeriksa perubahan pada cabang kerja secara berkala untuk menyelesaikan cerita pengguna. Anda dapat menerapkan beberapa cerita pengguna di cabang yang sama secara bersamaan. Namun, Anda dapat berintegrasi balik ke cabang MAIN hanya ketika Anda menyelesaikan semua pekerjaan yang sedang berlangsung. Disarankan agar Anda mengelompokkan cerita pengguna dengan ukuran yang sama karena Anda tidak ingin cerita pengguna besar memblokir integrasi banyak yang kecil. Anda dapat membagi dua set cerita pengguna menjadi dua cabang.

Kapan tim harus menambahkan cabang?

Anda harus membuat cabang dalam situasi berikut:

• Ketika Anda harus merilis kode pada jadwal/siklus yang berbeda dari cabang yang ada.

• Saat kode Anda memerlukan kebijakan cabang yang berbeda. Jika Anda membuat cabang baru yang memiliki kebijakan baru, Anda dapat menambahkan nilai strategis ke proyek Anda.

• Ketika fungsionalitas dirilis ke pelanggan dan tim Anda berencana untuk membuat perubahan yang tidak memengaruhi siklus rilis yang direncanakan.

Anda tidak boleh membuat cabang untuk setiap cerita pengguna karena menciptakan biaya integrasi yang tinggi. Meskipun TFVC memudahkan percabangan, overhead pengelolaan cabang bisa menjadi signifikan jika Anda memiliki banyak cabang.

Bagaimana tim mengelola rilis dari perspektif kontrol versi?

Tim Anda harus dapat merilis kode di akhir sprint apa pun. Dengan menggunakan Team Foundation Server, Anda dapat memberi label cabang untuk mengambil rekam jepret kode pada titik waktu tertentu. Seperti yang ditunjukkan oleh ilustrasi berikut, Anda dapat memberi label cabang MAIN untuk rilis. Ini memungkinkan Anda mengembalikan cabang ke statusnya pada saat ini.

Karena Anda harus menerapkan pembaruan pada rilis, membuat cabang untuk rilis membantu tim Anda terus bekerja secara independen pada sprint berikutnya tanpa membuat konflik dengan rilis mendatang. Ilustrasi berikut menunjukkan cabang yang berisi kode untuk pembaruan dan yang diintegrasikan terbalik ke dalam cabang MAIN setelah rilis di akhir sprint kedua.

Ketika Anda membuat cabang untuk rilis, Anda harus membuat cabang tersebut dari cabang MAIN, yang merupakan yang paling stabil. Jika Anda bercabang untuk rilis dari cabang kerja, itu dapat menyebabkan tantangan integrasi karena stabilitas cabang kerja tidak dijamin.

Artikel terkait

• Pilih strategi percabangan yang efektif