FullStack Application. Odpowiednia struktura repozytorium.

Question

Witam, kończę pisać prostą aplikację internetową i nadszedł czas na jej wydanie. Chcę udostępnić kod źródłowy na Github oraz umieścić ją publicznie z użyciem Heroku. Projekt podzielony jest na dwa katalogi o wiadomym przeznaczeniu:

• client
• server

Oba zawierają w sobie repozytorium git. W fazie deweloperskiej frontend jest serwowany z użyciem Vue CLI a backend to osobny serwer. W wersji produkcyjnej aplikacja Vue wraz z zasobami kompiluje się do katalogu public serwera jako statyczne pliki.

O ile na Github będą dostępne oba repozytoria, to na heroku trafi tylko serwer z odpowiednią statyczną zawartością katalogu public.

I tu mam mały problem:

• W przypadku repozytorium na Github, zawartość katalogu public serwera (skompilowana aplikacja) nie ma żadnego znaczenia i powinna znaleźć się w gitignore. Wynika to stąd, że w fazie testowej klient i serwer powinny działać odrębnie. Budowanie aplikacji Vue do tego katalogu nie powinno dokonywać zmian w historii repozytorium serwera. Było by to bardzo mylące i niewygodne.
• W przypadku heroku, który też wykorzystuje gita, katalog public ma znaczenie, ponieważ tam znajduje się gotowa zbudowana aplikacja.

Nie wiem od końca jak z tego wybrnąć. Pierwsze o czym pomyślałem to inne pliki gitignore dla obu platform. No ale repozytorium jest jedno... Da aplikacji produkcyjnej mogło by być oddzielne repo. Nie wiem jednak czy to nie jest zbyt nieefektywne rozwiązanie.

Będę bardzo wdzięczny za jakąś poradę od bardziej doświadczonych osób. Pozdrawiam serdecznie :)

Answer 1

Heroku zaciągą aplikację z gałęzi master/main i tam trzymaj sobie serwer z buildem w public, a fazę testową realizuj na innym branchu. Możesz napisać w package.json skrypty prebuild i postbuild uruchamiane przed i po buildzie, gdzie można realizować zadania kopiowania builda, usuwania, itd. Lub dowolny inny skrypt uruchamiany npm run, który będzie pracował na plikach.
Dwa oddzielne repo będą wymagały kopiowania builda, po każdej zmianie frontu i w historii commitów serwera, była by wtedy tylko zmiana plików (zminifikowanych w katalogu public) a co było zmienione w kodzie trzeba by było szukać w tym drugim repo. Jedno repo ma tą zaletę, że zmiany na serwerze i w kliencie będą/mogą być w jednym pull request. Odzielne repo wymusza najpierw wprowadzanie zmian na serwerze i sprawdzanie ich np. Postmanem, a dopiero potem zmianę w kliencie.
Wszystko zależy chyba też od skali projektu. Myślę, że jeśli build nie jest jakiś wielki, to nie ma problemu i jeśli assetów jest mało i ich nazwy nie są hashowane po buildzie za każdym razem.
Sam jestem ciekaw opinii innych.

Comments

Dziękuje za odpowiedź. Proces budowania aplikacji do odpowiedniego katalogu serwera mam zautomatyzowany. Ciekawy sposób z tymi brachami, nie pomyślałem o tym.

Po przeczytaniu odpowiedzi, widzę to u siebie tak:

Serwer i klient są w jednym repo. Mam 2 gałęzie, np:

• master (do produkcji)
• develop

W master, cała aplikacja kliencka była by w .gitignore. W develop public był by ignorowany. W razie dokonania jakiś zmian w develop, gałęzie były by złączone i potem, ponownie wydzielone.

Myślę, że mogę sobie pozwolić na jedno repo bo aplikacja jest mała i prosta. 

Nie wiem czy dobrze wszystko zrozumiałem i czy wyciągnąłem sensowne wnioski.

Będę wdzięczny za ustosunkowanie się do logiki mojego pomysłu :)

---

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

Jest kilka sposobów na to. W tym linku masz to opisane dokładniej co wybrałeś.