Układ dużego projektu: dodanie nowej funkcji do wielu podprojektów

13

Chcę wiedzieć, jak zarządzać dużym projektem z wieloma komponentami za pomocą systemu zarządzania kontrolą wersji.

W moim obecnym projekcie są 4 główne części.

  1. Sieć
  2. serwer
  3. Konsola administracyjna
  4. Platforma.

Część internetowa i serwerowa używa 2 bibliotek, które napisałem. W sumie istnieje 5 repozytoriów git i 1 repozytorium rtęciowe. Skrypt kompilacji projektu znajduje się w repozytorium platformy. Automatyzuje cały proces budowy.

Problem polega na tym, że gdy dodam nową funkcję, która wpływa na wiele składników, muszę utworzyć gałąź dla każdego repozytorium, którego dotyczy problem. Zaimplementuj tę funkcję. Scal to z powrotem. Moje przeczucie brzmi: „coś jest nie tak”.

Czy powinienem utworzyć pojedyncze repozytorium i umieścić tam wszystkie komponenty? Myślę, że rozgałęzienie będzie w tym przypadku łatwiejsze. Albo po prostu robię to, co robię teraz. W takim przypadku jak rozwiązać ten problem tworzenia gałęzi w każdym repozytorium?

version-control branching configuration-management merging Shiplu Mokaddim
źródło
Czy potrafisz ponownie ustawić swoją funkcjonalność tak, aby umieścić jak najwięcej we wspólnych bibliotekach (klejnoty Ruby, jaja Python, ziarna Java itp.), A następnie złożyć części z myślą o „skomponowaniu” każdego elementu z bibliotek?
Narfanator,
Zastanów się, kiedy dodamy obsługę nowego protokołu do komponentu Serwer. Musimy również dodać odpowiednie kontrolki interakcji (przyciski, pola itp.) W tym celu również w Internecie. To jest problem
Shiplu Mokaddim,
1
To brzmi jak analogiczne do wzorca „pomostowego”; możesz czerpać z tego inspirację.
Narfanator,
jedno repozytorium, by rządzić nimi wszystkimi
Steven A. Lowe

Odpowiedzi:

8

W opisywanej sytuacji nie ma żadnych korzyści z posiadania wielu repozytoriów, ale wiąże się to z pewnym kosztem: nie można przywrócić starszej wersji repozytorium i mieć pewność, że system będzie nadal działał. Wynika to z faktu, że kod jest ściśle powiązany z repozytoriami. Ponieważ zaufanie do możliwości wycofania jest jedną z głównych korzyści kontroli źródła, nie jest to sytuacja, w której chcesz się znaleźć.

Rozwiązaniem jest zdefiniowanie struktury repozytorium na podstawie sprzężenia zawartego w nim kodu: jeśli komponent projektu A dzieli tylko stabilne interfejsy z komponentem projektu B, wówczas można je umieścić w osobnych repozytoriach. W przeciwnym razie powinny one znajdować się w tym samym repozytorium. Bardziej szczegółowy układ repozytorium będzie odzwierciedlał lepiej zorganizowaną architekturę systemu.

Aidan Cully
źródło
2

Jeśli każde z twoich repozytoriów jest samodzielnymi projektami lub bibliotekami, powiedziałbym, że nie ma nic złego w konieczności tworzenia gałęzi funkcji w każdym repozytorium podczas dodawania nowych funkcji, które są przekrojowe w projektach. Będąc samodzielnym, każdy z nich może być niezależnie wersjonowany i możesz przestać używać starych interfejsów API.

Ale w twoim konkretnym przypadku wygląda na to, że Twoje repozytoria nie grupują twojego kodu skutecznie. Jeśli zmiany w kodzie w jednym repozytorium wymagają zmian w innych (na bok wycofanie), to albo twoje połączenie jest zbyt ciasne, albo repozytoria powinny zostać zreorganizowane.

Jeśli wszystkie repozytoria są częścią tego samego projektu (nie mogą być samodzielne), być może powinieneś mieć tylko 1 repozytorium. (A może 2: projekt główny i jeden dotyczący ogólnej / standardowej funkcjonalności).

Allan
źródło