Migrasi ke Git dari kontrol versi terpusat

Artikel
07/27/2023

Memigrasikan tim ke Git dari kontrol versi terpusat memerlukan lebih dari sekadar mempelajari perintah baru. Untuk mendukung pengembangan terdistribusi, Git menyimpan riwayat file dan informasi cabang secara berbeda dari sistem kontrol versi terpusat. Merencanakan dan menerapkan migrasi yang sukses ke Git dari sistem kontrol versi terpusat memerlukan pemahaman tentang perbedaan mendasar ini.

Microsoft telah membantu memigrasikan banyak tim internal dan pelanggan dari sistem kontrol versi terpusat ke Git. Pengalaman ini telah menghasilkan panduan berikut berdasarkan praktik yang berhasil secara konsisten.

Langkah-langkah untuk keberhasilan migrasi

Agar migrasi berhasil, tim harus:

Mengevaluasi alat dan proses saat ini.
Pilih strategi pencabangan Git.
Tentukan apakah dan cara memigrasikan riwayat.
Pertahankan sistem kontrol versi sebelumnya.
Hapus file biner, executable, dan alat dari kontrol sumber.
Melatih tim dalam konsep dan praktik Git.
Uji migrasi ke Git.

Mengevaluasi alat dan proses saat ini

Mengubah sistem kontrol versi secara alami mengganggu alur kerja pengembangan dengan alat dan praktik baru. Gangguan ini dapat menjadi kesempatan untuk meningkatkan aspek lain dari proses DevOps.

Teams harus mempertimbangkan untuk mengadopsi praktik berikut saat bermigrasi ke sistem baru:

Integrasi berkelanjutan (CI), di mana setiap check-in memicu build dan uji lulus. CI membantu mengidentifikasi cacat lebih awal dan menyediakan jaring pengaman yang kuat untuk proyek.
Tinjauan kode yang diperlukan sebelum memeriksa kode. Dalam model pencabangan Git, peninjauan kode permintaan pull adalah bagian dari proses pengembangan. Tinjauan kode melengkapi alur kerja CI.
Pengiriman berkelanjutan (CD) untuk mengotomatiskan proses penyebaran. Mengubah alat kontrol versi memerlukan perubahan proses penyebaran, sehingga migrasi adalah waktu yang tepat untuk mengadopsi alur rilis modern.

Pilih strategi percabangan Git

Sebelum memigrasikan kode, tim harus memilih strategi percabangan.

Di Git, cabang topik berumur pendek memungkinkan pengembang untuk bekerja dekat dengan cabang utama dan berintegrasi dengan cepat, menghindari masalah penggabungan. Dua strategi cabang topik umum adalah GitFlow dan variasi yang lebih sederhana, GitHub Flow.

Git mencegah cabang fitur berumur panjang dan terisolasi, yang cenderung menunda penggabungan sampai integrasi menjadi sulit. Dengan menggunakan teknik CD modern seperti bendera fitur, tim dapat mengintegrasikan kode ke cabang utama dengan cepat, tetapi masih menjaga fitur yang sedang berlangsung tersembunyi dari pengguna hingga selesai.

Tim yang saat ini menggunakan strategi cabang fitur berumur panjang dapat mengadopsi bendera fitur sebelum bermigrasi ke Git. Menggunakan bendera fitur menyederhanakan migrasi dengan meminimalkan jumlah cabang yang akan dimigrasikan. Baik mereka menggunakan cabang fitur atau bendera fitur, tim harus mendokumenkan pemetaan antara cabang warisan dan cabang Git baru, sehingga semua orang memahami di mana harus melakukan pekerjaan baru mereka.

Memutuskan apakah akan memigrasikan riwayat

Teams mungkin tergoda untuk memigrasikan riwayat kode sumber yang ada ke Git. Beberapa alat mengklaim untuk memigrasikan riwayat lengkap semua cabang dari alat terpusat ke Git. Penerapan Git tampaknya memetakan dengan relatif baik ke set perubahan atau model check-in yang digunakan alat kontrol versi sebelumnya.

Namun, pemetaan ini memiliki beberapa batasan serius.

