Layout proyek besar: menambahkan fitur baru pada beberapa sub proyek

13

Saya ingin tahu cara mengelola proyek besar dengan banyak komponen dengan sistem manajemen kontrol versi.

Dalam proyek saya saat ini ada 4 bagian utama.

  1. Web
  2. Server
  3. Konsol admin
  4. Peron.

Bagian web dan server menggunakan 2 perpustakaan yang saya tulis. Secara total ada 5 repositori git dan 1 repositori mercurial. Skrip build proyek ada di repositori Platform. Ini mengotomatiskan seluruh proses pembangunan.

Masalahnya adalah ketika saya menambahkan fitur baru yang mempengaruhi banyak komponen saya harus membuat cabang untuk masing-masing repo yang terpengaruh. Terapkan fitur tersebut. Gabungkan kembali. Perasaan saya adalah "ada sesuatu yang salah".

Jadi haruskah saya membuat repo tunggal dan meletakkan semua komponen di sana? Saya pikir percabangan akan lebih mudah dalam hal ini. Atau saya hanya melakukan apa yang saya lakukan sekarang. Dalam hal itu, bagaimana saya mengatasi masalah ini dengan membuat cabang pada setiap repositori?

version-control branching configuration-management merging Shiplu Mokaddim
sumber
Bisakah Anda mengatur ulang fungsionalitas Anda untuk menempatkan sebanyak mungkin di perpustakaan bersama (permata Ruby, telur Python, kacang Jawa, dll), dan kemudian merakit bagian dengan ide "menyusun" setiap elemen dari perpustakaan?
Narfanator
Pikirkan ketika kita menambahkan dukungan protokol baru pada komponen Server. Kami juga harus menambahkan kontrol interaksi yang tepat (tombol, bidang dll) untuk ini di web juga. Itulah masalahnya
Shiplu Mokaddim
1
Kedengarannya seperti analog dengan pola "jembatan"; Anda mungkin mengambil inspirasi dari itu.
Narfanator
satu repositori untuk memerintah mereka semua
Steven A. Lowe

Jawaban:

8

Dalam situasi yang Anda jelaskan, Anda tidak mendapatkan manfaat dari memiliki beberapa repositori, tetapi Anda memiliki biaya: Anda tidak dapat memutar kembali ke versi repositori yang lebih lama, dan memiliki keyakinan bahwa sistem Anda akan terus bekerja. Ini karena kode Anda tergabung erat di seluruh repositori. Karena kepercayaan pada kemampuan untuk memutar kembali adalah salah satu manfaat utama dari kontrol sumber, ini bukanlah situasi yang Anda inginkan.

Solusinya adalah mendefinisikan struktur repositori Anda berdasarkan pada kopling kode di dalamnya: jika komponen proyek A hanya berbagi antarmuka yang stabil dengan komponen proyek B, maka mereka dapat ditempatkan dalam repositori terpisah. Kalau tidak, mereka harus ditempatkan di repositori yang sama. Tata letak repositori yang lebih granular akan mencerminkan arsitektur sistem dengan faktor yang lebih baik.

Aidan Cully
sumber
2

Jika masing-masing repositori Anda adalah proyek atau pustaka yang berdiri sendiri, maka saya akan mengatakan bahwa tidak ada yang salah secara inheren dengan kebutuhan untuk membuat cabang fitur pada setiap repo ketika menambahkan fitur baru yang lintas sektor dalam proyek. Dengan berdiri sendiri, masing-masing dapat diversi secara independen dan Anda dapat mencabut API lama.

Tetapi dalam kasus khusus Anda, sepertinya repositori Anda mungkin tidak mengelompokkan kode Anda secara efektif. Jika perubahan kode dalam satu repositori memerlukan perubahan ke yang lain (selain penghentian) maka kopling Anda terlalu ketat atau repositori harus diatur ulang.

Jika semua repositori benar-benar merupakan bagian dari proyek yang sama (mereka tidak dapat berdiri sendiri) maka mungkin Anda hanya memiliki 1 repositori. (Atau mungkin 2: proyek utama dan satu untuk fungsi generik / standar.)

Allan
sumber