Chciałbym wiedzieć, czy sensownie jest podzielić projekt, nad którym pracuję, na dwa repozytoria zamiast jednego.
Z tego co mogę powiedzieć:
- Frontend zostanie napisany w html + js
- Backend w .net
- Backend nie zależy od frontendu, a frontend nie zależy od backendu
- Frontend użyje spokojnego interfejsu API zaimplementowanego w backend.
- Frontend może być hostowany na dowolnym statycznym serwerze http.
Na razie repozytorium ma następującą strukturę:
korzeń:
- frontend / *
- backend / *
Myślę, że błędem jest utrzymywanie obu projektów w tym samym repozytorium. Ponieważ oba projekty nie mają zależności między sobą, powinny one należeć do poszczególnych repozytoriów, aw razie potrzeby do repozytorium nadrzędnego zawierającego podmoduły.
Powiedziano mi, że jest to bezcelowe i że nie uzyskamy z tego żadnej korzyści.
Oto niektóre z moich argumentów:
- Mamy dwa moduły, które nie zależą od siebie.
- Posiadanie historii źródłowej obu projektów na dłuższą metę może skomplikować sytuację (spróbuj wyszukać w historii coś w interfejsie, mając połowę zatwierdzeń, które są całkowicie niezwiązane z szukanym błędem)
- Konflikt i scalanie (to nie powinno się zdarzyć, ale zmuszenie kogoś do pchnięcia backendu zmusi innego programistę do wycofania zmian backendu w celu pchnięcia zmian frontendu).
- Jeden programista może działać tylko na backendie, ale zawsze będzie musiał wyciągnąć frontend lub na odwrót.
- Na dłuższą metę, kiedy nadejdzie czas na wdrożenie. W pewien sposób interfejs może zostać wdrożony na wielu statycznych serwerach, mając jednocześnie jeden serwer zaplecza. W każdym przypadku ludzie będą zmuszeni albo do sklonowania całego backendu, albo do stworzenia niestandardowego skryptu, aby wypychał na wszystkie serwery tylko frontend lub usuwał backend. Łatwiej jest po prostu pchać / ciągnąć tylko frontend lub backend niż oba, jeśli tylko jeden jest potrzebny.
- Przeciwdziałanie argumentom (jedna osoba może pracować przy obu projektach), Utwórz trzecie repozytorium z podmodułem i rozwijaj się z nim. Historia jest podzielona na poszczególne moduły i zawsze możesz tworzyć tagi, w których wersja backend / frontend naprawdę działa razem. Posiadanie obu frontend / backend razem w jednym repozytorium nie oznacza, że będą one działać razem. To tylko połączenie obu historii w jedno duże repo.
- Posiadanie frontendu / backendu jako submodułów ułatwi to, jeśli chcesz dodać freelancera do projektu. W niektórych przypadkach tak naprawdę nie chcesz dać pełnego dostępu do bazy kodów. Posiadanie jednego dużego modułu sprawi, że będzie trudniej, jeśli chcesz ograniczyć to, co „obcy” mogą zobaczyć / edytować.
- Wprowadzenie błędu i naprawa błędu, wstawiłem nowy błąd w interfejsie. Następnie ktoś naprawia błąd w backend. W jednym repozytorium wycofanie przed nowym błędem spowoduje również wycofanie backendu, co może utrudnić jego naprawienie. Musiałbym sklonować backend w innym folderze, aby backend działał podczas naprawiania błędu w frontendzie ... a następnie próbowałem go przerobić ... Posiadanie dwóch repozytoriów będzie bezbolesne, ponieważ przemieszczenie HEAD jednego repo wygrało nie zmieniaj drugiego. A testowanie różnych wersji backendu będzie bezbolesne.
Czy ktoś może podać mi więcej argumentów, aby je przekonać lub przynajmniej powiedzieć mi, dlaczego dzielenie projektu na dwa podmoduły jest bezcelowe (bardziej skomplikowane). Projekt jest nowy, a baza kodów ma kilka dni, więc nie jest za wcześnie, aby to naprawić.
źródło
Niektóre z twoich argumentów są prawidłowe, a niektóre nie.
To nie jest do końca prawda. Aby móc się komunikować, zarówno front-end, jak i back-end muszą mieć wspólny interfejs (opis). To sprawia, że jest to słaby argument przemawiający za posiadaniem obu w jednym repozytorium. Ale tylko słaby argument, ponieważ nie robi tak dużej różnicy.
To fałszywy argument. Jeśli chcesz sprawdzić, w jaki sposób naprawiono konkretny błąd, zajrzyj do narzędzia do śledzenia błędów, dla którego zatwierdzenie zawiera poprawkę. A jeśli chcesz wiedzieć, jak ewoluował dany fragment kodu, zapoznaj się z historią jednego pliku (lub co najwyżej garstki). W obu przypadkach posiadanie innych plików, prawdopodobnie z innych modułów, w repozytorium nie powinno w żaden sposób komplikować rzeczy.
To fałszywy argument. Nie znam żadnego (na wpół przyzwoitego) VCS, w którym trzeba zsynchronizować całe repozytorium, zanim będzie można zatwierdzić / wypchnąć zmiany. Co najwyżej musisz zsynchronizować foldery zawierające zmienione pliki (a często tylko same pliki).
To ten sam fałszywy argument, co poprzedni.
W zależności od tego, jak ludzie przewidują, że wdrożenie zostanie wykonane, może to być prawidłowy argument. Jeśli wdrożenie zostanie wykonane przez rozpakowanie pliku zip / tarballa na serwerze, nie ma znaczenia, w jaki sposób zorganizowane są repozytoria. Jeśli wdrożenie zostanie wykonane poprzez wyewidencjonowanie (części) repozytorium na serwerze, dobrym pomysłem może być użycie osobnych repozytoriów dla modułów, które są wdrażane osobno.
To jest ważny argument, ale nie jest tak silny.
To jest poprawny argument.
To fałszywy argument, ponieważ oznaczałoby to, że po dwóch poprawkach błędów w jednym module nie będzie można przywrócić pierwszego. Każdy na wpół przyzwoity VCS pozwoli ci cofnąć prawie każdy stary zatwierdzenie (chociaż często będzie to oznaczać, że wykonasz nowe zatwierdzenie, które odwraca te zmiany, czasem nawet na górze HEAD).
To właściwie całkiem niezły argument. Posiadanie dwóch repozytoriów ułatwia testowanie scenariuszy, w których wdrożone interfejsy i zaplecze mogą (nieznacznie) zostać zsynchronizowane.
źródło
Ten post jest trochę stary, ale chciałbym się do niego przyczynić. Chociaż Twoje zaplecze tak naprawdę nie wie o interfejsie, musi ono zawierać żądania pasujące do interfejsu API zaplecza. Jeśli weźmiesz pod uwagę back-end jako interfejs API REST, możesz zdefiniować plik interfejsu, taki jak interfejs YAML swagger. Teraz są naprawdę 3 projekty, które możesz indywidualnie podzielić na różne repozytoria według własnego uznania:
Definicja API jest zależnością w dwóch pozostałych projektach, powiedzmy, że używałeś maven jako narzędzia do wstrzykiwania zależności. To zależy od tego, jak ściśle chcesz tworzyć wersje. Możesz podnieść wersję projektu definicji API za każdym razem, gdy wprowadzasz zmiany, aby upewnić się, że projekty są zawsze w stanie kompatybilnym, ale wymagają większego obciążenia, lub możesz użyć czegoś takiego jak SNAPSHOTS w maven i wykonać wersjonowanie tylko wtedy, gdy jesteś zadowolony z interfejsu, który jest mniej obciążony, ale często możesz mieć niezgodności. Ale tak długo, jak wymusisz definicję interfejsu API w interfejsie i zapleczu, będziesz mógł dobrze podzielić projekty na różne repozytoria.
Te problemy dotyczą bardziej zarządzania zależnościami. Nawet jeśli projekty nie są podzielone i znajdują się w tym samym repozytorium, dość łatwo jest wprowadzić stronę internetową w stan, w którym przód i tył nie są zsynchronizowane. Naprawdę jedynym sposobem na powstrzymanie tego jest faktyczne zdefiniowanie umowy między nimi, ale chcesz to zrobić w sposób, który nie łączy implementacji frontonu i back-endu, podobnie jak koduje się interfejs implementacji w programowaniu OO.
Aby zapobiegawczo poradzić sobie z krytyką, że stwarza to narzut związany z utrzymywaniem tego pliku interfejsu, na przykład swagger może nawet tworzyć kody pośredniczące kodu dla różnych języków programowania i struktur, takich jak JAX-RS. Możesz więc stworzyć interfejs w wybranej technologii, a następnie wdrożyć ten interfejs. Dodaje również bardzo ładną dokumentację do zaplecza, ułatwiając programistom front-end wykonywanie swoich zadań.
źródło