Strategi untuk menggunakan kontrol versi pada sistem modular

Anggaplah (untuk kesederhanaan) bahwa kita memiliki aplikasi yang menampilkan klien dan server; Adakah ide yang lebih baik untuk menggunakan satu repositori untuk keduanya atau sepasang repositori terpisah?

Mencampurnya mungkin akan membuat lebih mudah untuk melacak perubahan yang berkorelasi dan mempertahankan cabang yang berkorelasi (yaitu evolusi protokol), tetapi di sisi lain akan membuat pengembangan individu lebih berantakan ...

Jika Anda menggunakan git atau lincah , maka Anda mungkin ingin melihat submodula atau subrepositori .

Klien, server dan file antarmuka mereka akan berada di repositori mereka sendiri, tetapi akan diikat bersama di tingkat super-repositori . Ini akan memungkinkan Anda untuk melakukan satu checkout di tingkat atas dan gitatau hgakan memeriksa komit yang sesuai dari masing-masing submodules / subrepositori.

Dengan hanya melakukan super-repositori ketika kedua klien dan server cocok satu sama lain, super-repositori hanya akan memberi Anda pilihan untuk memeriksa sistem kerja - jadi Anda tidak akan pernah mencoba menjalankan klien baru terhadap yang lama server atau sebaliknya.

Submodules / subrepositori memberi Anda semua keuntungan menggunakan repositori terpisah, bersama dengan keuntungan dari repositori monolitik tunggal, dengan mengorbankan sedikit kompleksitas tambahan.

_{Jawaban ini tidak dimaksudkan untuk mengadvokasi gitatau hgmelebihi SCM lain, tetapi kebetulan saya hanya tahu SCM ini cukup baik untuk mengetahui bahwa opsi ini ada. Saya tidak mengerti bagaimana svneksternal bekerja misalnya.}

Terpisah!

Bahkan, saya mungkin memiliki tiga repositori, satu untuk Klien dan pustaka hanya klien yang sesuai, satu untuk Server (dan pustaka yang sesuai), dan satu untuk pustaka bersama (menggabungkan antarmuka API yang memperlihatkan fungsi antara keduanya , ditambah kode bersama lainnya). Saya pikir itu benar-benar kuncinya, kode bersama harus masuk ke dalam repositori tersendiri. Dengan begitu Anda dapat memastikan bahwa interoperabilitas antara klien dan server Anda selalu pada versi yang sama DAN terisolasi dari desain masing-masing konsumennya.

Jelas, ini tidak selalu mungkin, tergantung pada kerangka komunikasi tertentu yang Anda gunakan, tetapi ada kemungkinan kode bersama yang menentukan format objek transfer data atau langkah jabat tangan dalam protokol khusus Anda (atau beberapa contoh lain) .

Dengan asumsi Anda memiliki Continuous Integration dan QA setup yang cukup baik (asumsi yang cukup besar, dalam pengalaman saya, tetapi saya akan membuat. Jika Anda tidak memiliki departemen QA, Anda setidaknya harus mendapatkan beberapa CI) Anda seharusnya tidak Anda perlu menggunakan pola repo tunggal sebagai pertahanan terhadap kemungkinan kecocokan kode yang salah, baik server CI Anda akan menandai interoperabilitas perpustakaan atau tim QA Anda akan menemukan kesalahan runtime (atau, bahkan lebih baik, Tes Unit Anda akan).

Manfaat dari repositori split terletak pada kemampuan untuk secara terpisah membuat versi bagian yang terpisah dari suatu sistem. Ingin mengambil salinan Server minggu lalu dan menjalankannya dengan Klien minggu ini, untuk mencoba dan mengunci akar masalah kinerja? Jangan khawatir.

Dalam Mercurial , skema ini dapat digunakan, menggunakan ->untuk menunjukkan hubungan subrepo:

product -> client -|-> (many components)
                   |->  shared component A

        -> server -|-> (many components)
                   |->  shared component A

Produk memiliki klien subrepos, server. Masing-masing memiliki komponen sebagai subrepo, mungkin setidaknya satu subrepo dibagi di antara keduanya.

Penandaan mungkin harus dilakukan pada dua level pertama, bukan di bawah itu.