Di sebagian besar sistem kontrol versi terpusat, cabang ada sebagai folder di repositori. Misalnya, cabang utama mungkin berupa folder bernama /trunk, dan cabang lainnya adalah folder seperti /branch/one dan /branch/two. Dalam repositori Git, cabang menyertakan seluruh repositori, sehingga terjemahan 1:1 sulit.
Dalam beberapa sistem kontrol versi, tag atau label adalah koleksi yang dapat berisi berbagai file di pohon, bahkan file di versi yang berbeda. Di Git, tag adalah rekam jepret dari seluruh repositori pada titik waktu tertentu. Tag tidak dapat mewakili subset repositori atau menggabungkan file pada versi yang berbeda.
Sebagian besar sistem kontrol versi menyimpan detail tentang cara file berubah antar versi, termasuk jenis perubahan mendetail seperti mengganti nama, membatalkan penghapusan, dan pemutaran kembali. Git menyimpan versi sebagai rekam jepret dari seluruh repositori, dan metadata tentang cara file diubah tidak tersedia.

Perbedaan ini berarti bahwa migrasi riwayat penuh akan hilang paling baik, dan mungkin menyesatkan. Mengingat kehilangan, upaya yang terlibat, dan kelangkaan relatif penggunaan riwayat, disarankan agar sebagian besar tim menghindari impor riwayat. Sebaliknya, tim harus melakukan migrasi tip, hanya membawa rekam jepret versi cabang terbaru ke Git. Bagi sebagian besar tim, waktu paling baik dihabiskan untuk area migrasi yang memiliki pengembalian investasi yang lebih tinggi, seperti meningkatkan proses.

Mempertahankan sistem kontrol versi lama

Selama dan setelah migrasi, pengembang mungkin masih memerlukan akses ke riwayat kontrol versi sebelumnya. Meskipun riwayat kontrol versi sebelumnya menjadi kurang relevan dari waktu ke waktu, masih penting untuk dapat merujuknya. Lingkungan yang sangat diatur mungkin memiliki persyaratan hukum dan audit tertentu untuk riwayat kontrol versi.

Terutama untuk tim yang hanya melakukan migrasi tip, sangat disarankan untuk mempertahankan sistem sebelumnya tanpa batas waktu. Atur sistem kontrol versi lama ke baca-saja setelah Anda bermigrasi.

Tim pengembangan besar dan lingkungan yang diatur dapat menempatkan remah roti di Git yang mengarah kembali ke sistem kontrol versi lama. Contoh sederhana adalah file teks yang ditambahkan sebagai penerapan pertama di akar repositori Git, sebelum migrasi tip, yang menunjuk ke URL server kontrol versi lama. Jika banyak cabang bermigrasi, file teks di setiap cabang harus menjelaskan bagaimana cabang dimigrasikan dari sistem lama. Remah roti juga berguna bagi pengembang yang mulai mengerjakan proyek setelah dimigrasikan dan tidak terbiasa dengan sistem kontrol versi lama.

Menghapus file dan alat biner

Model penyimpanan Git dioptimalkan untuk membuat versi file teks dan kode sumber, yang ringkas dan sangat dapat dikompresi. File biner biasanya besar, dan setelah ditambahkan ke repositori, file tersebut tetap dalam riwayat repositori dan di setiap kloning di masa mendatang. Karena cara Git menyimpan riwayat, pengembang harus menghindari penambahan file biner ke repositori, terutama biner yang sangat besar atau yang sering berubah. Migrasi ke Git adalah kesempatan untuk menghapus biner ini dari basis kode.

Disarankan juga untuk mengecualikan pustaka, alat, dan output build dari repositori. Sebagai gantinya, gunakan sistem manajemen paket seperti NuGet untuk mengelola dependensi.

Aset seperti ikon dan karya seni mungkin perlu diselaraskan dengan versi kode sumber tertentu. Aset kecil yang jarang diubah seperti ikon tidak akan membesarkan riwayat, dan Anda dapat memasukkannya langsung ke dalam repositori. Untuk menyimpan aset besar atau yang sering berubah, gunakan ekstensi Git Large File Storage (LFS). Untuk informasi selengkapnya tentang mengelola file besar di GitHub, lihat Mengelola file besar. Untuk Azure Repos, lihat Mengelola dan menyimpan file besar di Git.

Memberikan pelatihan

Salah satu tantangan terbesar dalam bermigrasi ke Git adalah membantu pengembang memahami bagaimana Git menyimpan perubahan dan bagaimana penerapan membentuk riwayat pengembangan. Tidak cukup untuk menyiapkan contekan yang memetakan perintah lama ke perintah Git. Pengembang perlu berhenti memikirkan riwayat kontrol versi dalam hal model linier terpusat, dan memahami model riwayat Git dan grafik penerapan.

Orang belajar dengan cara yang berbeda, jadi Anda harus menyediakan beberapa jenis materi pelatihan. Pelatihan langsung berbasis lab dengan instruktur ahli dapat membantu untuk beberapa orang. Buku Pro Git adalah titik awal yang sangat baik yang tersedia gratis secara online.

Kursus pelatihan langsung gratis yang tersedia meliputi:

Organisasi harus bekerja untuk mengidentifikasi pakar Git di tim, memberdayakan mereka untuk membantu orang lain, dan mendorong anggota tim lain untuk mengajukan pertanyaan kepada mereka.

Menguji migrasi

Setelah tim memperbarui proses mereka, menganalisis kode mereka, dan melatih anggota mereka, saatnya untuk memigrasikan kode sumber. Baik Anda melakukan migrasi tip atau memigrasikan riwayat, penting untuk melakukan satu atau beberapa migrasi pengujian ke repositori pengujian. Sebelum Anda melakukan migrasi akhir, pastikan:

Semua file kode bermigrasi.
Semua cabang tersedia.
Tidak ada biner tersesat di repositori.
Pengguna memiliki izin yang sesuai untuk mengambil dan mendorong.
Build berhasil, dan semua pengujian lulus.

Memigrasikan kode

Lakukan migrasi akhir selama jam kerja, idealnya antara tonggak pencapaian ketika ada waktu henti alami. Migrasi di akhir sprint dapat menyebabkan masalah saat pengembang mencoba menyelesaikan pekerjaan. Cobalah untuk bermigrasi selama akhir pekan, ketika tidak ada yang perlu check-in.

Rencanakan cutover perusahaan dari sistem kontrol versi lama ke Git. Mencoba mengoperasikan beberapa sistem secara paralel berarti pengembang mungkin tidak tahu di mana atau bagaimana cara check-in. Atur sistem kontrol versi lama ke baca-saja untuk membantu menghindari kebingungan. Tanpa perlindungan ini, migrasi kedua yang mencakup perubahan sementara mungkin diperlukan.

Proses migrasi aktual bervariasi tergantung pada sistem tempat Anda bermigrasi. Untuk informasi tentang migrasi dari Kontrol Versi Team Foundation, lihat Migrasi dari TFVC ke Git.

Daftar periksa migrasi

Alur kerja tim:

Tentukan bagaimana build akan berjalan.
Tentukan kapan pengujian akan berjalan.
Mengembangkan proses manajemen rilis.
Pindahkan tinjauan kode untuk menarik permintaan.

Strategi percabangan:

Pilih strategi percabangan Git.
Dokumentasikan strategi pencabangan, mengapa dipilih, dan bagaimana peta cabang warisan.

Riwayat:

Tentukan berapa lama untuk menjaga kontrol versi warisan tetap berjalan.
Identifikasi cabang yang perlu dimigrasikan.
Jika diperlukan, buat remah roti untuk membantu teknisi menavigasi kembali ke sistem warisan.

Biner dan alat:

Identifikasi biner mana dan file yang tidak dapat dikakukan untuk dihapus dari repositori.
Tentukan pendekatan untuk file besar, seperti Git-LFS.
Tentukan pendekatan untuk mengirimkan alat dan pustaka, seperti NuGet.

Pelatihan:

Mengidentifikasi materi pelatihan.
Rencanakan acara pelatihan, materi tertulis, dan video.
Identifikasi anggota tim untuk berfungsi sebagai pakar Git lokal.

Migrasi kode:

Lakukan beberapa uji coba untuk memastikan migrasi akan berjalan lancar.
Identifikasi dan komunikasikan waktu cutover.
Buat repositori Git baru.
Atur sistem lama ke baca-saja.
Migrasikan cabang utama terlebih dahulu, lalu cabang lain yang diperlukan.