Komit dilakukan pada tingkat komponen, superrepos secara efektif melacak cabang bernama dan versi produk. Cabang yang dinamai / bookmark biasanya lebih baik daripada cabang klon untuk kegunaan (yaitu kemampuan untuk dilatih) dan kompatibilitas dengan subrepo.

hg cenderung ke arah asumsi bahwa superrepo adalah produk, dan komitmen dilakukan di tingkat atas, tetapi itu tidak bekerja dengan baik ketika banyak produk menggunakan komponen yang sama. :-)

Saya tidak berpikir bahwa skema ini akan banyak berubah jika dialihkan ke git, tetapi saya belum mencobanya di git.

Ini adalah masalah manajemen konfigurasi, bukan masalah kontrol revisi. Seperti biasa, seorang programmer menggunakan obeng untuk memalu paku. Cari tahu bagaimana Anda akan mengelola konfigurasi Anda, kontrol revisi akan mengurus dirinya sendiri.

The sederhana pendekatan adalah untuk menggunakan repositori tunggal, jadi kecuali Anda seperti kompleksitas demi kompleksitas ini, maka yang harus menjadi pilihan default dalam ketiadaan argumen menarik sebaliknya.

Apakah pengembangan klien dan server akan dilakukan oleh organisasi yang berbeda? Apakah akan ada beberapa implementasi dari klien (atau server)? Apakah klien open source dan implementasi server rahasia? Jika jawaban untuk semua pertanyaan ini adalah "Tidak", maka sesuatu yang lebih kompleks daripada repositori tunggal kemungkinan hanya membawa ketidaknyamanan tanpa manfaat.

Jika Anda memilih untuk mempertahankan basis kode yang terpisah, Anda akan memerlukan kebijakan yang jelas tentang bagaimana ini dikelola, untuk menghindari ketidakcocokan dan neraka ketergantungan. Setelah mengerjakan beberapa cegukan pertama, Anda mungkin akhirnya menemukan bahwa hal teraman adalah selalu memeriksa kedua repositori bersama, membangunnya bersama, dan menempatkannya bersama-sama ... yang jelas mengalahkan seluruh tujuan memisahkannya!

Modularitas adalah properti yang bagus untuk dimiliki, tetapi memisahkan repositori bukanlah alat untuk mencapainya. Seperti paragraf sebelumnya menyiratkan, Anda dapat memiliki komponen yang sangat berpasangan yang terbagi atas beberapa basis kode (tidak diinginkan), dan Anda juga dapat memiliki komponen yang sangat modular dalam basis kode yang sama (diinginkan).

Pada lebih dari satu kesempatan, saya telah mengadvokasi (dengan sukses) agar tim saya menggabungkan repositori git yang ada, karena ini menyederhanakan pengembangan dan penyebaran.

Lupakan repositori sejenak. Bagaimana Anda mengatur dua proyek di mesin Anda jika Anda tidak berbagi dengan siapa pun? Bagaimana anggota tim lainnya melakukannya? Maukah kamu...

• Letakkan semua file sumber untuk klien dan server di direktori yang sama?

• Buat direktori proyek utama yang berisi subdirektori untuk klien dan server?

• Pisahkan kedua proyek sepenuhnya?

Setelah Anda mencapai beberapa konsensus tentang hal itu sebagai tim, Anda siap untuk memeriksa proyek ke dalam repositori kode Anda. Semua alat kontrol revisi yang dapat saya pikirkan dengan senang hati mereproduksi struktur direktori yang Anda suka - mereka tidak peduli sedikit pun tentang file mana yang termasuk dalam proyek mana. Dan perbedaan antara memiliki satu atau dua repositori (atau enam) biasanya tidak terlalu bagus, selain dari perbedaan administrasi kecil.

Misalnya, dengan Subversion, perbedaan terbesar antara repositori terpisah untuk klien dan server dan repositori gabungan tunggal adalah dalam cara perubahan angka revisi. Dengan repositori singe, nomor versi akan bertambah setiap kali Anda mengkomit kode ke klien atau server. Dengan repositori terpisah, komit ke proyek server tidak akan mengubah nomor revisi kepala untuk klien.